Developing commercial software is an activity that many companies have to do. Sadly, the results of such efforts are usually misplaced, as a lot of software that is created by companies is either inadequate, or takes an order of magnitude more time and resources to build than it should take.

Assembly Line Thinking

One of the big mistakes of commercial software development is not realizing that building software is very different from building a traditional product such as a car. There is no industrial line that can be used to create a complex software.

Companies that are used to the assembly line methodology believe that you can just assign different people to do small pieces of software, and then combine everything. While it is true that people have different skills in the software world, programming is best done when someone is able to reason about the whole functionality of the program, before going to the details.

Ideally, you want people to be assigned and responsible for creating large pieces of code, and let them think hard about it. If you don’t have people that is completely involved in the creation of software in this way, what you end up is with a few pieces of software here and there that, while solving the original problem, have no clear relation to each other. Therefore, the product will miss cohesion and an inner structure that would allow an easier development strategy for future changes.

Lack of Proper Design

Another reason why commercial software is so frequently bad and expensive is that the design process is not done properly, or when existing, puts emphasis on aspects of the software that are not essential for a high quality product.

One of the ways in which this problem occurs is in the lack of a general strategy for software design, with decisions made by people that really don’t understand the underlying problems that are being solved.

Maybe a simple rule that could fix this issue is the following: don’t let business people decide what goes into software. Listen to their opinions, but leave the options open so that the designers of the software have a real decision on what features will be included and how.

One of the big issues faced by software writers is that business people that approve the software think they understand something about how to write it. This is akin to patients thinking that they can give orders to a doctor about what treatment to follow. Many of these power users like to give a lot of recommendations about what the software should look like, mostly based on a superficial knowledge of the problem. They lack the knowledge of software design or user interface design that would be necessary to make the recommendations valid. However, due to the realities of business organizations, these ill conceived suggestions are frequently taken as requirements for the software.

If we really want a software system to be successful, it needs to be designed by people that really understand not only about the problem domain, but about proper software design techniques.

The other problem is having a design done by committee. This happens when, while defining the requirements of a product, analysts go to a large number of people in order to define the features of the application. In doing this they, frequently for political reasons, adopt the disparate suggestions of several people. The suggestions may even be individually sound, but if you let software to be designed this way it will completely lack a unifying approach, and will certainly be more complicated than it really needs to be.

The best way to avoid this kind of problem is to have one person, or a small group of people, responsible to define the main architecture and features of the software. Whenever there are conflicting requirements, it would be up to this group to determine how the situation should be handled, in a way that it doesn’t damage the main functionality of the application.

It is also interesting to make sure that owners of the application are informed of design decisions, so that there will be no surprises on the customer side. Every design decision should be careful explained, so when something is not included, there is a reasoning behind it. Most of the time, users will be satisfied when the application provide what they want, even if it is not in the same way that they initially imagined. It is just a matter of proper communicating with users about how the application is supposed to behave.

Similar Posts:

• Some Reasons Why Commercial Business Software Sucks
• Top Software for Programmers
• Avoiding Feature Bloat
• Five Common Mistakes in the Early Design Stage
• Day 27: Design Resilient Interfaces