«    »

Producing Good Software is Hard

This is a public service announcement to all project managers, business analysts, others working in the I.T. industry, and the general public: producing good software is hard. The next time you wonder why the software you are using crashed, or why your software development project is behind schedule, or why your software doesn't meet the users needs, remember this point.

People I have dealt with professionally who are not software developers occasionally make comments that imply that writing enterprise business software is a fairly straight-forward task, easily handled by the average developer. I have challenged these statements by pointing out that reality disagrees. The majority of software development projects are overrun or canceled. Software that does make it into production often has serious operational failures, performance issues, or fails to meet users' requirements, and much of it is poorly designed, making it difficult to correct these issues and implement enhancements. These problems cannot be blamed solely upon weak developers. Across the industry, the typical software development team will be staffed by average developers (by definition), which means that the problems I just described affecting a majority of projects result from the efforts of average developers.

In defense of software developers, the leading causes of project failure or overrun are actually in the areas of project management (i.e. overly aggressive schedules) and requirements gathering. Problems in these areas cause much more serious impacts, and this is perhaps why project managers and business analysts sometimes feel that writing the code is the easy part. But it is not. Even assuming sufficient time, clear requirements, and a decent solution architecture (which are big assumptions), producing working, high-quality code is hard.

Why is this? I'll first look at meeting the functional requirements. For a typical enterprise business application many of the functional requirements are admittedly simple, and can be summarized as creating data entry screens for a particular set of data. Many of the enterprise business applications I have been involved with, however, also have more complex functional requirements such as complex business rules, batch processing, web services, or data conversion. These more challenging requirements are the ones most likely to cause problems for the development team.

Software must also meet non-functional requirements in areas such as performance, usability, and maintainability, and I believe that most enterprise software does poorly in these areas. It is simple to explain why: everyone is focused on meeting the functional requirements - clients, testers, and project managers as well as developers - so the non-functional requirements are neglected. Even when someone - most often the architect - considers the non-functional requirements, it is difficult to address them all at the same time. Typically multiple iterations are necessary. For example, a developer first writes code that meets the functional requirements, then tries out the user interface and make improvements to address usability issues, then tests and addresses performance issues, and finally cleans up the code to ensure the design is maintainable - easy to understand and modify. These multiple iterations take time, skill and dedication, and if a developer is lacking in one of these areas, the non-functional requirements will likely be neglected.

Combine the challenges in both the functional and non-functional requirements, and the result is that the typical software application will fall short in at least one area. Add in other common challenges like a compressed schedule and unclear or changing requirements, and the chance of success plummets even lower. In other words, producing good software is hard.

If you find this article helpful, please make a donation.

«    »