10 years in and they were still billing -- more than ever -- for a project that would have completed 7-8 years previously if things had been done according to plan.
All the seemingly massively stupid and counter productive decisions made make sense if the goal is to confuse matters to make it seem like progress has been made or reforms instituted or bold corrective actions taken while actually keeping the project hopelessly mired.
It's like the Producers. (Though without the ironic twist... in reality it surely must be impossible to accidentally complete a software project successfully. No doubt, without the laughs either.)
i suspect the french gov will have put something similar in place, but i do agree with the final paragraph of the piece - it's probably a corrupt practise not top management stupidity.
I hope you didn't miss that sentence. It's the irony that probably lives in every government project.
Except, as these things go, what is being reviewed is whether the projects meets its arbitrarily nonsensical, self contradictory requirements and whether all 1528 required process artifacts have been properly archived in manila folders, not whether the project makes sense or follows basic economic principles.
No money to give nurses a pay rise but IT consultants laughing all the way to the bank. And the same consulting companies still have their noses in the trough.
Same story at the MoD.
Of course, this becomes more expensive upfront as well, because the consultant takes on the risk. Hourly billing seems cheaper to the client, since they have to take on the risk instead.
But you can circumvent these by over-billing contract additions/change in requirements ("avenants" in french). In theory those are limited to 20% of the original amount, but with contract renewals and if the government agency already sunk large sum of money into the project it's possible to bypass this limit.
Ah, I recognize this. It is a special level beyond workplace hell, Tokugawa shogunate hell, where the entire organization is structured to provide as much busywork for as many superfluous management layers as possible. Fifteen porters for every samurai...
I'll leave the workplace parallels as an exercise.
An article in French about it: https://www.franceinter.fr/emissions/secrets-d-info/secrets-...
In 2018 it still does not exist. The French government has decided to try again, awarding the contract to the same company.
I am not sure they actually worked on Louvois, so this is possibly another unrelated epic failure.
"In a country like France, corruption is not uncommon at that level, goes mostly undiscovered and is rarely prosecuted. "
My brother is working in a construction bussiness in France and he has a handfull of stories of this type of high-level corruption (house built for the ex-mayor, refection work done for a lawyer, invitations to Roland-Garros...). But as the author have said, it's the same thing everywhere.
And there were a slew of big international military contracts in the 80ies/90ies which were subverted to finance political campaigns (Taiwanese frigates, Agosta contract with Pakistan).
These scandals tend to be judged long after the facts (10 to 20 years), and the verdict is generally underwhelming to say the least.
This surprised me. I thought it was extremely difficult to fire people in France.
"Among the many comments, some surprised me. Seems lots of people cannot believe you can be fired in France for being 1 minute late at work. Sorry to burst your bubble, mates, but this is what SSIIs (contractor companies) were invented for. You don’t lose your job, you immediately lose the contract you are working on (no justification needed, this is what contractors are for)"
So they were not really employees, but consultants.
Still, he also wrote:
"For people who have a direct contract with the company, same story. Nothing prevents the company from saying you have committed a major blunder, fire you on the spot, and see you a couple of years later in court (Prud’hommes). Yes, that will cost them money if people choose to sue (I hope they all did). When you are unemployed, are you really looking forward to two years of battle with your former employer, even though you know you will win?"
Link to the post: https://projectfailures.wordpress.com/2018/03/24/follow-up-o...
On places where it's hard to fire people, mostly everybody works as consultants and people tend see those positions as normal job positions.
I've worked as a consultant in Germany for 13 years, and pretty much every large project has consultants in it, often half the developers are consultants. IBM, T-Systems, Capgemini and accenture each have around 5000 people doing software consulting, and there'S hundreds if not thousands of smaller consultancies.
So now you hire an engineering consultant, train him/her for a few months on the job and are forced by law to let that person go after 18 months to repeat the cycle.
(To answer the inevitable "was he the right person?": Yes, he was. EMEA was continually our best-performing sales region the whole time I worked there, and he built our EMEA sales infrastructure from the ground up. Some years later, after the company exited, most of the senior people regrouped at another startup. He was in charge of EMEA for a few years, and then he was promoted to CEO.)
However, most UK employers would use a probation period or initial fixed term contract (true employee with a fixed end date), rather than a non employee contractor.
It is unlikely your company hired the guy as a contractor because the set up for becoming a self employed contractor (your bank will hate you, an umbrella company takes 10% of your income, you have to register as self employed abd fill out extra tax forms for ever), would probably kill a hire, if you weren't hiring an existing contractor, who wouldn't hang around to perm.
Maybe it was an initial fixed-term contract.
> The same coffee machines are switched off whenever officials come to visit the site, to give the impression that everybody is at work.
Inconceivable! I'm convinced this person worked for aliens in human skin suits. Think Edgar from Men in Black. Obviously missed the memo from high command where it is mentioned that humans perform better when caffeinated so supply them with plenty of free coffee and tea to keep them productive and ready to harvest, er, review.
I think using C++ was literally the least of their concerns.
I was programming back in '96 (recreationally and as a student, not professionally) and C++ would not have seemed like a good choice even then.
Java was still new and slow. There were some interesting RAD tools, but those weren't particularly well suited to 'large' projects.
(Of course, we were sub-sub-contractors working only on designated parts of the application. The stuff I did touch was consistently sane enough, though, that I don't think I'm too out of place in positing a legit minimal degree of not-terribleness across the rest of the project.)
All errors was reported as : syntax error on line 1. Fun times.
Surprised they didn't get fired for reading/learning at work when you're paid to be programming all the time. Although I've never been fired for reading at work, I've had it made clear on multiple occasions at different jobs that reading wouldn't be tolerated, and I was already down a couple of strikes.
Outside of work hours, of course. You're paid to program, not to learn.
At the end of the day you're not paid to program, you're paid to solve problems, and typically that's easiest to achieve by producing code.
Sometimes the problem is you don't know a particular language or toolkit even if it's the best fit for a problem domain...
It's on you for hiring someone that didn't already know everything. Don't expect them to put in free time to understand whatever infrastructure and code you have in place.
And isn't programming a matter of continuous learning? How is anyone supposed to do a job like that and not be learning? You really expect your employees to learn everything they need to do their job outside of work? WTF?
Surely what they learnt at bootcamp is less than worthless.
Story time? Please?
You definitely seem like a good prospect for the following "workplace of hell" saga? ;)
C++ as a language for an enterprise business logic software like a payment system in this case? You put together Stroustrup, Thompson, Pike and Torvalds and they still would probably fail to deliver a fully working project or at best it would be very past the delivery schedule (until of course they "cheat" and develop appropriate DSL and compiler/runtime for it first :)
Closest I've been is when an agency sold my time to another agency which sold my time to the end client, who paid me with "profit" from insurance money ( the end client was an insurance agent ).
And as I'm not in my 20s anymore and I look at how government related IT services work, I'm so much afraid about everything else happening around me. Questions like "What about the tram I use every day? There should be a company maintaining these things. Probably is hell there as well."
1 : https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law
Have you ever noticed how many smart French programmers there are in the USA? People vote with their feet when given a chance.
> With so many files in store you may think that two people working on the same file would be rare, but it turned out that most work happened within the same 100 files or so.
Not really surprising, unfortunately. This is a hallmark of the Big Ball of Mud. Thousands of code files and yet people keep tripping over each other.
Just another proof that if a product involves the word "Synergy" in its marketing, you should run away fast.
"they had to pay soon for Free Software. None of them ever mentions ‘Software Libre’, but they all know about ‘Software Gratuit’. "
In French, we have two word for Free: Libre is for free as in free speech and gratuit is for free as in free beer.
But no commonly-used adjective form of that noun.
I think these two actually go hand-in-hand. Happy Monday!
Can someone explain the meaning of this? I think something got lost in translation.
> what are they going to do if you don't show up
They will simply not pay you.
What you do when you're deep into a project like the OP describes is to quit your job by telling your manager that he's the worst you have ever worked for. Then one of three things happen:
1. He/she asks me to stick around for two months. I do and get paid regular salary during.
2. He says "hey, if you want to leave today, that's fine with me". I do but I wont get any more pay checks.
3. They are offended by my critique and says "walk away from you computer right now and never come back". I get paid for two months without having to work.
When #3 happens it's excellent because you will have two months of pay and enough time to find a new job if your resignation was in the spur of the moment. And no need to worry about bad references. When my up and coming boss calls my last horrible boss, someone who I happily divorced, things will work out fine.
Even though (middle?) managers are usually full of prestige and are quite easily offended, #3 has happened to me only once.
Although most don't, I try to utilize or take advantage of the system to the max in my quest to find a decent work place/project. I job hop a lot.
But then I wasn't leaving because the place was a train wreck; I was still engaged, and liked the team I was on. Had that not been true, it would have been a bad move on everyone's part.
Employees on the other hand have NEVER been docked pay in New Zealand and you are in NO way legally obligated to turn up for work. The only case you'd experience penalties is if you're a doctor, nurse, teacher and the like where you're likely to receive license/registration repercussions from a governmental board.
I'm not sure if it's ever been in any of my contracts, but it is apparently an option.
Very different to being liable for finding a new hire.
The employment court of New Zealand is very favourable to employees. Even if something was contractually obligated - it can easily be null and void by the court if they deem it unreasonably overreaching by the employer.
They would fire you for grave offense (I'm not sure what the right word in English would be). But even firing or giving one's notice is long here, around three months.
So in this case, what could happen? either you're a competent engineer, got just hired and sent to this circle of hell, you'd probably leave the next day, no regrets; or you're radically incompetent and you just stick to this job and salary, until 2 months and 29 days later the manager just fires you because you're no good (and he can). Rinse, repeat.
Also I did not know the maximum duration of trial period has changed, thank for the info.
EDIT: unless personal boundaries would be trespassed.
However (to me) there are some cultural issues which make things even worse it seems : a VERY rigid chain of command structure and a strict 'political' hierarchy which makes changes happen very very slowly and not always towards the best outcome (for the project, billing is $$$ great).
As mentioned each country has issues, but I don't know if I could go into such a strict hierarchical corporate environment.
I thought that with Golang and the popularity of static linking for apps in Docker containers that this was now considered acceptable again (tongue firmly in cheek).
They would already have CI/CD processes in place to rebuild the binary/container, run regression tests and redeploy the application/container to production, surely?
So what difference does it make if it's one or one hundred applications/binaries/containers then?
Also: we chose C++, because it is fast.
Performance is meaningless if the code is not correct.
After all, I can make the code arbitrarily fast if I'm not going to be held to any standard of correctness: It always returns "FOOBAR". Done, and very, very fast.
> Also: we chose C++, because it is fast.
That is a bit naive. C++ is a standard, so how fast is a stack of paper?
When your code is only fast because it does the wrong thing, and fixing the problem takes much more overhead.
Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf
Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.
Obviously its a case of the correct tool for the job and depends heavily on the type of software you are writing, but in most cases its a different type of optimization that is needed for Python code.
No language implementation is "too slow" if performance doesn't matter.
> … Numpy is apparently not far of C in terms of performance
As-fast-as C when it is C (or Fortran or assembler…) :-)
Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent).
Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers?
I certainly wouldn't.
Yes, an arbitrary algorithm will probably perform significantly faster in C++.
But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.
John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC.
(The C++ implementation is at 0.939, GCC 5.4.0 -O3.)
This is probably a better comparison:
As-fast-as C when it is C (or Fortran or assembler…)
(I happily and productively used C++ for many years; there's no hatred in the above sentiment.)
So this was a project for a government agency in France that limped along for years.
Ohh, which versioning software comes from Sweden and is so bad? Got curious about this one.
Performance would strongly depend on the power of the server and a bunch of other things. Also, apparently builds are done centrally.
A get the shivers just thinking about it.
See also these two links.
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".
Many such cases
I am interested in seeing the source :)