Recently, I followed a discussion about quality of software in zombie mode. Please do understand that not the software – but I – was in zombie mode.

The question under discussion was: who is to blame for poor software quality?

Is it the business, with their vague requirements? Or maybe the (project)managers, who only care for budget and scope? In any case the coders are to blame, are they?

Maybe all of the aforementioned?

Personally, I am a (sort of) believer in Goldratt his theory of constraints, so the answer would be obvious. Loss of quality adds well to the pile of crap.

However, what first struck me was the omission of software architects (and testers). The omission suggests that there is no role for software architects in quality? Strange.

Therefore I would say: no wonder it is of poor quality, there is no software architect involved as a technical conscience. On the other hand, technique plays – of course – only a small part in the whole software development process. For creating quality software, all perspectives must thus be taken into account.

True. But what is the definition of quality code?

From a technical viewpoint you can have high-quality software, whilst from a business perspective the software doesn’t solve the problem that the business is looking for. The other way around can also be true.

Therefore, the motto of today:

Although the software is crappy, the business still can be happy!

That’s the power of a good UI/UX. Apple does understand this very well.