Hidden Costs That Engineers Ignore
theeffectiveengineer.com
theeffectiveengineer.com
Version one had simple functionality. Version two had all the bells and whistles dreamt up by the programmers and the customer while we were working on version one. Those were added to a todo list for version two. They were not implemented in version one.
That kept up the flow of ideas but didn't disrupt the project. It made the programmers feel appreciated while giving us an outline for the next version so our competitors couldn't keep up.
What surprised me was that the whole team got into the spirit of the thing. When someone came to me with an idea, cries of "Version two! Version two!" echoed around the programming room.
1/I often discover new things and have new thoughts and ideas along the way of an implementation which hadn't presented themselves previously.
2/I think it's a great way to avoid overthinking a feature or arguing too much for or against it. If nearing a majority consensus (with oneself or team) and there is time to spare, add it to Version 2 -- advantages being point #1 above, and having it prepared should it be deemed worthy to be merged to Version 1. I've heard that having features in the chamber ready to release is something big corps commonly do.
There is a point where the glue logic becomes very complex (and brittle) - At that point, the best thing to do is to redesign part of the system's class structure.
If your components (at all levels of your class hierarchy) are specific about their own behaviors, it means that you can use simpler glue logic to make them work together.
When you need to handle a lot of complex use cases, it's often useful to have many specific classes which share the same interface and can be used interchangeably.
And when these bullshit foundational design decisions are made, the "improvements" that the engineers make to the system later are almost always a reduction in fidelity to the real world process that is being modeled, instead of a move toward a system that drastially simplifies your system while simultaneously improving fidelity to the real world but might mean you have to read a wikipedia article for a few minutes.
"Conquering Complexity in Your Business: How Wal-Mart, Toyota, and Other Top Companies Are Breaking Through the Ceiling on Profits and Growth Paperback" by Michael L. George and Stephen A. Wilson
The nice thing about it being monthly, instead of one off, is that it keeps simplicity in the front of everyone's mind
I used to work with a guy who worked on the compute infrastructure that CERN uses to sift the petabytes of data they get from the LHC. That's a hard problem.
And that's the problem with web guys, they think the web is all of computing, yield management has been done by airlines and hotels for DECADES. It is very, very far from breaking novel ground at this point.
Now the points he makes about the TCO of a new feature are valid but please, if you're going to brag, be prepared for people to yawn.
I think what it really is, is some people just like to complain about "web guys" every opportunity they get. And while your criticism may have been perfectly valid, it is entirely irrelevant to this article.
There's a bit of ageism there too. Über's yield management code could probably have been written by one grey haired guy from United Airlines or Marriott. Instead they got a whole bunch of twenty something's who think they're doing "data science".
The only thing you can do is 1)Mitigate that by isolate it 2)Separation of concern
You could have a component that's fuck-all complex, but as long as it's a single, isolated component, that can be disabled by
messedUpComponent.isEnabled = false, then I'm ok.
Sure you can. For example people need to move around in the game. You can add rideable objects - or not. Usually you don't need to ride something for the game - it's just cool. So this is complexity you can remove.
You can take it a second step - assume riding is required. Do you want various types? Say you ride a horse - do you need multiple colors and sizes of horses?
Or something as simple as allowing the character to change hats.
When I hit my human ram capacity so to speak, i was extremely frustrated that I couldn't make the boundlessly quick progress that I used to. But then you get used to it, and just accept that it will take time when you switch from one subsystem to the other, to load up the relevant parts of the code into your human ram in order to do be able to do the work you want to do.
The simpler and more straightforward the program architecture, the easier it is to jump into and out of and write new code. Of course understanding what your product is and is going to be helps tremendously in making sure you can design your program in a sensible way.... I've been lucky enough to have a firm intuitive understanding of future the design of the game and it's features as it was being formed. (not being at the mercy of clients or bad managers is a wonderful thing)
What i've noticed is a big difference from me and friends with small development studios that accomplish less with a lot more sweat. Is that I don't develop fully featured flexible systems when simple ones will do, I don't roll my own code when good/simple libraries or apis exist. I'm trying to make my product a work of art, and the code is functional and simple. Where often I see other good engineers try to make their code the work of art. Which leads to lots unnecessary code complexity because they engineer systems designed to be future proof for everything, instead of of what realistically will be necessary for the future of the project or projects. A system with 30 components is easier to understand and easier to maintain than a system with 100. More functions, more objects, and more abstractions. Often mean more components and code complexity. Which ultimately means it's going to take more brainpower to get anything done. Which is why it takes teams of 100s to maintain large enterprise software projects where the incremental updates change very little even though the engineers working on it are educated well trained people. shrug
This has been a bane for me in my work. I have termed it lasagna code: lots of layers with a little filling in between each. Often, each layer is isolating things for which there is little-to-zero reason to ever suspect that they will need to change. I've even seen attempts to abstract away data model... As if the entire program wouldn't have to be modified if the data model changed. I have learned to design and code only to known requirements. All the extra time saved in design, coding, and maintenance of the easier reduced system more than pays for the small redesigns necessary when things shift.
I'm in the same position, except that it was never a priority for me. Even if I knew it would create a disaster in the future I prioritized getting things done. Basically I had the game idea and started coding without even thinking about architecture or maintainability so you can imagine what a mess my codebase is.
Still, I regret nothing since without this mindset there would be no game to speak of.
do you have a link to your project? i think one-person, deep projects are interesting.
Also all of these issues highlight why product management needs to have a working knowledge of technology and the related costs of various trade offs.
It might happened that some features were introduced years ago based on demand. But It would be not usable for now. Still those features are maintained. I believe those features should be removed which eventually gives you space to work on innovative features for same product.
The idea of calling this stuff technical debt is simply laughable. there's no debt. you don't owe shit.
hint: if you code something up in 20 minutes you still don't have to do all that other stuff, you can just ignore it, and throw away the twenty minutes of code if it's not better than not having it. if you become a millionaire you don't have to do all that stuff, you can just ignore it.
Let me put it another way. Say you're an MBA who can't code anything but excel formulas, yet you figured out how to get excel and powerpoint onto the web as a web app (wat). you create something and get 5,000 paying users and raise a $500,000 investment.
Have you created technical debt? No. You're at the same square as if someone gave you $500,000 to spend on developers against your mockups, except that you've validated them as well. There's no debt here. This article had it right:
http://www.higherorderlogic.com/2010/07/bad-code-isnt-techni...
The people that call this scenario (excel on the web) technical debt, think that somehow the MBA 'borrowed' the web app from a real dev, and now owes it in real development costs. That's a wrong way to think about it. In fact it's a ridiculous way to think about it.
Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments.
The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features.
As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call.
If you abandon the project (declare bankruptcy) then you never have to pay off the debt :)
If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset.
[1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!
It is like saying if I sell you a luxury mansion in the Hamptons that comes with nice hedges, for $1, I've really sold you an $800 interest payment, since you'll want to keep paying a gardener to trim the hedges, since if you don't it will hurt the price of your property long-term. you want to retain the value.
Do you see how considering the $1 as coming with an $800 interest payment (until you replace the hedges with gates at even greater cost) is a totally wrong way to consder what has just happened?
The fact that someone (you) will want to pay something doesn't make it anything close to debt. It's an unhedged (heh) call option.
Suppose you can make $20 if you spend $15 adding a feature. Obviously you should do it, right? You'll make $5. So you do.
Now the customer comes back and says the new feature doesn't work in some edge case and they won't pay the $20 unless you spend another $15 fixing it. At this point the original $15 is a sunk cost that you can't get back and you're presented with the original scenario again: Spend $15 to make $20. So now you've spent a total of $30 to make $20. This can repeat arbitrarily many times, putting you even further into the hole each time, until you recognize that hidden future costs mean that you're actually spending far more than $15 to make that $20.
The point of the debt analogy isn't to think about which parties are involved in the transaction; it's to think about the various kinds of costs involved in a decision, and the timescales over which they are paid.
From that point of view, if I can't afford the $800 hedge maintenance, then I shouldn't buy the mansion, even for $1. The strict analogy with debt breaks down a bit because I'm not paying you the $800, but it's still an ongoing cost I have to bear.
Edit to clarify, I'm still not saying debt is always bad. If I enjoy DIY and expect to have spare time, the cheap fixer-upper might be a great investment.
Code complexity is a good example. A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. That does not incur technical debt, but there is a hidden cost to maintain it given it's complex. On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase, which in the future he/she must pay down by refactoring / writing tests.
I tend to use the following terminology to distinguish necessary an unnecessary complexity:
| Easy Problem | Hard Problem
Easy Solution | Simple | Simplistic
Hard Solution | Complicated | Complex | Simple Problem | Complex Problem
Simple Solution | Easy | Elegant
Complex Solution | Stupid | NecessaryThat said, you can say the same case for your matrix: if there's a simple solution to a complex problem that actually solves it, is it really a complex problem?
>On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase, which in the future he/she must pay down by refactoring / writing tests.
This is simply not true. It is exactly the same that a non-developer who managed to get an Excel spreadsheet on the web 'borrowed' time from a real developer if it takes off. How can you borrow time from a non-existing person? This just doesn't make sense. It's just an unhedged call option.
Let me give you an offer for your services. Suppose I ask you for a quote for a very simple database app where employees can punch in and punch out with a password, and it tracks their daily time between the two. Nothing exists including a mock-up. You give me a quote. Now suppose that some genius actually got excel online witohut password authentication, in twenty minutes, they can put in a URL and click a button for a timestamp. That's what we've been using three weeks.
Does the existence of this change your offer? Yes: it reduces it, because you can see exactly what we'r ehappy with. (Unless you're trying to take advantage of the shop for being non-technical and therefore increase your quote; in this example we can just hide the existence of it from you. But this is a pathological case.)
So how can you call it debt, when in fact all it is is a slight asset (we got three weeks of utility from it) that took a non programmer half an hour, and reduces the price you quote to write it properly by a certain amount?
It's not debt in any sense of the word. You don't 'have' to pay it, any more than you 'had' to pay it before the hack.
In the other poster's example. if the salesperson sold something under cost, he sold it under cost. But if he sold it over cost, then his demo didn't become technical debt of the actual cost, it was just worth 20 minutes by a non-programmer, exactly as though he hadn't done it. Except he did do it, becuase it helped him get the sale. It was an option.
A third example would be saying that any time I buy something crappy that I expect to break, I am creating technical debt. For example if I buy a crappy screwdriver that will break on my third project, I've really signed up for the debt of a real screwdriver. Huh. This is not a very sane way to think about it. (It's actually a good analogy for technical debt, if I only bought it to produce the first two projects, and wouldn't have started on the third if the first two didn't get traction and get sold, or maybe even result in an investment.)
An analogy that isn't understandable by its target audience is useless.
Given that most programmers' idea of finance is of some kind of magic that happens that makes money pop up out of the ether, you need to use the appropriate analogy.
Maybe this is really a variation of the sunk cost fallacy or something similar, where if something seems to exist in some form, then people can't get their minds around the fact htat only 20 minutes of it actually exists and the rest simply doesn't and needs to be written if they want it to.
EDIT: all these downvoters are wrong. You say "now you have both wasted time" but the 20 minutes wasn't debt. It was the cost of the call option. For example in the other poster's example where a salesperson sold some code that didn't exist, his non-programming version of it wasn't debt toward the final thing: it was the cost he paid for the call option of being able to sell the whole thing. Hopefully he sold the option under cost :) his payment on the option has nothing to do with it.
Completely agree with this, and I wish it was said more often.
Prototypes are a valuable tool for testing hypotheses, but you have to discard them when testing is no longer all you're doing.
That means the key to responsible use of prototypes is to make sure you remain able to discard them! This is why shipping the prototype is so dangerous - because now you're locked into either maintaining the prototype, or a rewrite followed by a tricky, risky live migration.