Skip navigation

Usine a gazI had the privilege to be working in various professional environments over the past 20 years, from small-size businesses to enormous corporations. If you are too busy to read through this complete post, just remember this: avoid big organizations at all costs.

Big organizations means heavy human structures with pyramids over pyramids accumulating middle-management staff who do nothing but report above what was done below. This is not a cliché, I have seen it countless times in several countries over three continents. Some people will feel comfortable in this kind of environment, but I have to admit it always ended up badly for me. From the middle-manager who presents your work as his and gets all the bonuses for it without even a “Thank You” to top-executives giving orders without having a clue about what you are doing, I have seen enough.

Let me try to summarize in a few points the sure signs you are in the wrong place:

Presence is more important than actual work

You can work as much as you want for any level of quality you are willing to put into it, the only thing that matters is to be seen leaving late. You are not even compelled to do actual work after 5pm, just be there, have discussions around a coffee with your colleagues, browse reddit, do whatever but staying in the premises until night comes is key to your next raise. The underlying concept is that you should devote your life to your company. Forget about family life or having a life at all, you are paid to spend your waking hours at work, no matter how much work gets done during that time.

Write whatever you want but do it with Word

You can prepare the best report ever on your favourite topic, if it is not properly formatted in a Word document displaying a company logo and official colours, it is worthless.

Computers are MS machines

Normal people run Windows, they use Internet Explorer to browse the web, they send emails with Exchange, and edit documents with Word. If your documents contain less then 10 bullet points per page, make it PowerPoint.  Between 10 and 20 it should be Word. Above that go for an Excel spreadsheet. IETF and RFCs are synonyms for open-source, i.e. a pirate culture.

Java is the only language, XML is his messiah

Other programming languages are for scientists at MIT. We just want to use whatever the rest of the industry has chosen. If everybody else is doing it they cannot be wrong.

Software is code; programmers write it

Software engineering is a fancy name for cheap labour pretending to do complex stuff. To build software you need pages and pages of code, which are nothing more than straight ASCII files. Programmers (or coders) are paid to produce them by the line. Code line production scales linearly with the number of coders and number of days spent coding. Programmers are paid to type up computer code.

Quality does not matter as long as customers pay

This trait is very much found in every closed market where customers will pay no matter what: the military breed these companies like mushrooms, but all sorts of administrations are found here too. The contract says we are paid to deliver software so we did. If it cannot be used, somebody will get blamed and support will be paid, no big deal.

Keep information for yourself

You should report all valuable information to your superior but never propagate it to levels below yours. Informed people tend to do terrible things, often questioning or challenging executive decisions while they should be sitting in front of a computer entering computer codes. The best way to keep your position is to keep information to yourself and only circulate what you must.

Human Resources Dept is more important than Human Resources

Human resources are disposable. Finding candidates for any given job is extremely easy in times of crisis. The HR department however will be the last one to leave the ship, so trust them blindly with all recruitment and departures.

After 20 years in business it seems there are more administrations out there than interesting companies to work with. Abandon all hope, ye who enter here.

Usine a gazSo here we are: it is 2008 and some people out there still think C++ is a neat idea. To the point that the latest Stroustrup interview shows him confident about the future of his pet language and it seems nobody has told him yet.

So what grudge could anyone possibly have with the language that gave us most of Windows, Photoshop, KDE and Microsoft Office? Before you pick up the flamethrower, let me detail things a bit.

Complexity

Complexity is a key issue. Initially designed by a single man or small group, the language has grown by accretion over the years and suffers the dreadful “Design by committee” feature that gave us e.g. CORBA. If you have any experience working with C++ you know what I am referring to: you have spent countless hours learning how to use such or such feature, doing the exercises, practicing on tiny meaningless projects where everything is clear, and suddenly you are faced with a pageful of code where nothing makes sense. Nothing. You grab that book again, go through all the details and cannot find what the hell is written on screen. You know it compiles, even if the compiler swears at you in Russian, but you still do not know how. And you will never know.

In Effective C++”, Scott Meyers warns about the many sub-languages contained in C++. He mentions C, Object-Oriented C, Templates and the STL, but if you look closely there are about as many flavours of C++ as there are compiler vendors, multiplied by the number of platforms, multiplied by the number of programming rules and recommendations, multiplied by the number of active programmers. On top of that, the ISO committee releases new versions every now and then to spice it up. Faced with such a huge mountain of complexity and sub-dialects to learn, the only sane reaction is to focus on a smaller number of topics and try to master them inside out until you feel confident in your programming skills. The best C++ gurus I have ever met admit they master around 90% of the language, which is quite sufficient for them to produce their share.

As a Project Manager, you are given the task of producing a quality piece of software to fulfil a number of objectives. You have 10 expert C++ software engineers ready to work for you, what could be better?

As it turns out, chances are that the 10% C++ slices of ignorance for each software engineer do not overlap. This will translate to parts of the project that can only be maintained by one programmer. If the guy leaves for any reason you are hosed. Nobody can read or understand what was written so you end up re-engineering parts of it, finding workarounds, encapsulating the working parts in something you can actually understand and maintain.

This is still rather theoretical so let me pour some more reality. As much as it saddens me to say it, I have no Nobel Prize in computer science and neither do most of the programmers I have been working with. C++ complexity is just out of reach for most engineers I have met, whether they wanted to admit it or not. This should not be an issue because after all, we do not write programs to please a compiler but to achieve a goal that is in one way or another related to humans and their well-being. I believe a good software engineer should be able to design a useful system no matter what language is used for the implementation. What I observed was just the opposite: after a few months working on a C++ project, we realized that we were spending more time fighting the language and the compiler than actually implementing something useful. Bring in enough C++ experts and witness endless sterile discussions about copy constructors and inheritance when we should have been talking about usability, feature enhancements or backward-compatibility for old data files.

We should not have to think twice when using a tool. The more we need to think, the less we are able to actually use the tool for anything useful. I have seen too many projects caught up in the web of C++ complexity, where the main activity seems to be sheer survival against the language.

Binary (in)compatibility

Second issue: binary compatibility (ABI). The way C++ objects are named in an object file has not been standardized until quite recently. Until then, it was just impossible to link two objects produced by two different compilers. This may not seem too important at first, but let us review the consequences:

You cannot link your code against a binary-only distribution of a library.  For library vendors, it means you will have to release the source to your code or die. This may seem like a good case for open-source addicts, but in many cases a binary release solves a lot of issues.  Integrating a third-party library as source code means you have to bring in all the needed compilation environment, which may or may not be compatible with yours. Your problem was to integrate an external library, now you need to figure out how to compile it too.

The next consequence is more dramatic. Imagine you write an OS in C++, where all base libraries and system calls are C++ objects. Since you cannot mix objects compiled from different compilers, you will be locked into a single compiler for your system, and this also holds true for all developers working for your OS. Single point of failure: the whole OS future is tied to what was initially a developer tool to transform C++ into assembler. Microsoft has found a workaround by declaring all Windows interfaces using C constructs to avoid locking all Windows developers into one single compiler. More than technical reasons, this would probably have been the cause for European Union (rightful) accusation of monopoly.

You may well say that this drawback is something of the past now, and I would like to believe it too, but I see too many old systems still being used in production all over the place and they all have issues with C++ compilers due to ABI incompatibility. It may take decades before the problem goes away.

The very fact that it has taken all these years to come up with a unified ABI seems to hint about the nature of the C++ standardization committe talks: vendors lobbying to protect their interests, rather than computer academics talking about pure ethereal concepts. I was not there but that is what it looks like seen from the outside.

That may be right for others but not for me

As a single programmer, you may not have realized that limiting yourself to a subset of C++ could have consequences. You feel talented at what you do and you certainly are, but the issues come when you start working in a team, i.e. any decent-sized project. You may have been bitten by binary incompatibility and you may think that is something of the past now. If you are lucky enough to only work on brand new projects working on future OS’s, keep your head high and ignore the argument. For all other people living in the present, you have my sympathy.

Another thing I used to hear was: “if C++ is so bad, why is everybody using it?”. This was 10 years ago. Today, most software engineers I know would not touch the thing with a 10-foot pole. Judging from what you can read on Slashdot any time C++ is mentioned this seems to be a largely shared opinion. Though the discussions tend to end up in the usual flamewars, many raised arguments run very deep. Pick any recent discussion on the topic and check by yourself.

If there was no other choice of programming language we would all probably figure our own way out, but today we have many more languages that are all better adapted for the task and do not force us to take this kind of unneeded risk on our projects.

So go ahead and flame me. This will not change what my eyes have seen over the last 15 years in many, many different projects taking place over different countries and businesses.

Relevant links:

A few years ago, I was hired to work as a consultant on a software project for a large French tech company. What I have witnessed there is beyond everything I could possibly have imagined in terms of software engineering. Far more serious than just a lack of professional competence was the utmost contempt for human dignity which at some point made me compare the whole experience to (what I imagine can be) jail. What I relate here is a selected list of topics that should illustrate my point, but check out by yourself.

Scope

Develop a piece of software for a government agency.
Complexity is about the same as Windows Paint with a few twists.
Not kidding.

Government pays a few million Euros upfront, development is scheduled for two to three years. Company hires a couple of developers to start the job, and keeps doubling team size every 3 months or so as cash starts flowing in.

7 years later, the project is still not in any decent shape.  Penalties are running in several thousand Euros per day.  Management decides to reduce costs and fires all experimented people, hires people with little or no software experience.

10 years later, given the disastrous state of the project, middle-management decides to hire some people with software engineering experience to get back on tracks. Average turn-over for the newcomers: 3 months, the legal time to leave your job in France.

12 years later, the project is still active. The company recovers daily penalties by billing ever-increasing change requests to the government. The year is 2008.

Figures

  • 6 million lines of code
  • C++ based
  • 50,000+ classes
  • C++ flavour in use is obsolete, locked into compiler version, which is only distributed with one (unmaintained) Operating System.
  • CORBA-based
  • Database software from a company gone bankrupt
  • Several layers on top of each other to handle the Graphical User Interface, none of which actually maintained by the authors.
  • Build takes 48 hours on 32 parallel machines.
  • 40 to 50 simultaneous processes needed to run one User Interface
  • No dynamic library linking: executable sizes in the range of several hundred megabytes
  • Startup time is about 15 minutes
  • Mean time between crashes: 30 seconds to 30 minutes

No software engineer will tell you that C++ is an easy language.  In fact, it is probably one of the worst computer languages in terms of complexity. It is actually so complex that even its creators admit that they still do not master all of it. See a famous spoof Stroustrup interview here:
http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

Faced with such an incredible maze of bottomless complexity, people tend to react in a different way. The geek wannabees have all heard about C++ and want to show that they can do it too.  They dive into it without fear and get maimed beyond recognition, spending countless hours trying to figure out how a pageful of gobbledygook crashes endlessly without apparent reason.  People with more sense quickly turn to other languages and other projects. Life is too short.

Maintaining a large body of software in any language is a hard task. Imagine a team having to maintain 6 MILLION LINES of code and you get an idea of how far insanity can reach in the realm of software engineering. 6 million is a big number: if you wanted to read all the lines quickly at one per second, you would spend about seventy days non-stop in front of your screen.

Just to give you a taste, here are two anecdotes:

One developer was given the task of checking why right-clicking on the interface completely froze the application. After several days of careful examination and incredible amounts of patience, he found out that right-clicking worked fine, only that it took about 45 minutes for the context menu to popup. Menus were all dynamically generated from huge (static!) content every time you right-clicked the main window.

At some point end-users reported that “Load data from CD-ROM” did not work at all. This one took several weeks to sort out, but in the end the bug report was flagged as ‘already solved’, because data were indeed being loaded. The only point was that it took 7 straight days for 700 MBytes to get in. Patience is a virtue.

Version Control gone wild

It took several years until one bright guy in the team came up with the idea of using version control tools. First attempt was not convincing, so the team switched to another system, then another a couple of years later, loosing all history with each change.

The tool that was finally chosen is a disaster with a graphical user interface, an abomination coming directly from Sweden. A team of four people is actually dedicated full-time to performing most maintenance issues on the version control software, which gives things like:

  • Doing a first checkout requires taking an appointment with the version control team, usually granted a week later.
  • Editing files is not permitted without authorization from middle management. You have to tell your manager in advance which files you want to edit, then send an official permission request which gets filed with the version control team who may take action within a couple of days.
  • Every modification of the code triggers branching, which means you have to merge back all modifications you receive. 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.
  • Check-in needs to go through a painful procedure whereby your code is reviewed by automagic bug-detecting software and eventually by middle management. Needless to say, this does not prevent bugs from creeping in faster than developers can remove them. A closer look at the number of registered bugs showed that every defect correction brought in twice as many bugs as it corrected.
  • Versioning is simple. Old software is version 1, today’s software is version 2, software in the future is version 3.  Nobody can actually tell which version has been delivered to the customer.

At some point, an official delivery was scheduled, totally independent from any kind of planning set within the team. When the day came, the customer was actually sent a blank CD with installation instructions because nobody had been able to build the software in weeks. The customer found out they had been delivered a blank CD, officially complained, and was given an old version to replace the previous delivery. They found out because the displayed date in the “About” box was the same as last year.

Peopleware

Pay peanuts, get monkeys.

With a large number of people without any software engineering experience, is it really a surprise that bugs keep creeping in in vast numbers? A really bright manager must have realized that human costs were the main source of cost in a pure software project. Not at all deterred by this extraordinary discovery, he decided to fire all people with any kind of experience but keep all managers in. It was not uncommon to see “C++ for dummies” on many people’s desks.

Meet the Team

55 people in the team: 20 developers, 35 managers.
That’s right: more managers than actual developpers.
Managers keep organizing meetings where they show the same PowerPoint presentation over and over ad nauseam, while developers kill time by chatting in the vast open-space office.
Few managers have any experience with software engineering. At that time SCO was suing IBM about Linux. Even if the whole thing was a bluff, it really worked with such people who all understood that they had to pay soon for Free Software.  None of them ever mentions ‘Software Libre’, but they all know about ‘Software Gratuit’. Needless to say, the project is peppered with GNU libraries all over the place and these guys have absolutely no idea this turns the whole thing into a vast unshared GNU-compliant project. But hey, given the abysmal quality of this thing, nobody will ever insist that they release the sources.

Technical knowledge is low. Few people know about Internet, those who do think it is only made for porn. Mentioning you have seen something on the Internet brings you winks and smiles.

Welcome to Hell

The whole experience could have been funny if the top management had not decided to behave like nazis in a concentration camp. Just to give some examples:

  • It is forbidden to come to work after 9am. One day, the site manager stayed behind the main gates and fired on the spot every person who came in after 9.01am, including a number of managers and sales.
  • Smokers take more pauses so produce less. Management tried to force everybody to stop smoking by coercion. Did not work.
  • Coffee machines are regularly out of order for several days. Somebody who drinks coffee is less productive than somebody sitting at his desk, typing away precious lines of code.
  • The same coffee machines are switched off whenever officials come to visit the site, to give the impression that everybody is at work.
  • Toilets are the most disgusting I have ever seen in a company. The idea is probably to increase productivity: spend less time in the loo, you work more (and better).

You are probably wondering now why people kept coming to work in such an environment. The first and main reason was the deep economy crisis France was going through at that time (and still is today, to a certain extent).  Having a job and a salary was considered a privilege, no matter what conditions were attached.

Another reason was that for many, this contract was the first they ever got with a real company. Without any reference it is impossible to gauge how much your job sucks. Most beginners thought it was perfectly normal to be forced to be there at 9am sharp or be fired, when absolutely nothing imposed such a constraint except the sick mind of a manager.
As to how a government can let such things happen: we all know how it works. The guys in charge of budget at the ministery are pals with the top-management in a number of companies. In a country like France, corruption is not uncommon at that level, goes mostly undiscovered and is rarely prosecuted. Apparently this is not reserved to France. I have heard the same stories a little bit everywhere in Europe and the US.

Next time you think your job sucks, think again.

Relevant sites: