We use software all the time. Not only developers, but also non-technology workers. Everybody is interacting daily with software in its many diverse forms. If it is in a PC, Mac, embedded system, or iPhone, there is no escaping from the reach of software in our lives.

It is therefore with repeated sadness that we verify that most software is of very low quality. And almost everybody has noticed the poor quality of the programs that we have been using lately:

We would not accept a new house with sloping floors, holes in the ceilings, nails sticking out of the walls, and an outrageous price — even if it minimally met basic needs. We would not be content with the explanation: “Well, it has a front door, which usually opens. You can find your way to the kitchen, but watch out for the nails. The holes in the ceiling don’t really leak. And sure it ran 300% over budget, but houses often do.” Rather than crooked floors, the software manifestations of poor design are redundancy, unnecessary performance bottlenecks, intertwined bugs that cannot be fixed, impenetrable code, and other ills. Unfortunately, we often accept software in just such a state. Regularly, companies release code like this to external and internal customers. And customers accept delivery. Businesses pay billions of dollars per year for this kind of software during mergers and acquisitions.

Among all classes of software, it seems however that what is known as business software seems to be the most plagued by quality problems. Rare is the business software that is created on time, under budget, and with minimum quality.

As software developers, it is educative to stop and try to understand why most business software completely sucks. It is probably not just for one reason, but I have my opinions about some of the culprits:

Most business software is not written for end users: in many companies, software is written for the needs of administrators. For example, many business administrators decide about features without talking to the real people who will use the feature. It is a serious miscalculation, but it is also a symbol of power that they want to maintain.

Many decisions are taken for reasons other than engineering: it is not uncommon to learn that a platform was chosen for a project because of a business decision. For instance, a company may use a completely unsuitable tool for a software task, just because it is provided by a well known supplier. This is the kind of disconnect between engineering and business that make like very difficult for developers.

Lack of design: software that is written simply by “collecting requirements” really lack a central design, which will make it always a bad choice. Good software emerges from a fundamental design decision. For example: a web browser, a spreadsheet, or a video game has a central design that makes it easy to use and even develop them. Most business software is created as an “aggregate of features”, instead of a tool that can solve a unique problem.

Given the attitude and the execution behind business software, it is not hard to see why it fails so often, even when it is delivered. Maybe it is not just an engineering issue, but a social issue that needs to be addressed by current and future generations of developers.

[Picture by thinkpanama]

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.

If you are like me, you probably think that the advertisements on Google are mostly annoying. In rare cases they show something interesting, but most of the advertisement on Google searches are not useful for the things I am looking for — unless I am trying to buy something.

Now, for a limited period of time, you can have access to Google search without the annoying ads. The trick is using the test search engine that Google announced recently.

The idea behind this is that Google wants to test its new infrastructure for search. So, they will allow anyone to search on it, as a way of checking that results are correct.

The interface is identical to the current system, but the results may be a little different.

So here is the tip: if you want to help test this new infrastructure and, more importantly, avoid seeing the ads showing everywhere on Google, just use the address http://www2.sandbox.google.com/ instead of google.com.