Being from France and having worked in a company that deals mainly with government contracts, I've seen some of these aspects first hand.
The company I was in was far from being as horrible as the one mentioned in this post and management was not complete douchebags, they never fired people for being 1 minute late, didn't impose strict hours.
On thing to keep in mind is that public contracts are extremely unhealthy for all the parties involved.
The government agency as more rights than a private organization asking for the same kind of job, the agency can impose everything as long as it is written in the scope statement document (which is rather mediocre in general, can be vague, can be self-contradictory and some requirements may not be doable at all), your actual technical offer as little weight.
I remember a project where we got screwed by one pretty vague phrase mentioning a document (which was not provided during the call for bids by the way). In this document there was a lot of idiotic guidelines regarding software path installation, init scripts, users running daemons... that even the government agency didn't follow internally, and that made any kind of automation extremely difficult. We got screwed also by indecision from the client in this project, first Debian was chosen, then CentOS, then a mix of Debian and CentOS, I reinstall our platform 3 or 4 times before it was decided...
Then there is the other part. The bids are generally quite competitive, and the most important factor is the price generally, little digging is done on the actual technical quality of the answer. As a result, these projects are generally undersold, with the idea that it will be possible to ludicrously bill maintenance and changes of scope after the initial contract. As an example, I've seen a project where the risk provision was ridiculously low despite the fact a core piece of the system was an off the shelf software that existed only on paper at the time of the call for bids (and we lost several months trying to make it work and advising the editor).
Also, sometime some legitimate risks are taken but are not completely assumed. For example, most of these contracts will have a tight schedule, but in general, the government agency will be quite slow on their parts (buying servers for example). So it's safe to assume that your tight schedule is a bit more lax, and you have more time than what is written on the contract. It's taken into account in the bid, but in the end, management doesn't remember it and ask you why it took more than the tight schedule agreed in the contract.
Globally, everybody is trying to screw everybody at the detriment of the users who actually need the system.
And as an engineer, it's really not satisfying to work in those conditions, you constantly cut corners (unit tests? no.), you have to make due with what you have (I literally stole old servers that seemed abandoned by other projects to work) and you produce sub-par systems that will blow up in production (and you don't have access to production systems, so any bug is pretty much catastrophic).
I decided to left this company when a sales guy told me that we were losing money because we "engineer were too perfectionist".
The company I was in was far from being as horrible as the one mentioned in this post and management was not complete douchebags, they never fired people for being 1 minute late, didn't impose strict hours.
On thing to keep in mind is that public contracts are extremely unhealthy for all the parties involved.
The government agency as more rights than a private organization asking for the same kind of job, the agency can impose everything as long as it is written in the scope statement document (which is rather mediocre in general, can be vague, can be self-contradictory and some requirements may not be doable at all), your actual technical offer as little weight.
I remember a project where we got screwed by one pretty vague phrase mentioning a document (which was not provided during the call for bids by the way). In this document there was a lot of idiotic guidelines regarding software path installation, init scripts, users running daemons... that even the government agency didn't follow internally, and that made any kind of automation extremely difficult. We got screwed also by indecision from the client in this project, first Debian was chosen, then CentOS, then a mix of Debian and CentOS, I reinstall our platform 3 or 4 times before it was decided...
Then there is the other part. The bids are generally quite competitive, and the most important factor is the price generally, little digging is done on the actual technical quality of the answer. As a result, these projects are generally undersold, with the idea that it will be possible to ludicrously bill maintenance and changes of scope after the initial contract. As an example, I've seen a project where the risk provision was ridiculously low despite the fact a core piece of the system was an off the shelf software that existed only on paper at the time of the call for bids (and we lost several months trying to make it work and advising the editor).
Also, sometime some legitimate risks are taken but are not completely assumed. For example, most of these contracts will have a tight schedule, but in general, the government agency will be quite slow on their parts (buying servers for example). So it's safe to assume that your tight schedule is a bit more lax, and you have more time than what is written on the contract. It's taken into account in the bid, but in the end, management doesn't remember it and ask you why it took more than the tight schedule agreed in the contract.
Globally, everybody is trying to screw everybody at the detriment of the users who actually need the system.
And as an engineer, it's really not satisfying to work in those conditions, you constantly cut corners (unit tests? no.), you have to make due with what you have (I literally stole old servers that seemed abandoned by other projects to work) and you produce sub-par systems that will blow up in production (and you don't have access to production systems, so any bug is pretty much catastrophic).
I decided to left this company when a sales guy told me that we were losing money because we "engineer were too perfectionist".