A good thing to think about.

This is short and to the point. Productivity. My personal reflection to this, he blames the Operating System(OS). It is not actually that where the problems is. You can get a productive experience on most OS:es. The problem is the software put on the OS.

Opinions, everybody has them.

There is plenty of C++ hate to go around. There are forums, blogs and social bookmarking sites where the hate sometimes appear. This is usually posted through a web browser. The post are about how bad the language is in managing memory(because it doesn't), how hard it is to parse(there are some fun ambiguities) and so on. People claim in these posts that it takes a genius to get all these things right. But the thing is that bothers me is that... Ehm.... the majority of the web browsers are implemented in C++. In other words, they rely on the very language that they hate so much.

Further, this is the fun part. By anecdotal evidence, the people that spread the most hate about C++ have their head up so far the "Web 2.0" ass, that they don't see that their beloved web experience is run by C++.

Sorry and hate to break it the "Web 2.0" fanboys C++ is good for something. And it does not take a genius to program with it. Your favorite language of the hour is not good enough to build a complete web browser, that can bring the "Web 2.0" experience to people. Prove me wrong please.

This is getting out of hand now.

Adobe has released their latest Adobe Reader. Funny stuff can be read here and here. Yes if you want to read PDF:s with the adobes own reader you must have atleast +200 megabytes available on your hard drive.

This is a sorry state of affairs. This is not about bloat anymore. It is intrusive behavior by the software company. It is not new in the industry as a whole. Microsoft has done it, the redistributable for .NET 3.5 is a whopping 197 megabytes. Yeah old Realplayer stole file associations for media files types(persistent rumors say that they even didn't support). Apple did a nice trick with an update.

This is not about bad programming with way too many features A.K.A. bloat. This is wasting the resources of their users without "asking" them what they want. If they even bother to ask what the users want they have to take an action to avoid the feature(s).

Now ask yourselves this! What gives Adobe, Apple, Microsoft and RealNetworks the right, to steal disc real estate, your file associations and install other software that you downloaded?

Skills shortage?

Found on the web: Skills shortage hits games firms. Poor poor game companies, they can't find skilled slaves anymore. They blame it on math education and whatnot. Well, sorry but your reputation is not that good. If the reputation was better and it would be a good job, *gasp* people would actually bother with the necessary math.

It is about eight years ago I visited a game company with a friend. My friend knew a member of the team that did work on the Refactor 2 engine for Battlefield 1942. We visited him at his office, in the evening around eight or nine. Because he was still working. About two years prior to the release date.

Usually what I've met game programmers they are insanely skilled at what they do. I can be humble and say that I'm not nearly as good of a programmer as most game developers are. But also AFAIK the average game developer drone is not paid that well compared to the skill set and the hours he puts in.

Is there a shortage, I would not say so. Most people don't want to work under poor conditions for a lousy pay and they even have to know advanced math. People that know advanced math usually are smarter than that.

About outperforming STL

I can't really say that I'm chocked by the conclusion in the article by Sergey Solyanik called STL vector performance. But it is a fine piece on what is wrong with microbenchmarking. It is also a case study of people who critique C++/STL should actually learn it before they critique it.

I've spent a great deal of time in learning C++ and STL. It is complex language and library where there a number of finer points to remember. There are a number of other things that I cringe on but I'll limit myself to "microbenchmarking" and actually learning the library/language.

You can make any language/library look bad with a microbenchmark. Because it limits itself to a couple of features and a particular way of solving a problem. The biggest problem in the STL vector performance post is that he is comparing a narrow problem of filling an array with values and filling the same values into a much more complex and capable vector template. All that complexity is adding abstractions that cost a fair bit of cycles that in the case of integers can be outperformed with realloc or if you have known size preallocating. The post revolves around a very unclear problem. What exactly is vector bad at? This is where the language and library knowledge comes in.

As a C++ programmer I am in the habit of using vectors and arrays the same way. Because the STL library implementation gives a nice little detail with vectors. The elements of a vector are stored in a continuous area of memory exactly like an array. You can access the internal array of a vector through the [] and it will have same speed as a regular array access. But to keep this continuous array of objects this way it needs to reallocate the memory when you need more space for your objects. i.e. insertions of objects at the end of vector is not constant. This the complexity of push_back, check if you need more space before you insert and actually doing an insert. For a vector of int:s it could be quite large compared to a array of int:s reallocated with realloc(). If I'm ready to sacrifice access speed to the elements I could use something like deque from STL instead. Insertion in the front and back is guaranteed to be "constant", because it does not provide the guarantee of continuous storage. Internally it looks quite different, read all about it in vector vs. deque.

What if you need fast access by index? You should use a STL vector and fine tune your growth with reserve to increase capacity. Adding to the vector with push_back might still be costly depending on what you are pushing. Because when you reserve you don't actually add anything to the vector you just make sure it has enough memory(a.k.a. capacity) when you add more objects onto it. Read all about it in Uses and Abuses of Vector.

Further comment on "How software companies die!"

People that work with sales and marketing are for software developers a strange bunch. For a software developer it is totally nonsensical why anyone would come up with ideas like: Gluing a couple of eyes on a rock and call it a Pet Rock. But marketing people see how brilliant it is. They think: "You can sell anything with the right marketing!".

But you can't sell everything with marketing. It depends on the nature of the "product". As soon as the buyer expects it to something and be usable the meme of "anything can be sold with marketing" becomes useless. Marketing and sales do not understand the nature of the beast of software. When you cram in more features in the poor developers schedule two things happen. They have less time to fix old bugs and the buyers (sometimes referred to as the market) get confused by too many options and features. If you ever try to fight a marketing department when they say "the market demands more options and features", you will get slammed each and every time with "developers are too dumb too understand the users" or "developers don't understand marketing". So when they get their way the result is an unmaintainable mess of buggy bloatware with features no one knows how to use. Thanks marketing.

Are there any solutions for this mess?

Lets look at a related business of hardware. Processors to be precise. I feel like an old fart when I think back to the dancing clean room guys. But that was exactly what happened with Intel. Marketing took over because they had a successful campaign with brightly colored people dancing telling about MMX enabled processors. They started to butt in to the engineering decisions of the company. Intel had an CEO that allowed that. To make a long story short, it resulted in a Pentium IV with a magical number of 3.2. But a lot of engineering compromises where necessary to reach the magical number. Competitors caught up, they had engineers making R&D decisions. Resulted in a different gamble from their part. AMD trounced Intel with good engineering, they wouldn't have had the chance if Intel had made decisions based on technical merits than reaching a magical marketing number. Intel shifted to an engineering based decisions and they are making solid products ever since.

This is also very true for software. It is better to make solid products rather than market the crap out of compromises.

Sounds awfully familiar.

This pops up now and again when you read about software engineering and programming on the web. How Software Companies Die by Orson Scott Card. It is scary how often you see this pattern repeated. It seems to be repeated at my current workplace. Considering it is written in 1995, the remaining question is will people ever learn.

I'll post a longer comment on it later.

Here is a scary thought for you.

The faith of billions of euros(or dollars or whatever currency you prefer) are decided by Excel sheets with quick n' dirty VBA hacks. These hacks are sometimes built by people with little or no training in software engineering. This is the scariest bit of information that I have got from the SocGen scandal. Jeromé Kerviel isn't a computer genius, he knows a little VBA. Don't believe me read this.

Who would have known, an Excel bug could trigger the next stock market crash. Microsoft decides the faith of more money than they are themselves worth.

I don't know about you, but to me this looks like an accident waiting to happen. And if we don't do anything about, it will not be pretty.