Every software application goes through a design phase. It may be as formal as a multi-session design summit with architects, DBAs and the entire development team or it may be as informal as a developer sitting with a Mt. Dew and thinking about how she wants to store the data after it is pulled from the database. In all cases though, good developers will ask themselves ‘How am I going to prove that this code works’ before they even reach for the keyboard. They will design their code so that they can easily demonstrate that their code meets all of the requirements (positive test cases), and can handle any exceptions that might be encountered (negative test cases).

By thinking about how a particular piece of code is going to be tested before it is written, a developer is forced to think about programming in a more structured manner. They must think about how data will come into contact with their code, what form it will take, what possible values will be encountered and what exceptions could occur through normal and abnormal circumstances. They focus on what the end result will be in all of those cases, and how they can prove out each of them.

There is also a hidden benefit to test driven development – a simplified code base that is easy to maintain and debug. When you think about how you are going to test a piece of functionality first, you tend to think about writing code to pass the test in the most simplified manner. Sure you can create a complex code base with multiple calls to sub modules that perform very complex calculations and pass data back and forth multiple times. But testing it all out is going to be painfully time-consuming. It is much easier to design a clean code base with simple statements that are easy to test with data manipulation. Expand this thinking over several thousand lines of code and suddenly you can see how a simple structure that is easy to test becomes a very powerful thing. Rather than creating spaghetti code that is hard to trace and debug, you have a simple structure that can easily be tested by anyone who interacts with it, even a person who has never worked with the code before. By creating simple, easy to test structures, you improve the readability and maintainability of your code base, and make it easier to support and debug if something goes wrong.

While Extreme Programming concepts are typically associated with web-based technologies, Test Driven Development can be used in any programming language and in any development methodology. The key is to think about how you are going to prove your code works at the design phase, rather than after it is written. This eliminates a lot of re-work and creates the desired structure from the beginning.

Business Side: Business clients do not write good requirements. They are focused on running their business and most don’t want to take the time to hammer out every little detail. They provide the basic concept on how to do things and let the IT guys figure out how to make it happen. In many cases, they feel that the business case should be more than enough. To a large extent, they are correct. Business folks are responsible for articulating the business need and describing all of the use cases. They provide input on the overall design and need to be available to answer questions. It is the job of the IT team to translate those use cases and business needs into technical requirements and design. However, there’s a problem with this as well.

IT Side: IT developers don’t understand business client needs. Developers want the requirements spelled out to the maximum detail. It is the easiest way for them to translate words into applications. Their success is measured by how well the code matches the requirements and the ultimate usability is a secondary concern. To be truly successful, the IT folks need to meet the business half way. Developers should take the time to really understand what the business is trying to do, and what these new requirements are trying to accomplish. To borrow an example from an old friend of mine : ‘The IT team would love it if the requirements document said build an 8 oz plastic bottle because the success criteria is absolutely clear. But if the business was only looking for something to hold cup of water, a glass or a plastic cup would have done the job and taken half the time to build.’ If the IT team doesn’t understand what the business is trying to accomplish, their final product will not be the best possible answer.

The Solution: The key to building good requirements is multiple, in depth dialogues between the business client and the IT team. Much as it will pain folks to admit it, this can’t happen in a one hour meeting on a Friday afternoon. The business team should first work with the project lead. This can be a project manager, development manager or the actual application developer, depending on the size of the project. They should thoroughly go over the business case and the IT person should create a high level requirement document. Once this is complete and the business owner agrees with everything that is written, the IT lead needs to go back to the development team and have them review the document in detail – creating a list of questions or concerns that need to be addressed, and a list of assumptions, if any, that will be made. This list is then sent back to the business client and will form the basis for the first meeting between the full IT team and the business client. All developers and Quality Assurance team members that will be involved in the project should meet with the business client so that everyone is on the same page. The business client should approach this meeting as an opportunity to lay all of their cards on the table, describing everything that they need from the project. The IT team should view this like a legal discovery session, asking tons of questions and delving into the requirements at a very low level. The goal is not to attack the business client, but to gather as detailed information as possible. When the first session is over, the documented results are then re-distributed to all parties and additional sessions are scheduled based on how many additional gaps are defined. Note: these types of meetings need to take place, regardless of the development methodology. In a waterfall or RUP methodology, the requirements gathering sessions happen up front. In an AGILE methodology, the requirements gathering happens in smaller chunks, with a larger chunk taking place before the initial design is created. In either case, the scope of work should be clearly understood by the business client and the IT staff before any real work begins. The goal in all cases is a high degree of communication between the business and the IT staff and a mutual understanding of what is needed and why.

Please check out my website http://williamagrant.com