Steps for shortening the “Feedback Loop”

Information is the basic building block of software development and the most valuable form of information is useful feedback.  Feedback can come from the customer, the application’s users, and the development team. 

Regardless of the development methodology used the feedback loop is going to follow this basic flow

Looking at the Waterfall Methodology it’s very easy to see why it has become dated.  When you look at the basic flow 

The first opportunity for the developers to get feedback is at the end of the Verification stage.   Depending on the size of the project the Feedback Loop for Water Fall can take a couple of months to over a year.  This large gap between gathering requirements and implementing them makes it very difficult and costly to fix misunderstood or faulty requirements. 

What if the oil light in your car only gave you feed back every 30 min?   If you lose your drain plug, 30 min. is a long time to run without oil.  Software development is the same way, unless you’re getting regular feedback you won’t know something has gone wrong until it’s too late and you face costly refactors.

The hardest part of shortening the Feed Back loop is getting started.  It takes not only a change in behavior but also in thinking.  To quote a great American writer

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one.” ― Mark Twain

Step 1: Short Development Iterations

A project may look large and complex but keep in mind the Egyptian Pyramids where built one block at a time.  By breaking tasks down into more manageable items you are able to focus on very specific requirements and get feedback on that specific requirement.  I personally like 2-week iterations; it’s enough time to get things done, without getting lost in the details.

Step 2: Work in Small Teams 

The old adage “too many cooks spoil the broth” is just as true in software development.  Large teams have the same problems that large tasks do; there is too much going on.  Large teams require too much coordination, reduce individual responsibility, and only the most vocal get heard.

It has been my experience that three to five developers works best.  With fewer developers the team can lack skill set diversity, and with more you run into coordination and crowd mentality issues.  Never have a team of one. 

Step 3: Test Driven Development

Test Driven Development (TDD) is creating software tests to verify requirements, and then writing the software to perform that behavior.  This provides the developer with a personal feedback loop to know that what is being created has the expected result.  This also provides the added benefit of built in regression tests.  

Step 4: Continuous Integration

Continuous Integration (CI) is the process of merging code as soon as possible and running tests to verify everything is working as expected.  CI can be done manually but is more commonly done with a build server such as Team City, Jenkins, TFS, or others.  This quickly gives software developers feedback regarding overlapping work, quality control, and overall code health.  This step will quantifiablly improve the quality of your code more than any other single task you do.

Step 5: Automate as much as possible

When automating tasks you are going to get quicker feedback, a consistent behavior, inherent documentation (by way of the automation script), and reduces overall costs by freeing up resources to work on more important tasks.