DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Maintenance
  4. Technical Value is Business Value

Technical Value is Business Value

Make sure the sacrifice of technical debt is worth the result of clean design.

Jonathan Fries user avatar by
Jonathan Fries
·
Nov. 27, 18 · Opinion
Like (2)
Save
Tweet
Share
7.85K Views

Join the DZone community and get the full member experience.

Join For Free

When software developers are focused on good design — focused on taking the time to build a system the right way — they are focused on delivering business value for their customers or stakeholders.

They want good design because they know that in the medium and long-term a system with good design is easier to support and extend. This has clear business value — you can do more new stuff (features) for less money and you can fix problems (bugs) for less money.

More stuff for less money is good business value. In this way, technical value (good design and elegant coding) is business value.

A system with poor design may get more features built more quickly, but before long productivity will break down as the absence of plan results in fragmentation and chaos.

So in this way, you may get a quick hit of productivity, but in the long term you spend much more to get less which is bad.

There are times in every project where you reach an inflection point and what I described above needs to invert, temporarily. See this earlier article on the topic of technical debt and why sometimes the two can be at odds.

During the inversion, you take on technical debt to deliver some quick hits, once the underpinnings and architecture are in place so that you can ship a product on time to the marketplace.

Overall I think it is important to remember that the title of this article is true — in the long term good design is business value. Though sometimes you suspend that temporarily to deliver.

Sometimes business people want result right now and impatience with delivery is seen as a virtue. It can be. If it is a temporary inversion and not a long-term state of affairs.

It can be a real hindrance to long-term value if that state of affairs is chronic and without respite.

The decision to switch from the long-term view (important at the outset and through most of the life of a project) to the short-term view (often important at the end of the project, to deliver on time) is an emotional one.

People don't want to stop designing and they don't like the idea of taking on technical debt. However, it can't be avoided.

Your job as a software development leader is to listen and guide your team through this transition, AND to guide the business back, once the release is done.

Be aware of the emotions and motivations on both sides. Make the smart decision to ship. Also, make the smart decision to switch back and pay your technical debt when the next phase begins.

I think that we need to recognize two important things:

  1. A request to finish fast and on a timeline can feel arbitrary to people you need to articulate why.
  2. A request to finish fast and take on technical debt can also appear to be a request to stop delivering business value and do a shoddy job, you should avoid phrasing things so that it sounds this way.
  3. A choice to finish fast is a choice for the business value of now versus the business value of later which can be called many things: time value of money, a bird in the hand is worth two in the bush, or "we need to close this account". This can be a good and smart decision, but it is a decision with trade-offs. Acknowledge the trade-offs and press forward.
tech debt Software development

Published at DZone with permission of Jonathan Fries, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Problems of Cloud Cost Management: A Socio-Technical Analysis
  • A Simple Union Between .NET Core and Python
  • Top 10 Secure Coding Practices Every Developer Should Know
  • CQRS and MediatR Pattern Implementation Using .NET Core 6 Web API

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: