The Undercover Adventure (Part 5): Sliding sand consensus.

In my time here on the oil mine I have had a lot of time to think and observe and one thing is for certain, perspective on something makes a big difference in its execution and acceptance. Whether a difference exists between planners and specialists, procedure writers and planners or the leads and the journeyman, it doesn't matter. What is clear is that people are quick to judge something accordingly to what they understand about it. More so, if they fear it and don't understand they are quick to abandon it.

I have experienced this very response within software development as having been a tester I know what it feels like to be accountable directly to the client. I am not saying a developer or project manager (et al) aren't, but rather I am referring to something quite specific in this case. I am talking about that moment in a UAT session when you experience the disillusionment that strikes a client when things go badly wrong. It is something that got my attention quite strongly both here on the oil mine and on previous projects I have worked on. It is the dangerous dichotomy between the need for permance because of the nature of transaction in business and ensuring compliance and the fuzzy ending that is the container of software development.

In my previous post, I spoke about the impermanence of information that exists between code and client. Perhaps I have viewed this most easily as a tester, because you sit at the end of a sometimes long process, but when all those mistakes and mis-steps and "no longer relevant intepretation of functionality" are added up, the overall effect can be large. I am refering to situations such as user acceptance testing that goes very badly because the multi-user access wasn't accommodated for or no access was possible because a deployment wasn't done correctly. Essentially the key moments when things are meant to come together so as to confirm completion and delivery and well, it doesn't happen. Several things can happen beyond this point, depending on the severity of the gap between what was desired and what was delivered.

This gap can happen in any number of ways and I have one example to share. I was working as a QA manager and while I was in a meeting one of the directors of the company called me out and asked me to meet with him directly after the current session. He looked very concerned and that was cause for worry on my side as he wasn't someone to ever be that abrupt. I went to go and speak to him and it seemed that one of the deployments at one of our biggest clients had gone badly wrong and caused them to loose money. A fair chunk at that as it is a large retailer in the UK who processes a large number of product development and designs in a day. Effectively the bug had completely stopped business and what made it worse is that the team had no idea how that bug had made its way out. They were very upset and actually threatening to sue us.

After some digging, it was discovered that a developer had checked in code without telling anyone. More so, the code he deployed didn't affect the section that had been marked for fixes and updates for that date. Thus the tester who had worked through the selected selection and and closed off all the major issues quite simply hadn't discovered the bug. He asked me to pull out any and all QA documentation that we had which specified our process and procedures and requirements in terms of delivery as the client wanted evidence that we had done all we could to prevent this. Additionally, he wanted to use it as evidence in a disciplinary case that involved the developer aforementioned.

If the gap is small and the client has a good relationship with the team as a whole, time to amend and re-deploy can be easily organised. Obviously, experienced project managers would have already accommodated for this repetition as it is well recognised that we don't always get it right the first time, or the second time or even the third. Sometimes it seems as if software development happens in reverse if you look clearly at some well known software methodologies and you compare them to the reality of its application. While the intention is good to have specifications built in the begining, as I have mentioned before users change their minds (sometimes there is more change than anything else) or the business changes and what was once the constant becomes inaccurate. It is interesting to note that this also exists within the process of maintenance and planning, not so much with the tasks and actual hands on work, but rather the system and processes that are built around those to manage and facilitate things. However, it is far easier to move and change peoples direction and task allocation than it is to change functionality, redeploy and retest and signoff.

If the gap is really large and the client is well, angry at you for multiple failures, the landscape grows dark very quickly and the nature of the business relationship changes. What was once something that resembled a partnership of sorts, can descend into a purely contractual fight to determine what the client can gain from you without having to cough up more money without delivery. There is distrust and it becomes a case of comparing the actual to a previously stated reality (which is no longer appropriate).

I do believe that people inside the software development process, I am refering to developers, testers mostly who don't deal with the business side of software development that they don't realise the legal consequences of certain things. Software developers and testers would more easily see an application as precisely and only that. Namely, functionality that has been built to do something particular that is specific to the client. There isn't usually much attention paid to the business value, IT investment and asset management side of it. The people on the outside of that process, namely those that are responsible for delivery and management see the process and the end result very differently. They talk about accountability, asset management, risk management, legal and cost penalites associated with late delivery and so forth. It is far more a conversation about numbers than it would end up ever being about objects classes.

I don't say that to cause upset, but rather to illustrate the divergence of conversation. This raises several questions in my mind. Should the process of software development contain some sort of education about these types of consequences? Do we really understand what we need to do to protect ourselves? Do we really undestand how that relationship erodes to the pont where we are aware of it and understand how to respond? Are our practices mature enough to deal with it? Is it the fact that discussions about business value and delivery are not a part of standard conversation in a team reveal that we haven't gotten there yet?

When you go through a situation as described in the example above, you realise that something as seemingly “safe” (I use this term loosely here to imply that it is seen as only a part of the software process and not open to outside enquiry or investigation with intent to prosecute) as software development documentation (as it is often shoved to the side) comes with a enforcable consequence attached to it. Not only is it a means to establish transaction and terms of engagement, but you never know when it will be necessary to establish your position and be able to openly display your process and way of doing things. The hope is always that the situation never descends to that level where it would be necessary to go back to the original contract (and associated documentation), but it is necessary to always be aware that you can never be certain of what will happen. While the aim is to have a good and solid partnership, you cannot escape the nature of business. Whether you find yourself on an oil mine, or within software development the rules of delivery tend to be the same: if you no longer provide business value you will either leave of your own afford or be shifted from your position.

Disclaimer: I am not a lawyer and there are merely my observations about the process. I welcome any input from a legal perspective that could add more insight into this.