Software shortcuts: Pay down your tech debt. It's time to fix a price Technical debt: we probably create it every day. It happens when you do things that might get you closer to goal now, but which create problems that you’ll have to pay for later. The concept “technical debt” in software design and development comes from Agile development guru Ward Cunningham. He described what happens when you …
I don't think that the problem is due to devops, but rather that devops, to a degree, exacerbates it.
I think that the underlying problem is deep integration because it requires, even in modular systems, complex and specific interfaces which, because of their complexity and specificity, become fragile. A quickly changing environment, as with devops, just accelerates the process.
I'm of the opinion that loosely integrated systems are more easy to adapt and maintain but the usual downsides are higher interface overheads and lower performance.
In the days of Crosby Quality - it was deemed over-engineering to cater for anything other than the specification required. Making a design "open ended" was severely criticised as a waste of resources.
When OO became the norm - it could prove fatal if the specification had failed to cover a particular case. There could be no bending of the object model - it was often a tear down and start again.
"Why are you writing software that goes beyond the specification?"
Because any fule can see that version 2 will need some of the extensions that you are now making room for and unless you are *planning to go out of business* you need to be able to deliver version 2. Adding new features is always cheaper during the planning stage, so it makes sense to plan version 2 whilst you are writing version 1.
"Who's paying for your time to do this?"
Your *next* customer. (Ideally, that is your current customer in a year's time. I say "ideally" because existing customers are easier to find than new ones.)
"Where's the value to the business?"
Staying in business. Not having to find a completely new product, design and implement that product from scratch, and then find customers for that product who haven't met the customers for your existing product that is now tanking badly and dragging your reputation through the mud.
Of course, if you are the kind of IT pro who jumps from one job to another every couple of years to avoid the trail of shitstorms you are leaving in your wake, the future of your current employer may not be important to you. But your employer might care.
Why are you writing software that goes beyond the specification? Who's paying for your time to do this? Where's the value to the business?
Some of us try to avoid painting ourselves into corners. We try to anticipate, a little, how things might evolve in future releases. So if we see two ways of doing something, with little to choose between them except that one paints us into a corner and the other does not...
There is also this little thing called "non-functional requirements". Things like scalability, logging and monitoring subsystems, deployment and test tools, etc. Things which are rarely, if ever, mentioned by the project stakeholders, but if ignored during design and development then the final product is guaranteed to fail.
Because in the absence of a genuinely collaborative approach, a Requirements Bible (the "specification") is typically a minified version of what is actually required, pared back to meet budgetary, time or capacity constraints (called "priorities" by the business) despite the protests of the implementors who have to deal with the reality of delivering an actual working system, not painting numbers in a spreadsheet/project document to represent some accounting notion of what building a system looks like.
The time is paid for by getting as creative with time in the timesheeting system as the business are with the idea of "requirement" in a requirements document.
The value to the business is that they get a system that does what they need rather than only what they say they require.
In theory.
Tom Peters in one of his "Excellence" books in the 1980s gives an example of a complex missile project that was split between three companies. Instead of a rigid interface specification for the three components - it was deliberately left to be somewhat fuzzy. The result was the components were flexible enough to fit together without too much adjustment.
In my support career it was always a case that the more detailed the documentation for something - the more likely it was to be wrong in some detail. Usually a principle hadn't changed in the product's continued evolution - but the implementation had.
RE: Anonymous Coward
"Tom Peters in one of his "Excellence" books in the 1980s gives an example of a complex missile project that was split between three companies. Instead of a rigid interface specification for the three components - it was deliberately left to be somewhat fuzzy. The result was the components were flexible enough to fit together without too much adjustment."
How fuzzy?
http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/
"Agile development makes the idea of rapid failure much more acceptable because you’re looking at continuous improvement as a way to fail fast and fix it"
I can't help but think that this sentence contradicts the one later on that says that devs should say what they need from day one.
That said, I have worked on a few large projects myself, and no amount of planning can cover all the bumps you encounter during development. So, in a way, I concur with both statements in as much as you plan all you can beforhand, then you fix whatever potholes you encounter during development.
Still, all the articles I read about DevOps, this one included, make a lot more noise about developing, fixing, developing and fixing fast, rather than writing proper specs and having an execution plan that doesn't involve regular week-end marathon sessions.
To me Agile is a framework for rapid prototyping internally and/or for only the cutting edge areas that can handle it - certain trading desks as an example where you need to try to keep ahead of the competition. In a more general software environment if I were a customer getting "fail fast and fix it" code I might be just a little pissed off as it's the fails that make you lose momentum in your working day.
Both iOS and Android are 10 years old now, and a lot of early design choices made due to the limited CPU power, memory, etc. back then are baked into their basic design. Sure, it is possible to leave some of that behind as you drop support for older versions, but some changes are harder than others.
For instance, the way iOS was designed to "know" the display resolution, so that as higher DPI displays were used they did 2x and then 3x scaling of some UI elements. Using PDF or vector graphics for display would make the most sense if you were going from scratch today, as the CPUs/GPUs have sufficient horsepower and displays are high enough resolution that any artifacting would not be visible, but neither was true when it came out in 2007 (let alone when they began the project in 2002) The 1x displays are EOL, as are the 3.5" sizes, but it is still a detail that adds work for app developers today.
Excellent write-up man. I am a mobile app developer myself & I can surely understand the limitations we sometimes face while dealing with the customers. The most annoying part is, when we want to develop something but the client fails to understand our vision. As one of my friend who works in an app development agency (https://www.branex.com/mobile-app-development/) said it best "Ask the price of your experience, not your hours.
and another article on theRegisters pages today asks
"Why isn't digital fixing the productivity puzzle? Paying people better matters just as much. Maybe more so ?" "https://www.theregister.co.uk/2018/02/23/mckinsey_productivity_puzzle_and_digital/"
Where you say it's all just grist for the mill, because as one gets a step closer to completing a project, it all gets a step closer to being obsolete.
a merry-go-round debt machine. I hope the purpose of the project was worth it.
Inflation is lack of productivity in spending - debt is just spending
It can be a difficult conundrum. On the one hand, a team of developers are sat there waiting to build the best system they can dream of, on the other, is the client who wants it cheaper than you've quoted for and by tomorrow. The management team want the work to pay everyone's salaries and it almost always results in a system which has been heavily compromised.
No one cares until the support team need to constantly fix things or the client can't add an extra feature without it breaking something else.Then it's always our fault.
This word is not mentioned once in the piece, yet it is arguably the biggest BYOTB (Bite You On the Bum) item of Technical Debt that can be taken out, as can be seen, for example, with the number of vulnerabilities with IoT and unsecured Cloud Buckets being reported. The problem with a developer grappling with something new is to get the damn thing working for now, and come back to configure it securely later.
API providers want you to use their creation, so they don't want to rock the boat and refuse to work with default credentials, but there should be some kind of nagware built in (stretching the metaphor, an IOU) to alert the developer, on a regular basis until the debt is repaid. Unfortunately, there will be developers out there who will "sink" such reminders, rather than act upon them.
"Nevertheless, it faces a decision: should it spend time and money fixing the problem, or should it kick the can down the road?"
In my experience, companies almost ALWAYS choose the latter unless the problem can be fixed quickly and easily. I have got into metaphorical "knock down, drag out" fights with previous companies regarding this sort of thing, and bone headed design decisions.
Decisions that cost them 20% more now, vs costing them 200%+ later (later being within 2 years) and almost without fail they choose the former.
So when the Titanic finally hits the massive Iceburg I warned them about, I get the emails and phone calls about how they can deal with it.
When this happens I give them a fair and honest assessment of what it will take to fix, and quietly add 30% onto my consulting fee as an "idiot tax"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
