It is common for legacy products to have a lot of technical debt. How to manage estimating bug fixes or new features?
Here’s an example, the team decides to jump 2 versions ahead with their Java installer software. The new version installs Java 1.8 as the default JVM. The product needs 1.7,which of course is determined during testing.
While product A was able to get receive the installer update without a hitch, product B had this and other customized (and un-documented) build/configuration steps. Product A was recently updated to Java 1.8.
So if one offers an estimate on updating the projects, even with A’s experience, the estimate is likely to be off by 100% or more. When dev’s provide estimates, there is a natural inclination to meet that estimate (in terms of calendar days, not hours), as a matter of professional pride.
Stepping back, it’s clear estimating has many problems, especially as it destroy’s the business’s ability perform any planning. The status quo has the developer asked to perform it again & again. If however, the business set a budget for the change, then a great learning opportunity smacks everyone in the face. It’s far better for development to ask the business for a budget. If business doesn’t like the outcome, then the assignment should be transferred to another team to validate or explore other options. This in and of itself is a great learning opportunity for that team as well, as silos are being broken up and knowledge is being gained by many.
Perhaps one could argue there is a difference between known & unknown technical debt. Perhaps one can assume given a reasonable number of automated tests that known technical debt could be estimated. There may be an assumption the amount of known debt is, er, “known” or finite.
Software experts have often spoken of the need to isolate your product from any specific implementation. If anything, this has become more important today.
There is great fun & profit in hacking software. Many are doing it, pretty much around the clock. These hacks can be purchased on various websites, in fact; no news here, just re-stating basic facts.
Now suppose your software uses a package from vendor X and X has chosen to use OpenSSL within. As we know, OpenSSL is a rich target with many known & fixed problems, but bad dudes are a persistent lot and will continue to attack. So then, if vendor X for some reason cannot keep pace with the changes to OpenSSL, guess who is left stranded?
Since your team has put in a layer surrounding Vendor X, you have long been considering Vendor Y’s offering and have a plan to swap them out, if need be.
And now you are totally bored reading about something completed eons ago…
Many companies create re-usable code whereby it would be profitable to share across business units. If the bureaucratic friction within is too expensive, it may make more sense to use external code.
For example, let’s say the company sells PDF conversion software. With that sale, there must be a licensing agreement that documents restrictions for the purchaser, as well as other legal constraints.
If another product includes the same PDF conversion software, say for a newspaper website production package, all of the prior licensing must be rolled up into that offering as well. This all seems simple and straightforward, until it gets complicated.
As more and more business units or products wish to share home-grown technologies, the licensing structures can get complex. Maybe not today, but as this sharing expands & contracts over different products or business units over months and years, the amount of practices, side-deals, exceptions and policy changes make for a special quagmire.
Silly of you to think that all you needed to do was include the conversion software and be home free! Compare these burdens with the well-documented, published, legal document that accompanies the external software.
So an engineer has been laboring over a set of technology “X” projects that have staggering amounts of technical debt. He observes that when the prior engineers didn’t have the training, inclination or encouragement to make necessary improvements, this debt is a natural outcome accrued at a compound rate over many years.
When said software veteran with decades of experience takes this over, works with it for several months and renders his opinion of the state of affairs, what is the outcome? Note the company & management team has paid several hundreds of thousands of dollars for this engineers time over the past couple of years. Obviously this company has paid quite a lot for any opinions rendered.
So what happened to said opinion (and re-articulated many times); nothing.
Until a book is found on the technology… Such a book cost, what $40, $50 – let’s get crazy: $200! On page 463, that author stated: “If your projects are organized in this way, they will become unmanageable.” Huh. When the management team sees this, then immediate approval for re-writing is granted.
Does the management team realize how depressing this is? Why is this engineer kept around if their opinion is competitive with a $40 book?