I think the article does not fully convey what I mean by quality. This one was the result of a chat with Cesar to try to surface what I really mean by quality insurance.

Also, I fully agree with you on the achieved quality and the difficulty of having quality requirements. Which in turn is why I believe Agile methodologies are the best practical approach in many cases. In a few others formal methods help.

More importantly, software quality is a continuum, like the line of real numbers, and one can only define what sufficient quality is. If one is a true perfectionist of quality, then one must refuse to work on a project unless formal methods are applied and the entire program is mechanically derived from a specification written in predicate logic (or something of equivalent power), regardless of whether one practices waterfall or agile or anything in between.

In the discussion above, the word “guarantee” is used in a number of places, but I wonder if even the perfectionists can “guarantee” anything — even when formal methods are used. You see, the initial specification I mentioned above, even thought it elegantly summarizes the requirement precisely, may be in error. There is no formal way to prove that this spec meets the requirement. To do that, the requirement will have to be specified rigorously, and then how does one prove that it is what is in users’ heads?

In summary, I am in general agreement with Cesar that one must look at the practicality of achieving high quality, this level of quality differs from one person to another, even among perfectionists.

Compromising quality in this case means that you are prepared to lay down pipes that will not deliver enough (or any) water when you could have delivered pipes that delivered water by applying best pratices.

The trader, the client and the developer may have expected and been used to a minimum quality level and this was not met. However, neither quality nor in fact the software itself were the common goal of the project. The goal was to deliver the structured product. Another (implicit) point is that I have seen some software developers behave as if the center of every project is the software, and failing to adapt when it is not.

The customer (i.e. the trader) expressed some requirements which needed to be delivered, but also some guiding principles that the project had to meet. Principles were more important than requirements, and they were things like “speed to market” and “focus on the outcome”. There was also a drop-dead date.

The initial delivery was barely fit for purpose. The trader was barely able to use the software and some of the requests-for-price were lost. The client was barely able to construct an order and experienced frequent errors and timeouts. Often, at least at the beginning, the communication reverted to the telephone or email, and the processing to excel. Both trader and client were happy though, because the transaction went through and they accepted this overhead not because they were used to buggy code but because they acknowledged that their minimum standards and stated requirements could not have been met in the time they provided even compromising quality. They also had control over prioritizing quality improvements or additional structured products or allowing other traders to process the existing product.

I may not sway you but I think I’m trying to express that there are environments and circumstances where saying “you shall not compromise quality” is too inflexible. Here is an extreme (and imperfect) analogy I will probably regret. How about a project where you are building a pipe to bring water to a village? Your customers request a pipe and you know how to build pipes so you set about doing that to the quality you know you can deliver. Now imagine that because of a natural disaster, you have to get water to that village before its population starts to die. Maybe the roads are impassable, there are no helicopters available, and there is no way to get them enough water in time. Say you have three days. The only thing you might deliver in that time is a low-quality solution that leaks badly and delivers water which will poison the village, but the villagers will thank you. While you are doing this, you recruit local people on foot to take bags of medicines to combat the disease your water might bring, and bags of sterilizing tablets to treat the water and minimize this disease. You have delivered according to their priorities which placed the flow of water above the quality of the water or the quality of your pipe system. Low quality, but overall goal accomplished. You then prioritize between doing the same for another village or improving the quality of the water and the pipe system for this village.

In your examples, how do you guarantee that the application you bang up satisfies its purpose ? I also specifically stated that in this kind of case, a barbarian approach may be acceptable if it is explicit.

Still my experience is that when you bang together an application that is actually useful, it pretty soon grows in size and user base and becomes very expansive to support. It is actually stuff of legend that the software that last longest in financial institution is the ‘temporary’ one.

Your remark is also based on the (flawed) assumption that ensuring quality lengthens the time to market. In my experience the main factors that lengthen time to market are:
inadequate requirements,
inadequate tools (like building a webapp in C++),
deploy-break-fix cycles (the barbarian qualiity insurane),
the learning curve (new tool, architecture,…).

Instead, I am reading this as an educated ranking of quality against other priorities. I have seen situations where a trader comes up with a new financial structured product and simply needs sufficient capability to be able to sell it to a client. Integration with the firm’s systems, scalability, automation and all that other good stuff is secondary. This can be because the first one to market will typically take all the revenue for the next 18 months, and the second to market will get zero during that time.

The stated need here was for an outcome-oriented solution. In that spirit, I have seen IT and various support functions collaborate successfully in knocking together a simple web interface for the client (to see positions or net value, or even to place orders) and all of the processing behind the scenes being done manually for 6-12 month - i.e. the solution was buggy software combined with hiring x low-skilled people to do repetitive and mundane paperwork. The client valued the opportunity to trade, and cared less about having to restart his PC every time an order was placed.

Don’t think that you can spend the next 6 months cleaning that up either. Now imagine that the following week another trader thinks up a new great product and that needs to be made available to the client asap…

This is my most extreme example of what you’re describing and it is a situation where you’re delivering well below your standards and not always able to enhance the functionality. However, the trader is prepared to take the risks and the company makes a lot of money with each one of these. In fact just about any other way to do this would result in losing the business opportunity or the client and their future business.

Agile works well in this environment, particularly because you can “bank” the value of every iteration where you get the chance to improve the technical foundation underneath all those products.

Where I oppose the “client veto” is where it would not be professional or ethical to allow certain choices. If the decision is made openly and with the participation of relevant groups (operations, compliance, risk, legal, audit…) then I have no issue. If the same trader attempted to put something on my queue without that involvement, I would not tolerate it and push it back or walk away.