Build quality in every line of code produced

There is one thing in common with a lot of software development companies, or companies that have a software development unit. That’s the system labeled with the monstrous name “Legacy”.

So what’s in it, really?

Is your software change tolerant? Is your software easy to adapt to changes proposed by the business, or the tech department itself? Are you software’s modules independent and enable change? Does your software enable quick releases?

If you were nodding your head negatively about all of the above mentioned questions, then… I am really sorry but you’re dealing with Legacy software.

There’s something else that makes the system really Legacy. That’s the lack of tests, tests on every level, checking your software on the low code level, up until functional / acceptance level.

That’s of course the toughest situation…

What many Development Managers, QA managers or CTO-s start thinking about when faced with situations like this is how to “fix” the bugs, how to “test” in the end; to make sure the product is ready, instead of thinking to build more quality into the process of software development itself.

What we do have in the end are:  frustrated managers of business, not hitting deadlines, frustrated developers, since they are not really coached how to build in the quality as well as process does not allow them to do so.

There’s also a worse side to it… every code produced when dealing with a Legacy system without appropriate tools to think about quality is simply “producing more legacy code”.

“There are two kinds of software—change tolerant software and legacy software. Some software systems are relatively easy to adapt to business and technology changes, and some software systems are difficult to change. These difficult-to-change systems have been labeled “legacy” systems in the software development world. Change tolerant software is characterized by limited dependencies and a comprehensive test harness that flags unintended consequences of change. So we can define legacy systems as systems that are not protected with a suite of tests. A corollary to this is that you are building legacy code every time you build software without associated tests.” (p. 166, Poppendieck [2007] )

One of the core principles of Lean is to “Build Quality In” and start thinking about it in the lowest level of the process.

Every single line of code can change/beak whole your system, so think about quality when writing even a line of code. Put the quality in every line of code your developers produce.

Build it in as early as possible in the process to avoid quality issues materializing. And build it in throughout the entire development process, not just at the end.

And what’s the most important there ARE tools that help you in your contest for quality.

Unit Tests, Integration Tests, Automated Acceptance Tests, and even functional tests that lie in between the Integration and Acceptance Tests.

Start changing your software development process, not to “think about quality in the end of the development process”, but “in the beginning”. If you are developing software using SCRUM or XP that would even help you a lot. Create a definition of done (DOD) for every User Story implemented, so that Unit Tests are required, that Automated Selenium tests are prepared. Set deadlines, make contests for writing unit tests and covering your product with different level of tests and do that during the development process. Introduce pair-programming, that’s fun and makes many silly mistakes to be caught in the early stages.

Just imagine for a moment: your team/developer works on a specific part/module of the Legacy system. They touch the code, change it, integrate a new feature, and, in order for the Story to be labeled as success, they also need to cover that feature, that chunk of software with unit tests.

Yes it will be difficult in the beginning, some people may complain that it is hard to cover with tests code that other have produced, your development may slow down for a moment. But can you imagine what the result will be?

  • Increased Unit Tests coverage, resulting in development bugs found extremely quickly. Run the tests daily, hourly and find out quickly as soon as something breaks
  • Start writing and increase Automated Acceptance tests (Selenium), check the whole functionality with one button click. Make your code automatically deploy on stage environment and test itself, come to the office in the morning having fresh tests results.
    Some people would even use core bunch of tests for monitoring the production system to make sure it runs correctly

If you develop your software using more agile-enabled and trendy technologies like Grails you may also consider writing integration tests or functional tests as well.

Powerful features emerge when you have this capability;

  • Built, Built, Built in quality. Reduction of the number of bugs
  • Reduced testing, because the test is now automated
  • Quicker and confident releases
  • Stabilized product, that may give the product management a chance to breath and re-define the product strategy
  • And, it is more fun for developers to work on a system that does behave predictably, doesn’t break anytime you touch it.

Simply, build quality in and make your system behave predictably. ©

This entry was posted in Agile, Lean, UnitTests, build quality in, development, testing and tagged , , , , , . Bookmark the permalink.

18 Responses to Build quality in every line of code produced

  1. Pingback: Narek Alaverdyan

  2. Pingback: Fernando Flores

  3. Pingback: Yan Avery

  4. Pingback: ESambo

  5. Urs Enzler says:

    True, true, true.
    We invest a lot to get quality into our software from the beginning. See this presentation http://www.planetgeek.ch/2010/06/17/code-quality-building-code-you-wont-curse-tomorrow/ to see how exactly.

  6. Narek Alaverdyan says:

    Very nice slides Urs, you’re on the right path!

  7. Pingback: Todd

  8. Pingback: Mika Ahopelto

  9. Pingback: Vin D'Amico

  10. Pingback: João Cerdeira

  11. Pingback: Tord Fauskanger

  12. Pingback: NeoChronos

  13. Pingback: Miguel Ángel Useche

  14. Pingback: Narek Alaverdyan

  15. Pingback: Ian Dickinson

  16. Pingback: Dirk Strauss

  17. Pingback: haocheng

  18. Pingback: Simon Brown

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>