Monday, August 3, 2009

Why big hardware corporations can not write software?

I think one could write an entire Ph.D. thesis on this subject. Master's thesis could be to short and not cover all the aspects/problems the large corporations are dealing with.

I experience this sort of problems everyday since this is the kind of corporation I currently work for. It is extremely interesting to observe the behavior of people working here and it would be such a waste if I didn’t share some of my experience with you.

Why do they build software if they are hardware experts?


Well, the thing is that modern hardware has to go together with some sort of software. It needs it to function properly or/and to interact with the user. The devices the company produces are therefore useless without appropriate software package. Since the company builds the device itself, they are also the ones who understand it best. They simply know how the software should interact with their product. This knowledge is very seductive and makes them think: "Well, we've build the hardware, building software is just the formality then".

Since there is no way to go around this and some kind of software has to be build in the end, many companies choose to build it by themselves (and keep the implementation details "secret").

Why build it yourself, why not?


This is actually a very good question. If you have no experience with building software, then what do you do? Yes, you outsource it to someone who does! This idea is not that bad but only under one condition; you outsource the project entirely to the professionals who really know what they are doing! The problem of most hardware companies is that they want to go cheap. They simply outsource their projects to places where the so called "programmers" do not cost a lot. ("You know, the software is just this virtual piece of functionality that we need but is naturally of lower importance for the hardware itself, which our main product!"). This is the place where they are totally wrong and the "numbers" that management has seen at the beginning of the project turned out to grow up exponentially after delivery of the first working version of the new so called "software package".



So what do they do when they see the problem?


First of all they want the code back to their development centre. However, as soon as it’s there they realize there is no one who understands it. (I think that even the best software developers would have problem with it.) So what do they do next? Yes, they look for people who do (or at least say that they do). This is actually the place of their second failure. When they hire their new software developers they actually don’t know what kind of people they want. This problem may be well explained by the company’s lack of knowledge and experience related with building software. The group of their current hardware (or old software) engineers is simply not able to recruit good software developers since they themselves don’t know what the difference between "good" and "bad" is. So after asking the questions like: "How much experience with C++/ Java do you have?" or "Do you know what Ajax is?" they tend to recruit trashy people who have just a little idea about the art of software development.

But that's not all...


Hardware companies usually do not use, understand (or want to understand) the agile development methods. They stick with their waterfall models (or waterfall-like models) and think that something which was suitable for hardware can be also suitable for software. Well, it is not.

The typical problems they face:

  • Lack or badly defined requirements

  • Lack or bad architectural design. No "design for change". ("who needs architecture after all? We need to deliver soon so please start coding now!")

  • Lack of good software developers

  • Lack of unit, integration and system tests (no comments...)

  • [ ...write some yourself... ]


I was recently on a job interview at the typical, medium size "software company" in Berlin. These guys really impressed me with both, their professionalism and their recruitment process. I have spoken with the project manager and one of the lead developers. They knew absolutely everything about their product, developers, development methods they used and project management tools. They were even able to draw a simplified version of the architectural design of their application to explain me how it works and where they see me in that project. I didn't accept that job because of personal reasons and partially because they could not offer me the same or better financial conditions as I have at the moment. Now I kind of feel it was a bad decision.

Yesterday I was on a job interview for the other department at my current company (see, I am a "software engineer to rent"). The interviewers were totally different. They didn't know what they wanted from me, asked inappropriate questions, tried to convince me about how .NET is superior to Java technology without any reasonable arguments. They made me angry and in the end offered a JavaScript coding position for some sort of user interface they don't have requirements for. Can you imagine this? This was simply a waste of my (precious :-)) time. The funny part is that even though I don’t fit that position at all, they will probably accept me.

In the end I have one short message to all hardware developers. Guys, wake up! Software is a real deal! Be careful who you hire and don't forget to get rid of all that bad, useless and incompetent, so called architects, developers and most of all project (or product) managers!!! I want to be able relax when I am using my new digital TV receiver or get X-Rayed at the hospital, so please, get educated and do it right!

No comments: