Over a million developers have joined DZone.

On Technical Debt and Craftsmanship

· Java Zone

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

Technical debt is something we, as developers, live with every day. Sometimes a pragmatic solution needs to take precedence over a perfect solution. A software craftsmanship purist would argue that you should always strive for the perfect solution but in my opinion this is not always practical.

A friend of mine, Tay was telling me about a client he was doing some work for. Now Tay is a software craftsman. His code is tested and refactored to the nth degree. Everybody needs a guy like Tay in their team to keep them on the straight and narrow. Anyway Tay was telling me about this client, and the client needed some work done like yesterday! This particular client had a unique software product and there were only a few competitors in the space in which he was selling. An enviable position to be in. But one of Tay’s client’s competitors had just come out with a feature that Tay’s client thought could be a bit of a killer.

So the client had asked Tay to implement the same feature in their offering. And he needed it quick so he didn’t lose market share.

Now Tay is no idiot when it comes to writing web apps and so he got his favourite IDE out and took at look at the problem. After a bit of head scratching he had come up with two ideas. He would still use TDD however one one approach would make the code harder to maintain going forward but would be quicker and the second approach would be easier to maintain but would take longer to code up.

So which way to jump?

From Tay’s experience he knew that there were nearly always trade-offs when coding up a piece of functionality. Getting this new feature could mean millions of pounds saved in revenue for his client. Coding it in a way which was more maintainable could also save his client money going forward. But what if he didn’t get the feature in on time? His client could lose enough market share for the revenue to reduce and cause serious cashflow problems, maybe even causing the client to go bust!

I think as a craftsman it is our duty not only to look at what level of craft we should put into our code but also the affect putting craft into our code affects our clients and their needs. After all without our clients we wouldn’t be here.

We should always strive to put as much quality in our code as possible. Use SOLID techniques and TDD when we can.

I also believe that sometimes we need to make a judgement call and sometimes take a less than optimal route to get the job done. We should always use those techniques which will make the code more robust, but sometimes I think you have to take a pragmatic decision and not be afraid of technical debt.

Are you a software craftsperson? How do you handle the tension between technical debt and craftsmanship? Leave a comment because I would love to know.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.


Published at DZone with permission of Chris Odell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}