Breaking the Rules Part I: Create Quality Software the First Time

Break the Rule: You do not have time not to do it the right way the first time.

There seems to be some unwritten rule that you do not have time to do it right the first time. Break this rule now. You do not have time not to do it right the first time.

Let’s face it, there is always a business end to developing software. There is a need and addressing that need quickly makes a difference. Hopefully, the business end (management) has a plan or a product road map. It is called a road map for a reason – there is a starting point, a destination, and points of interest along the way. There may be short-cuts to your destination, but you still have a road to travel and a distance between here and there.

For this reason, you need to plan for a successful road trip. You will need to meet milestones and deliver software features, that is what you do and that is what makes you valuable. Since there will be a need for your services for this journey, doing it the right way the first time will allow you to continue and end the road trip successfully.

As a developer though, how many times have you seen a project that seemed perfect in the beginning turn out to be total chaos down the road? Why does this happen? It happens because it becomes more difficult to add new features and deliver on time as the source code becomes more complex. There was never a plan to handle the complexity that came later. There was never a plan in place to create consistent and maintainable code. There was never a plan to create unit tests to determine what is and what is not working – kind of like a dashboard on your car. The “Check Software Engine” light is on, but no one knows what to do.

Only a fool would start a road trip without checking the oil and tires. In real life, we do the right things because they are important. In software development, it should be the same way. I guarantee that doing it the right way the first time doesn’t take more time. You can deliver more features and deliver them on time. You will hit the milestones of the project. And the best benefit is that you will enjoy the journey along the way until you reach your destination. I have seen small and large teams do this. It is not impossible.

Here are five (5) ways to create quality software the first time.

  1. Create business logic using classes – create a framework, or use the Vergosity framework
  2. Implement business rules using a Business Rule Engine – create a rule engine, or use the Vergosity Business Rule engine.
  3. Implement unit testing early and throughout the development process. This is your safety net – kind of like road-side insurance.
  4. Implement logging for your application early.
  5. Use a well-defined architecture that includes proper abstraction between the layers of your application.

Test-Driven Development – A Life-Style or a Process?

Recently, I had the pleasure of working with a talented team of software engineers to increase their awareness of how they could do more with test-driven development. The team was highly skilled and knew how to write unit tests. One of the discoveries during the process, was that they needed to make their software more testable to enable the test-driven approach. We covered a lot of ground during the 2.5 days of work. One of the best outcomes of the session, was that testing is really more of a developer lifestyle than just a process. We realized that the process of testing really helped with the design of the software and that there was a lot more analysis and design when taking the test-driven approach.

It is important to take time to think before you write code – and sometimes this thinking should be as non-technical as possible. It shouldn’t involve writing code or the IDE – maybe some simple pencil sketches are all that is required. TDD doesn’t rule out thinking, analysis, or design before you write code. It is part of the natural process and needs to be included in the flow of TDD. Here is my slide deck used to facilitate some of the discussion.

Slide Deck: Test-Driven Development

Fries on the Floor

A story about technical debt…

I work on an application that tracks millions of requests each day. There was a time when we recycled the application pools of the web servers in the web farm. During this process we lost a few seconds of processing – in which there may be a few thousands requests not tracked. I referred to this in a meeting awhile back as, “fries on the floor.” The analogy made me think about things that matter when they are added up over time.

It reminded me of the typical fast food restaurant. You look behind the counter and what do you see? A few fries on the floor right? Not a big deal. Moving at the speed of fast food and dropping a few fries on the floor is all part of business. But I got to thinking about how many fries (pounds) that adds up to be for a single restaurant, or all restaurants in a single day over a week, month, or year. A few fries on the floor probably add up to tons of wasted french fries. Why am I concerned? I’m not too concerned about the fries, really. But I am concerned with the mentality of waste and letting things build up over time – things that create technical debt.

Technical Debt

Using the same analogy to the software development life cycle, we are leaving some fries on the floor or in essence creating some technical debt. We do this on each sprint, cycle, project, new feature added, etc. Business moves pretty fast and most companies that develop their own software or solutions hire the minimum number of developers for the job less one, right? We’re all pretty busy. The problem is that we move on to the next round of features or stories to implement. And of course many of us are eager to do so – doing something new and different is pretty cool; and we are eager to please. But we are creating technical debt. It may not feel like it in the beginning, but over time the debt accumulates and starts to compound. Then we are in trouble. You have to address the debt.

Why not leave a few less fries on the floor each day by doing some or any of the following:

  • design first
  • thorough business analysis
  • peer code reviews (daily)
  • refactoring loose code
  • test-driven development
  • unit testing for a specified amount of code coverage
  • alternate flow unit testing (negative tests)
  • performance analysis of the new release
  • making specific elements configurable vs. hard-coded
  • refactoring to a design pattern
  • documentation of the feature
  • code review by team
  • ________________ (add more items here)
I’m not saying we have to do all of the above all of the time. But it would be fair to say that there are fries on the floor at 5pm each day. They may not seem like a lot at the end of the day. But if we tracked what we didn’t do over time and how it effected our future development – it might surprise us! Maybe we can leave a few less fries on the floor by taking the time each day to do what we know needs to be done. This may increase the development effort. But we should be including many of these elements in our estimation. Then we can communicate the estimates and progress accurately and honestly with our project managers, CTOs, or IT Directors/Managers. In this everything has to be done yesterday mentality, it is going to be difficult. However, if we stick to the art of pragmatic programming, we can reduce a significant amount of technical debt. The benefits will be seen and recognized over time.