Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

Is Your Code on the Naughty List? Ask Yourself Why.

Coding-naughty-nice-list-Santa.jpg

Christmas is coming and Father Christmas is making those last minutes checks to see if you've been naughty or nice!  But what about your code?  Would it make it onto the nice list or has it been naughty this year?

The Santa Claus of Development is on the lookout for code with technical debt; lots and lots of technical debt. But how did we get here? We can all identify technical debt and know that the chance of paying it back are slim, yet we carry on doing it.  No presents for this code :(

Technical debt is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution." (Wikipedia)



The reasons for the accrual of technical debt are rarely straight-forward. Pointing the finger at the development team can sometimes be unfair, and often the causes of technical debt are outside their control.

If there is a command & control culture, the development team are often given work with fixed scope, fixed cost and fixed deadlines – the first thing to slip in this scenario will be quality (and then probably the deadline).

If the focus is on project rather than product, the development team may not be concerned about the longer-term underlying product quality, and only be concerned about meeting the project scope on time. This is especially true if teams are created and disbanded on a per-project basis. It’s also true if teams are offered a bonus for delivering on time – this encourages an at-all-costs mentality.

That’s not to say that the fault never lies with the development team, and while it’s rare that developers don’t actually care about the work they do, there are a number of other reasons why developers can be the cause of technical debt.

If development teams/departments don’t set and monitor quality standards, you can end up with a wild-west approach to development, where anything goes! This creates a codebase which is unlikely to be full of readable code, and where different internal designs fight against each other. Working on this sort of code is hard – mistakes are easy to make, and the tendency is just to hack more code in and get out ASAP.

shutterstock_361977515.jpg

It’s also possible that developers themselves are naïve when it comes to good development practices. Are they aware of the SOLID principles?  Have they heard of design patterns (and anti-patterns) and GRASP? Do they know about refactoring and have they heard of Uncle Bob?

The best way to avoid technical debt is to not incur it in the first place. This approach to technical debt avoidance is an active one, and here’s a good starting list of things you can put in place to kick-start this approach:

  •      Empower the development team[s].  Make them the only people that can decide how developments are implemented, and, most importantly, let them decide how long things will take.
  •      Create quality standards as a department and then for each product. Make sure that, wherever possible, these are monitored through automation. There are good tools (like FxCop or FindBugs) where standards can be configured directly into the development environment or checked as part of the build process.
  •      Create development teams around a product or products and make them long-lived.  Bring the work to these teams rather than spinning teams up and tearing them down like cloud instances.  These teams will become high-performing and their estimates will be pretty good!
  •      Give your development teams an environment that encourages collaboration. Seat them together, give them whiteboards and break-out areas. If you can’t seat them together, give them the tools they need to collaborate across distance.
  •      Encourage your developers to continuously strive to improve. There are many ways to do this, such as team meetings to talk about a particular topic/technology/technique or to look to the wider development community. This can be a quick and informal route to improving the development skills of individuals.

Addressing technical debt is not simply a case of patching individual instances of it – if you’re serious about tackling it, you need to find the root cause, and you need to be prepared to look beyond the development team.

Hopefully the Santa Claus of Development will see that while your code may be naughty, it has a heart of gold. Who knows, maybe he’ll bring the development team a nice Agile pilot project or perhaps even an Agile Business Transformation?

Learn more about avoiding technical debt and Agile software development - check out our Certified Scrum Developer® courses from the training portfolio.

Find a Scrum Developer course

 

Did you know that Radtac is also offering a wide range of technical IT training, such as Oracle, MySQL, Red Hat, UNIX, Linux, Web development & programming?

Explore Technical IT Training courses

 

 

Author

Rich Levy

Rich Levy

As a Software developer, it is Richard’s responsibility to technically oversee all new and on-going development, maintaining hands-on presence to ensure a laser focus on quality. Richard also takes on-line and resource management responsibilities for development teams, along with ownership of development practices and R&D into new technologies & Agile methodologies. A Sun Certified Java Programmer and Developer, plus a Certified ScrumMaster and Kanban Practitioner. Read more