Hardware vs. Software

One thing that always puzzled me is the different quality meters used on hardware and software by users: little flaws in software systems are accepted as inevitable, while hardware flaws (even small ones) may even create market panic if discovered. It's hard to tell why this is so, but today's software quality standards are becoming more and more selective, especially when monopolies are broken and users are able to judge the differences between products and solutions.

Open Source as Quality Management

The open source development model has emerged as a powerful way to control and improve software quality. The most important assumption, in this case, is the fact that debugging and code testing are parallelizable tasks. For this reason, different individuals are able to track down problems right into the source code, independently from one another. In open source projects, compared to closed source ones, the complexity of the software system grows slower than the ability to debug it, due to this parallelizable effort.

Open source processes are auto-organizative: when a seed of ideas and goals is thrown in the right place at the right time, it catalyzes the development process. Usually, when this happens, the user base expands, the complexity of the software system grows to meet the requirements of this bigger user base, incorporating new ideas, solutions and code and creating a positive feedback that keeps the process going.

Software Engineering and Open Source

Software engineering doesn't fit well into an auto-organized system driven by user requirements. Still, I believe that careful software design may allow the development process to know the ability of its developers and to provide them guidelines to reduce the work and to increase parallel capabilities. Of course, due to the extreme flexibility that open source projects show, software engineers should carefully design the system to match this flexibility and to avoid any restriction that may create friction with users and developers.

It is evident how the use of modern object oriented programming languages like Java helps the development and reduces the debugging efforts because most error prone tasks are handled automatically by the language itself. Still, the most important object oriented solutions (such as Interfaces and abstract classes) are very much unused in auto-organized project, where the work is usually done with the smallest possible effort to get something working.

The incredible improvement in time-to-market offered by these programming languages that reduce the debugging process to logical bugs rather than developer's programming mistakes, is a great feature and it's well appreciated, but it may lead, on the longer term, to code maintenance problems.

In all software systems, the maintenance costs greatly exceed the first development ones. In open source software systems, the cost is measured in terms of time and energy spent by developers to meet the new requirements and to expand the complexity of the software system. It has been shown (in the Apache JServ project) that the wrong use of object oriented features may lead to project stall and create friction between developers and users about the need for revolutions instead of evolutions driven by the need of a complete code redesign.

The rules "if it works it's good enough" and "if it works don't change it" may fit well in those programming contexts where developers need to design the code on their own to make it work. In object oriented systems, more than ever, working code is not automatically good code.

Frameworks and Patterns

The solution I propose is the introduction of coding guidelines to place new requirements to meet the "working" state: by introducing the use of software frameworks and design patterns, we are able to shape the work of developers without restricting their creativity. While object oriented languages don't pose such limitations or guidelines, the introduction of carefully designed engineering rules, contracts and patterns would create some additional requirements to the development process, but will allow better code maintenance, a more coherent parallel development process and, in the longer run, easier maintenance.

Conclusions

The use of development guidelines and frameworks is proposed as a way to reduce internal tensions that produce revolutionary development processes rather than evolutionary ones. Even if such ability is yet to be demonstrated, it has been shown how object oriented languages require different approaches and more careful design stages to be successful in the long run.