Currently, there is no universal solution for IT projects that take far too long, to deliver far little value, for far too much money. This triangulation of time, function and cost has run amok in our industry for over 40 years. Well, enough is enough! Now we stand at the tide of change, soon to witness the universal solution come into force where previously we had none.
We can see one sign of change within the recent Google Hang-Out between Kent Beck, Martin Fowler and David Heinemeier Hansson regarding Test-Driven Development (TDD). In my opinion, the solution that enables the IT project to deliver more, deliver cheaper and deliver quicker comes from TDD taking the next step along its evolutionary path. Therefore, over a two-part blog I would like to discuss the Google Hang-Out and explore the areas that I feel would benefit greatly through some form of evolutionary development.
Challenging TDD
Even if you feel you know everything about TDD or have strong opinions thereof, I think the Google Hang-Out is none-the-less a fascinating watch. You have an established and seriously well-respected thought-leader (Kent Beck) having his methodology (Test-Driven Development) challenged by another well-respected thought-leader (David Heinemeier Hansson). Regardless of your position over TDD, in any case, blowing “fresh air” through established ideas provides the perfect environment for a process of evolution. Ultimately, we make our world a better place through continuous integration and natural selection within existing methodologies. For now, however, let us address the testing community at the inflexion point of change. Let us focus on one area candidate for incremental change and embrace the change by redefining the role of the tester as a cross-functional work-cell.
Think about how the majority of testers fit into a typical IT project. Concisely: the business wants something, the analyst transforms requirements into specifications, the programmer implements something and then, finally, the test checks to see if things work.
In theory, this is a perfect process: it is clear, simple and so easy to understand. However, in my 25-year experience, this process never actually works. In reality, what happens is that the IT project suffers from misunderstandings, miscommunication and a wide variety of human errors – all of which compounds worse by the tester, often forcing the post go-live process to provide additional and unplanned solutions to the IT project’s technical debt.
Compounding happens because there is a stark and fundamental difference in mind-sets. At the risk of over-generalising my profession, the mind-set of a Business Analyst tends to think purely within the box. Crudely put, a Business Analyst will confine their specification to “within” the box of some predefined business requirements and there throughout the realisation of the IT project, the Business Analyst will guide the Developer to build something that operates under normal conditions “within” the box.
Normal system operation is of course the central case and, by definition, exists “within” the box. However, all bugs and defects reside “outside” the box – i.e. the horrendously detailed corner-cases that surround the central case of user requirements. In addition, the mind-set of a Tester is to think constantly “outside” the box because, after all, this is exactly where all the bugs and defects reside. Thus, if it will break then the Tester will soon demonstrate exactly how to break the system.
Unfortunately for the Project Manager, since the IT project assigned the testing phase to the end of the process the IT project enters into a phase of “defect fixing” which leads to change requests, unplanned changes, yet more bugs and other issues related to high stress environments.
Testing in The IT Project
What the Project Manager really wants (yet currently has no idea how to ask) is to put all the Testing right up front of the IT Project. The instant the business states their requirement is exactly the instant the IT project wants to start testing. Putting the technical “how do you do that?” to one side (we get to that later) – imagine the feedback loop: the business states the requirements and the Tester / Business Analyst combined present not just their specification to the Developer, but a whole list of bugs that the Developer will create. Imagine further, the business states the requirement X and the Tester / Business Analyst combined advise that satisfying requirement X will contradict requirement Y … and here is a whole list of fresh bugs that the Developer will create if you insist implementing requirement X.
I know, I know – you are all thinking “Huh? This is crazy!” and, I agree – actually, in addition, it sounds terribly arrogant to say to a Developer “here are all the bugs you will create…” I mean, how do I know? The Developer has not even had a chance to start programming so it just sounds like a short-cut way to break the team morale and build barriers instantly.
However, let us stick with the philosophy of “test first” for a moment. Developers seldom create bugs for the heck of it — at least, the professional developers that I know of certainly do not. The only reason they create bugs in the first place is that they did not know they created them originally. Further, the only reason Developers continue to create new bugs is that in the all-too focused attempt to fix one bug, their attention drops for a moment and they unknowingly create another bug. Put another way, if Developers knew they were about to create a bug then they simply would not do so.
The desire to create bug-free software, the desire to implement change and not to break a running system, the desire to “sleep well” either before or after a production release is right at the heart of the “test first” philosophy. The Google Hang-Out discusses (briefly) what means, “test first” and (mostly) discusses “how to get there” as Kent Beck and David Heinemeier Hansson have so very different opinions as to “how to get there”. If we can agree that “test first” is indeed a desirable place to go (just, we may disagree as to how to get there) then it is vitally important for a Tester to engage in this philosophy. The philosophy mandates that the role Tester and the timing of the Testing activities must change and must integrate with Business Analysis as a redefined, cross-functional work-cell, critical to the success of the IT Project.
Read Part 2 of Is TDD Dead here
About the Author:
I am an experienced and innovative business analyst with a unique set of skills that allow me to dive deep into the technology, analyse the issues, communicate issues into business terminology, discuss options, advise, consult with all stakeholders in the project and support the development process to implement the goals without defects.
The methodologies I practice inclue Agile, Kanban and Waterfall. I am experienced in object-orientated analysis & design as well as relational database design & management with special focus on Oracle, ETL, data warehouse design, star schemas and reporting cube design, implementation and management.
The various tool-chain products and frameworks I have used and trained include Eclipse, Enterprise Architect, IRA, Jenkins and Confluence.
Over the past 20 years, my client list includes Julius Baer, Credit Suisse, HSBC, JP Morgan, Royal Bank of Scotland, Man Investments (now called AHL), Allianz, Deutsche and UBS. Although this has heavy focus on financial services, within the industry I have covered ground such as engineering, financial engineering and regulatory engineering.
Dave Cobbe: http://www.tek-motivation.com/dave-cobbe.html
LinkedIn: http://www.linkedin.com/in/davidcobbe
Background: http://www.tek-motivation.com/standardising-communication.html
