Anything that can go wrong will go wrong, as stated by Murphy's Law.
My father's company has been developing a piece of application software. I do not know how much I can disclose, so I will just say that it is supposed to increase productivity, especially in the insurance industry. Anyway, this is just the background and it should not really matter.
Learnt that a contractor will charge a few hundred thousand dollars (Hong Kong Dollars) for the product, the company decided to develop it in-house. Not previously having a developing department, the company built one from ground up, which had just a handful of programmers. The project manager is an acquaintance of my father. He operated a software firm, which was defunct due to mismanagement.
The company based the department in Shenzhen, Mainland China to cut budget. Consequently, most of the programmers are Mainlanders.
In a few short meetings, my father explained to the project manager the functions and requirements of the application. Every week, the whole team would gather, reflect what they have done in the past week, update the schedule, and plan on what to do in the next. However, most of the meetings were useless: nothing was discussed because nothing is achieved in the previous week. Even if something is discussed, it is mostly complaints from the management level that the application does not conform to the requirements, and complaints from the development team that the company constantly changes requirements.
Two years later, in an expo, when the company was trying to promote the unfinished product and invite investors, they learnt that the application must be on-line. A set of data may even possibly be accessed simultaneously by different users, at different places. While keeping developing the current, single user version, the company started to develop a web-based version.
Soon after that, the single user version is completed, and is shipped to several insurance managers. Not until then did the company find out that the software is incompatible with Windows in Traditional Chinese (and every other language except English and Simplified Chinese). Apart from that, the programme is very buggy: marketed features do not function properly, and crashing is a usual visitor. As a result, the company cancelled it and focused on the on-line version, which was still in its infant stage.
Year after year, the development team worked on a moving target, and they saw no prosperity of either the project or themselves. As the new version slowly grew, developers started to leave. When the software is almost finished, the company lost all developers.
When the company wanted to hire new developers to continue the project, they faced a serious problem: they can hire no one. The web-based version of the software used ASP as their back-end; the company simply cannot find programmers that know ASP. Deemed that ASP is outdated anyway, the company decided to hire new programmers to re-implement everything in a newer language / platform: C# / .Net. Another two years have passed without anything new came out.
To date, few hundred thousand dollars are spent; the application is still remote from alpha stage.
Still holding hope in the product, the company wants to complete it collaboratively with a software firm. Luckily, the company still holds the old source code and the rights of it. Hoping to smooth transition, I went to Shenzhen earlier this month to see what is salvageable. The answer is, unsurprisingly, not much. Maybe most of the code base can be reused, since only the framework is done in the .NET version; however, without any documentation, it is very hard to understand what the code does. We do not even know which part works and which part does not: A month or two might be needed just to figure that out.
What went wrong?
Almost everything went wrong with this project, right from the beginning.
The first thing is totally underestimating the cost of the project. If you consult a professional software firm the cost of developing a piece of software, you should genuinely believe their answer. If you do not trust them, you can always consult another firm.
Once you convince yourself that price offered is reasonable, however, do not think you can lower it, by whatever means. If it takes a professional firm that much to build the system, it will certainly cost you more if you do it yourself. Remember, you find those firms for their professionalism; otherwise you would not find them in the first place. Sadly, many people do not think software development is a serious business and hence a professional field.
Of course, a software firm charge for is not the cost, but a price that will make them, as a company, profit. However, even considering this, you will still spend more money if you do it in-house, because you lack experience, knowledge, personnel, and professionalism.
Compared to paying a software firm, the cost of developing in-house will likely be a double, at least. Again, do not ever think you can lower the cost by any means, inducing but not limited to hiring developers at lower salaries, cutting some “unnecessary” job positions, and neglecting “superfluous” software engineering practices. Actually, all these practices are what make cost surge and are what you need to avoid (although not all that you need to avoid). Incidentally, the company did all three.
You do not want to pay low salaries to developers because they come in different grades: there are good programmers and bad programmers. Technicians and programmers in Mainland China are cheap for a reason. If you pay a high salary, no guarantee can you get to hire a good programmer. However, if you pay a low salary you are guaranteed to have a bad one. A bad programmer does not only lack the productivity of a good one; a bad programmer deprives productivity from others in the same team. Bad programmers might do something you would think to be unthinkable, such as refusing fixing bugs in their code, or introducing (not finding, but introducing) bugs in others' code. If anyone has dependencies on these codes, progress will be hindered.
Now imagine a team comprises just of bad programmers. This team will not only drag productivity of it to a lowest point, but also diminish efforts of future teams that work on this project or other related projects.
By neglecting “unnecessary” personnel and procedures, the company removed everything connected to quality assurance, and consequently everything related to quality. See how the company has her programmers create a programme that is buggy, and ignorant of foreign languages and character encoding, yet no one notice the problem until the product is shipped. When there is no full-time, dedicated quality assurance team, problems will slip through the development process and find their way to the customers.
You cannot rely on programmers to find bugs in their own code. Maybe they will find some, but that will not be comprehensive. When programmers write code, they think they have already considered every possible situation, which has been proved wrong so many times. Furthermore, they are preoccupied by many minor things already, such as requirements of client, constrain of hardware, software, and programming language. If you assign another job that requires attention and dedication to them, they will fail both.
Things do not end here. The development team did not ever use version control system or bug tracking system. Without these, there is no way to figure out when and where did the team introduce feature and bug into the code base. This makes development and maintenance very slow, if not impossible, on any programme beyond a few thousand lines of code.
One time, I was in horror when I saw the programme does not compile and a programmer uncomments a large chunk of code. Compilation was still not successful. The programmer made a dozen of changes and the programme still failed to compile. By that time, the source code was unrecognisable to what it was ten minutes ago. It was not until half an hour later did the programmer finally satisfy the compiler. The code compiled, but no one knew if it functions properly.
No one knew if the programme functions properly, because no one agreed how the programme should behave. The team lack documentation: specification, schedule, code comment, everything. Without a spec, the team will always work against a moving target and disagree on functionality. Without a detail schedule, works are guaranteed to crash through deadlines. Without code comment, it is impossible to maintain code, both for who write the code and who does not.
It is a miracle that the application got its current size.
