Is a formal IT development process like ISO and CMM a cognitive substitute?

Not hindered by any lack of knowledge once again, I'm asking myself some questions on what the real factors for IT project success are. These factors are often broken down as planning, skills, communication and formalization of a development process (like ISO, CMM, etc.).

What I miss from the above are other properties that people should have, beyond formalization and communication and skills. It should be easy to defend that project success depends for a very high percentage on communication and its quality.

But communication is an expression of our ideas, and then my argument would be that the correct ideas should exist before we are able to communicate efficiently with others to align the team and project with those ideas that would guarantee the success of a project. So... what is more important? The efficient communication itself between the team? Or the formation of the (correct) ideas itself in the first place?

My thoughts are basically revolving around the idea that... if I were to re-design or re-think software quality as a concept, how would I explore the limitations, shape this area of thought and come to new conclusions and realizations of what, from a cognitive perspective, really goes on in an individual's mind during the development process and how this can be very strongly influenced by the communication within the team. I reckon that from this perspective on quality, personality is more important than technical skill.

Some initial thoughts that could start this theory are:

• Personal traits and attitude that seek out error are far more important than any compliance with rules or regulations.
  
• Quality cannot be undoubtedly and efficiently measured without establishing clear criteria with the user or client.
  
• Thought pattern development, problem analysis, conflict resolution, behaviour etc. are not generally part of quality theories (unless you accept the very vague terms in ISO/CMM documents that might just mean about anything).
  
• The nature and objective of the project should be very clear from the start.
  
• Software engineers should understand general errors of thought and learn to voice concerns more readily and harshly.
• Disposition towards stakeholders may put pressure on engineers to change their response.
  

A natural reaction when encountering a problem, accident or incompliance is to establish rules and guidelines that people need to adhere to in an attempt to prevent similar occurrences. This might also stimulate a certain no-thought attitude where rules and guidelines are simply followed without understanding the actual matter and nature of the job. It can also falsely be used as a means to indicate progress. The latter can result in very serious problems developing until it's too late to recognize them. It might also result in a couple of people that know and a couple of people that follow blind.

So, my focus and view on quality in this post is to ramify about identifying cognitive processes and nature of the human mind that are most contributing to developing quality software. So, rather than thinking of process as a set of rules and actions, I regard process as a set of traits, attitudes and motivations that someone needs to develop in order to develop high quality software.

Traits, attitudes and motivations can also be called company culture. If we understand how we can influence this culture from within, we should have the capability to improve the quality that a certain person is able (and willing) to develop.

But there is another problem here. Without a framework for measuring the level of quality produced, the entity has no means of knowing whether their actions are effective. This probably requires frequent peer reviews and other means for measuring compliance in an attempt to adjust traits, attitudes and motivations, all to become more efficient all the time and eventually contribute more significantly to this process of self-enlightenment.

The problem here is the same as the one indicated at the start. There are (not yet) true absolute criteria of measuring software quality. Any attempt to establish such a criteria has so far resulted in a total mess, since the entities that are impacted by these criteria attempt to maximize on the goals given to them individually. This is because these criteria are often aligned with promotion factors or budget allocations.

There have been good successes, because the factors that indicate quality can differ from one project to another. Now... given this is a truth. How can we ever consider to develop a framework or "standard" of quality that encompasses each and every different situation or project? Standard in the sense of rules, regulations and processes as actions.

Linux Ubuntu on Dell

Dell is going to offer some hardware that comes with Ubuntu Feisty (7.04) pre-installed. These are exciting prospects for the propagation of Linux into mainstream markets that are non-geek. Does this mean that through the evaluation of Dell, Linux is finally considered mainstream-compatible?

Well, I know for one that Dell runs a lot of Windows software, not just offering it with their hardware, but they also run this internally. So they are not particularly interested in software as a technology (or as religion). We need to consider this move from Dell also from the perspective of support.

Windows, as the OS only and a couple of "productive" applications is a basic platform. Let's see the following formula:

known hardware + known software == x probable support calls

However, when we start installing "3rd party" software into this mix, suddenly the support calls can theoretically grow significantly larger. Not linear, but supposedly also exponential, especially when a commonly used piece of software happens to be incompatible with their hardware.

Ubuntu, as we know, has a repository with a very large amount of software on it that should satisfy most people's needs. I cannot truly remember the last time I downloaded an RPM or DEB from the Internet and installed it outside any repository.

This is a different kind of support that they have probably investigated, the support of testing the known software in the repository on their known hardware. If this provides all software tools that people need and it all works, then this is a fantastic service and may bring costs down significantly on the customer support front. Plus... since more than Dell customers use the software as well, for Dell support to resolve issues, they are no longer alone. They can count on the large number of forums, blogs and the community to help people out.

The question is thus... will Dell treat the community well? If they manage to become a responsible member of the community and contribute their productivty back, they gain much more than what they originally invested, as the momentum of the Ubuntu community should definitely increase. Openness in communication, testing of software on many different machines with many different kinds of users, hardware that works, software that works... Will this generate happy customers? Is this the future of computing? If mainstream picks up, does this mean that the market will *demand* Linux on their computers for community support (no fee!) and pre-tested distributions and hardware/software packages?

Some people are already discussing that Dell might start their own Ubuntu repositories and become full mirrors. If the cost of running those mirrors and hardware/software compatibility testing is lower than running a whole array of customer support reps, then this would actually lower the opex for Dell, which means more profit! exciting indeed...

It's not all the same kind of development

I have had the opportunity to work on many different kinds of projects, and you cannot treat software development for embedded hardware the same as web server application development, not by any long shot.

Embedded software, operating systems, low level applications are 70-80% preparation in design, memory layout, memory management, documentation and planning. In contrast to high-level languages used on webservers, etc. The more low-level and smaller you go, the better you need to plan the software, since the tools available (or rework) to modify changes is going to be more difficult. And the lower you go in the system, the more other systems built on top are likely to be severely affected.

So, 70-80% planning in embedded systems with not a lot of coding (just make sure you *do* it right). This is against 20-40% of planning for application software, but requiring a lot of coding effort. The high-level languages have plenty of libraries available and the development tools help significantly with refactoring nowadays. Planning beforehand for the software is actually a risk factor, due to changing requirements from the clients and changing insights along the development process, or a change in the way how things could/should be done.

Therefore, one could "perceive" embedded software development as a "slow" process, but this is not truly the case. A design is in itself a produce of intellect, but it does not immediately convert itself to a materialized ability to the end user. Nobody however can deny that a good design produces immense benefits in the long run for a certain operating system or function.

The final argument has to do with update cycles. Embedded software *has* to be correct. Webserver or PC software can be updated (should not, unless for new features), but we have sort of generally started to accept that for PC software you produce a version that you think works and then continuously update the software after it is released. Everybody does it, so why not you? With embedded, this is simply impossible, since the user does not generally have the ability or skills to do this. And in general we tend to think of a product as "bad" if they have to return it to the shop for 'an upgrade'...

Software Quality

This is one of the first posts on software quality. Since 2002 I have been working on a project called "Dune", which is basically an automated system that helps you in the process of quality (it does not inspect, nor write code for you, nor writes documents), but if your company has strict processes regarding baselines, inspections, document control and especially traceability, this may be an interesting thing for you to try out.

The software is at: http://pdune.sourceforge.net and http://www.sf.net/projects/pdune.
Yep, it is GPL'd, so anybody can download, help out and use it, however you cannot take the sources and close it down for any commercial product.

There are some good rationales behind the project that I am going to write and design soon and put on the site. The whole work on the project is good to understand quality a lot better. I read through entire books about software quality (dry reading material about "process", "audit" etc. *yawn*), but in the end just discover that whatever they are talking about.... it can be automated! And how many tools do you know that automate traceability and have import functions for project plans, RF and UC documents?

A "quality process" in the end is nothing but the definition of responsibility. Setting the boundaries where the responsibility of one person ends and the other starts. So if you believe that a process is going to improve your software, I wouldn't really think so. The only thing able to do that are the people that you have in your time. The process should only help to create an environment wherein this team can flourish! And as written before, definition of processes is not always good, because if the process writer 'forgets' to write down a certain responsibility, it is likely that this issue falls through the cracks with no one to blame (blame it on the process, not yourself :).

The rationale for adopting a software quality standard doesn't really have much to do with actual software quality. That is, a software standard certification need not be in place in order to write good software. Good quality depends on good people, not on processes of any kind. It may help, but only if the process is defined and adopted by the people in the company. Rather, a process must be seen as the formalization of how work is done in that company with that culture, not an enforced method of work by a select few in the organization that read a good amount of books on software quality and then run around crazy with the theory.

I have not yet read CMMi in its entirety, but I understand what it is about. I am not yet sure whether what I am building will comply with CMMi or vice-versa. I do expect though that the "rules for certification" of CMMi fit in nicely.

Any quality "system", whether this is a quality plan, a set of software tools or adopted method of work should aim for a couple of objectives to achieve software quality:

• transparency
  
• traceability
• control

Control is the means that a team has to exercise control over the 'states' in the project. There are initiatives, purchases, work items, bugs, features and change requests to be managed. The better the software is aligned with how the team wants to manage this information, the more effective it will be.

Traceability has much to do with the CMMi and ISO standards. This is often interpreted as a "paper trail", but I argue that it might just as well be a set of records in a database (it is actually much better). Traceability has much to do with "auditing" as well. To know when, how and who is basically the question that for each initiative, bug and feature needs to be answered.

Transparency means a system where the information is close to the surface. One should not have to open a separate locker with a key that only the manager has to go through drawers of paperwork to find out what happened to bug #35. This is one extreme transparency problem, but it shows how transparency is important in a system. Transparency is basically a measure how easy it is to get to the information in the system. The easier it is, the more value the system generates for its users.

So, this is what I am building. An automated quality support system. The system by itself is incapable of guaranteeing quality, but it helps to lift the effort in maintaining the audit chain and ties control, transparency and traceability together. This is very important for people involved in software development. It relieves the people involved from a couple of hours of effort a week (as an estimate), which can be directed to something really productive.