Every software development project is different but the definition of success remains the same: the product is delivered on time within budget and the customer benefits from it. The ultimate question is: what do we have to do to make our project successful? It seems that for many, the key to success is by using a hyped technology, the latest version of the philosopher's stone, one which will bring order to chaos, simplicity to complexity, and predictability to those never-ending projects. Unfortunately, fighting with a new and shiny weapon does not make obsolete the fundamental rules of warfare. On the contrary! We have to bear in mind that these weapons need solid grounding.

Overall responsibility

"It’s a pretty simple problem, guys. Just start writing the code." So begins a project which is certainly doomed.

Large bureaucratic organizations are especially good at falling into the trap of undertaking IT projects ineffectively and without learning from prior lessons. Projects just flow through an organization milestone-to-milestone from analysis to maintenance supervised by a remote "board" which is under-informed and wimpy in many cases. The responsibility is elegantly blurred, therefore failure belongs to nobody and everybody as well. Alongside the lack of information and a single responsibility-taker no one will dare to make fundamental decisions, necessary changes are implemented painfully (and expensively) slowly.

Company size and reduced bureaucracy does not guarantee improved efficiency. IT companies blindly believing in "self-organizing teams" and "individuals and interactions over processes and tools" may seem to be more flexible and customer friendly, but they may also fail to deliver on time with the desired quality level. Even in a flat, self-organizing team there must be somebody who happens to care about the success of the project more than the others. He may not necessarily have been appointed by anybody but only emerge from the crowd. The upper management asks him about the project status, and he keeps in touch with the customer. We could say that this guy is the de facto leader of the project without explicit credentials. He can only hope that the team respects him, but with the lack of the necessary credentials he may be faced with endless arguments with the team and the upper management over certain decisions. If something goes wrong he will be the one who has screwed up everything: the customer will have the feeling that he does not understand the problem which needs to be solved, the upper management blames him because of the dissatisfied customer and the missed deadline, and the team members get frustrated and hostile being badgered by "one of them". The perfect lose-lose situation.

So the most fundamental rule is that there must be a single person who is exclusively responsible for the success of the project. This person must be explicitly appointed, must have well-defined authority and in exchange for the exclusive responsibility he must have a wide range of credentials. He must be the ultimate decision maker regarding major problems: decisions affecting the deadline of the project cannot be made without his consent. Nonetheless, he must constantly gaze into the future in order to identify dangerous traps and neutralize them. We can call him, for example, project manager.

You can say that this is so embarrassingly obvious. Yes, it is obvious, and even so, surprisingly many software development projects lack such a person.

Technical supervision

Every now and then we have to introduce ourselves as a company to prospective clients, or at a job interview, to a prospective new colleague. We tell them that we develop industrial automation systems, banking and telecommunication systems. Consequently we have to satisfy very different customers, we have to solve very different problems, and we have to use very different technologies. Our audience usually gets puzzled. In essence, they wonder how we manage to deal with change, diversity and uncertainty. Our answers evolved over time.

First we emphasized the role of technology and tools. "We never have two concurrent projects which have too much in common, but in the last project we used EJB3 and Woodstock which saved us a lot of time. Before that we generated the code of a new production control software for Xella/Ytong from an UML model, so we did not have to spend even a minute writing C++ code but instead we had extra time to analyze the automation problems and test the software thoroughly." However, these are pretty common technologies today!

Many companies prescribe certain tools, technologies or development processes to be used within their own projects. "From now on you use Scrum, Hibernate, EJB3 and SOA." sounds the order. And still, using a given technology does not guarantee success. The developers must know how to use it. For example, a project following Scrum may fail, because changing requirements all the time (even during sprints) becomes customary and this results in a constantly changing feature set which leads to a missed deadline. Or they just think that an Agile method makes design, planning and documentation irrelevant.

So smart developers must be key elements! Our colleagues are excellent problem solvers, they are efficient, they ask just the right questions and ship the solution fast. However, having top notch developers may not be as common as using Java, but it is also far from being unique.

The best analysts, architects, developers and testers of the world, even having the best tools at hand, may also fail to deliver the desired product on time. They have to make the right decisions which harmonize with each other and the customer's interests. In many cases the team members cannot recognize that we are not just making a Requirements specification, Architecture specification, Test plan, software and test codes, etc., but we are essentially producing a tool which will be used by someone for a well-defined purpose.

Therefore, our current answer is that the technology and the project team are extremely important, but it is more important to have someone, who has the big picture. Someone who's main job is not only to put together a document or a piece of code, but rather to make a useful application. Someone, who knows what, why and how things have to be done, and can give a consistent rationale of all technical issues and decisions. We call this person the "technical project manager", or the "architect".

The architect oversees the technical issues from the very beginning of analysis through design, implementation and testing to product delivery. He is exclusively responsible for the technical content of the project, he must aim to ship the best quality product possible within the given constraints. It is his responsibility to provide the professional background for the project manager as well, and ensure that non-technical decisions have the essential professional foundations. He chooses the development process, tools and technologies his team will use in the project. It is his job to synchronize technical decisions, assign tasks to project members, and determine priorities. Besides that, it is also his responsibility to help the team members and provide all necessary professional assistance.

Of course, the architect is not an omniscient dictator. He must collaborate with the team: he has to rely on the expertise of the team members, he has to consult with them continuously, and he has to absorb their opinions and suggestions. The architect has to gather all the information, consider them and make the major technical decisions.

All in all a project needs to have the best instruments and musicians possible, but also it needs a conductor who orchestrates the development. It may not guarantee success automatically but certainly helps to avoid raging chaos.

A stable project team

I have been spending the last three weeks designing a new system. All went well until I was asked to review some unrelated documents to do with a prospective new project - requirements specification, architecture specification, the usual stuff. So I said farewell to my half-designed system and started to dig deep into the details of the submitted documents. It was a long and tiring task, so I was happy to get back to my own project. Until a realized that I had become completely lost...

I felt like I was in the middle of a jungle. "Where am I?" I remembered that last week I finished the GUI design and then... Or maybe, I did not even finish the GUI design? Now my best guess is that I was somewhere between the GUI design and the finishing touches of the server API.

This story painfully demonstrates the negative effects of a context switch on the developers' performance. It is not unusual that a developer must switch from one project to another, actually, it happens too often. However, every time a developer has to stop solving a given problem and start working on a new problem, a costly process starts. The details and different aspects of the old problem start to fade away, just like the subtleties and side-effects of the solution. They are pushed out of the mind by time and the new problem. The new problem has its own new context, new aspects and new subtleties.

When the developer gets back to his old problem, he has to reload the old context, which takes at least a few hours laced with agony and growing fears of amnesia. As a matter of fact, concerning the volume of complex information a developer must keep in mind during his work, it is natural that context switch takes a few hours. Natural, and costly as well.

So, unfortunately, even the best developer can perform badly if he has to work on different projects on different days of the same week. Therefore, the re-allocation of a developer must have a strong reason which definitely outweighs the overhead of the context switch. In general, a developer should be allocated to a single project from the beginning to the end, unless we are ready to wait patiently while he manages to locate himself in the middle of the jungle.

Effort is not derived from the potential price

Politics often play a mayor role in effort estimation. "Could you please estimate the effort of this project? Anyhow… our customer is willing to pay X-thousand USD, and please, bear in mind that we have to deliver within 6 months. Oh, and I almost forgot! You get the new guy and Steven. Get back to me before lunch, thanks!" – this from the CEO to a project manager. Is it familiar to you? And what if the CEO also adds that the customer is either unable or unwilling to clarify what he really wants? Now that is the worst kind of estimation politics!

I admit that the above situation is really absurd and may never happen. But quite frankly, estimators are always subject to various influences and conditions. It is far from being uncommon that, after an effort is estimated, the boss seems surprised at how much greater the estimated effort is than he expected it to be. Then the estimator gets some time to re-think everything, actually to convince himself that the boss was right. "Yes, we are better than that! Last time… we made that huge mistake, but this time, it's going to be different…"

The problem is that even if the estimator has convinced himself and yields under the pressure of his boss, the actual effort won't be lower, only the estimation will get farther from the reality. Consequently, the project schedule will be unrealistic, the developers will have to work 10, 12, 14 hours a day, 7 days a week, and even then, the deadline probably will be missed. The result is a bunch of tired developers, and a growingly impatient customer who notes your company as unreliable, one not to trust in the future.

Therefore, only the problem that has to be solved, the way it will be solved, the people who will be working on the solution (i.e. a product) and the characteristics of the organization should influence the estimation. Besides, the estimation method should be as objective as possible.

Developers' pride is one of the major causes of over-optimistic estimations. Among other estimation methods, we use decomposition estimations: we decompose the creation of the product into small tasks that (presumably) can be completed within a few hours. Afterwards, we ask the developers to give an “effort estimation” for each task which is preliminarily assigned to them. These "small" effort estimations should be such that their sum would be as close to the actual effort as possible. We do this without (deliberately) hinting any desirable outcome. On the following day we ask the developers to give their most optimistic and pessimistic estimations as well. Well, not in one case, a given optimistic estimation is actually higher that the previous day's estimation. The moral of this example: trust but verify. Moreover, trust, verify, and calculate the "real" estimation.

In summary: the estimation should be the result of a calculation as opposed to via some kind of vague guessing. In order to get a good estimation we deem that the best an estimator can do is (1) to gather as much information about the problem and the solution as possible and (2) use various estimation methods such as decomposition estimation, estimation by analogy and regression estimation, and (3) combine their results. Finally, yet another apparent fact which may be worth emphasizing: "There is no point in being exact about something if you don't even know what you are talking about." (John von Neumann). The more underspecified the problem (i.e. requirements) and the solution (i.e. architecture) are, the bigger the uncertainty (or error) of the estimation will be, which may lead to a project being mis-priced. So concentrate on gathering information and resist estimation politics.

"Testing? Of course we will test it, if we have time…"

Do you want to be faced with angry and frustrated customers accusing you of sloppy work? Then please, do not test! Do not do functional and performance tests, and forget the whole unit-testing thing. Just let the customer start using the product and ask them to report bugs. This is one of the most efficient ways of ruining your professional reputation and losing your customers.

Despite the catastrophic consequences of a lack of testing, many products are shipped without any testing at all. Or, at least, many producers try to ship their products without testing. It is not uncommon that we are contacted by someone who needs last minute testing. "We have been developing this product for two years. I think we are on schedule but we need to test it before we ship it early next month." sounds the not-so-unusual request. It is hard to give a positive answer to such requests.

There is no such product that after the developers have finished writing the code and leaned back with satisfaction on their faces, does not crashes within moments after it is first started. Even if they are excellent programmers and did their best to write perfect code. Even if they have done some smoke-testing whenever each implementation of a feature was finished. Unfortunately, the first "finished" version of the product is rubbish in the eyes of the user. The UI is hard to use, it keeps crashing all the time, its performance is a joke and, if it is a multi-user system, it cannot serve more than a small number of users. So if the developers say that they have finished the product you can be perfectly sure that at best one third of the road is still ahead. And the road will be rocky.

Therefore, even unwillingly, it has to be accepted that testing cannot be spared. It has to be included in the project plan and sufficient budget must be allocated for it. According to our experience, at least one third of the budget must be allocated to testing and bug-fixing, but in the case of (safety-)critical applications this can range from fifty up to ninety percent.

One may say that testing must be left out for financial reasons, i.e. someone deems that there is no money for it. But it does not change anything: the product will be full of bugs which will have to be found and fixed, and which has a more-or-less foreseeable cost. It can be done on a well planned and predictable way or it can be done by the user on an improvised basis. Both options have a cost but the former is much cheaper.