5 ms·

Hidden Costs That Engineers Ignore

163 points by gsands 12y ago

zedpm 12y ago
The notion of holding a Code Purge Day (as Quora did) is excellent. Searching out and removing cruft in the code base results in a benefit that's hard to measure but easy to understand. Having more compact code without confusing distractions leads to easier comprehension and ought to make for faster bug fixes.
- aswanson 12y ago
  Exactly. The best line of code is the one you dont have to write. The second best is the one you can delete.
  - hawkice 12y ago
    My favorite aphorism for this is "There's no code like no code."
- arthurjj 12y ago
  One of the neat things my company does is give out a monthly award for person who (net) deleted the most code that month. It's in the form of a little rubber duck called the deletion-ducky. Competition can get pretty fierce for it. The nice thing about it being monthly, instead of one off, is that it keeps simplicity in the front of everyone's mind
logicallee 12y ago
This article repeats a meme, but is total BS. It's similar to saying "the hidden costs of being a founder" and then stating that if you do ever make a successful exit, you will have a lot of your time wasted by having to select bedlinen and other hidden costs of having made an exit. (the hidden cost to being a founder - you will be forced to work unpaid hours shopping for luxury bedlinen. so consider carefully.) Well guess what: that's not real technical (or founder) debt! 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-technical-debt-its-an-unhedged-call-option/ 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.
- aba_sababa 12y ago
  And then your teammate then takes a week to build an API that's only compatible with your hacked out code you wrote in twenty minutes. Now you've wasted both your time and her time when both need to be re-written.
  - logicallee 12y ago
    Yes, consider what has happened here carefully. Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) That does not make it technical debt of 1 day. It means it didn't actually exist. 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.
    - samstokes 12y ago
      Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) 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.
- hw 12y ago
  While I agree with you that the notion of 'technical debt' is being overused, I don't think the article is talking about hidden costs as technical debt, but is instead about how product and code complexity incurs hidden costs, some of which but not all can be construed as technical debt. 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.
stefs 12y ago
currently it looks like they ignored the hidden cost of being on the hn frontpage.
jonpress 12y ago
The problem is that as requirements grow, class structures are often kept the same but the 'glue logic' which operates on these structures becomes increasingly complex (you have to handle a growing number of edge cases). 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.
- cam- 12y ago
  If we get several bugs or the team recognizes that an area is becoming brittle we make a bug that one/two team members work on for the sprint to clean that entire area up. The PO has become used to these kinds of bugs/user-stories and prioritizes them.
wavegeek 12y ago
There is a good book about this. It changed my thinking about complexity. The key insight is that if you don't manage complexity you will drown in it. Complexity is OK as long as it really earns its keep. And a lot of complexity is not worth it. (I speak as a person who just spent 20 hours - less than the IRS's estimated 30 hours - filling in form W-8IMY for the IRS, a form which started as a bright idea by someone in congress). "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
- codezero 12y ago
  Thanks for this, very interesting, I'll give it a read. I've long wondered if the aversion to complexity in SV is at times pathological, that is, "it adds complexity" is often used as a reason not to commit to building something that would absolutely add long term benefits that outweigh the costs. I guess it's just harder to quantify potential future benefits against immediately obvious complexity, but all the same, I think pathologically avoiding complexity is just as bad as pathological complexity :)
seivan 12y ago
You can't do this for games. Sometimes a game needs a particular feature that has a ton of states and complexity. 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.
- yuliyp 12y ago
  You can't do what for games? Avoid complexity? You can certainly try! Some bits of complexity will creep in. The important thing is to be aware of the cost and judge it appropriately, don't give low estimates for complexity-adding features. Include efforts to refactor complex stuff in the time budget. This is the same for games as other things.
- ars 12y ago
  > You can't do this for games. 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.
soup10 12y ago
As a one man army indie game developer I basically can no longer maintain my code-base without going crazy because it's grown to the point where it's no longer a one man job. I knew this would be a problem, so keeping code complexity to a minimum has always been a priority, but it's no longer possible to keep up. Thankfully it's reached maturity as a product and is a fun and profitable game. Many people think i'm 'brilliant' when they see the product and they hear i'm the only the developer and it's a custom 3d engine. But truth of the matter is much of my brilliance was stubbornness and cleverness in keeping things simple and code complexity to a minimum. The problem is you run out of memory in your brain. You forget how systems work. You have to trace back through the code and "reload things". When you have to make a modification. 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
soup10 12y ago
As a one man army indie game developer I basically can no longer maintain my code-base without going crazy because it's grown to the point where it's no longer a one man job. I knew this would be a problem, so keeping code complexity to a minimum has always been a priority, but it's no longer possible to keep up. Thankfully it's reached maturity as a product and is a fun and profitable game. Many people think i'm 'brilliant' when they see the product and they hear i'm the only the developer and it's a custom 3d engine. But truth of the matter is much of my brilliance was stubbornness and cleverness in keeping things simple and code complexity to a minimum. The problem is you run out of memory in your brain. You forget how systems work. You have to trace back through the code and "reload things". When you have to make a modification. 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
mrlyc 12y ago
What worked for us was to do two versions of the program at the same time. 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.
- gsands 12y ago
  I love this. For a couple of reasons. 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.
- Kiro 12y ago
  We were doing something similar but the result was a mess. Sometimes version 1 needed something that depended on unreleased stuff in version 2. It lead to fragmentation where we developed two implementations of the same functionality.
saosebastiao 12y ago
Unfortunately, sometimes the simpler system is the one you don't yet understand, and the more complex system is the one you can create on your own using tools you do know. This is the reason we still see homegrown business rule systems despite the fact that they were pretty much perfected them by the late 70s, with several open source implementations as of the late 90s. It is also the reason you still see deadlocks and race conditions in parallel code. And it is the reason you see matrix factorizations using hadoop map reduce instead of MPI. 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.
jaynate 12y ago
In the world of enterprise software it's also easy to overlook the cost of implementation/setup of features on the services teams and customers. Is helpful to define nonfunctional requirements that deal with these ancillary concerns. 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.
gaius 12y ago
Matching passengers and drivers while adjusting prices to balance supply and demand is a complex and hard problem. So is routing questions and answers to the people most likely to answer and read them 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.
- nmjohn 12y ago
  This point is quite nitpicky, no? The sentence you quoted could have been removed from the article and the article would have largely been unchanged - my point being it seems dubious to critique an article for a tangential point in the introduction which has nothing to do with the premise of the article. 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.
  - gaius 12y ago
    Not at all; the structure of the piece is, these are all the impressive things I've done, so you should listen to my ideas. It would have been a stronger piece of writing if he'd just jumped straight in. Or, actually had done some impressive engineering. 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".
sunasra 12y ago
I am totally agree with 'Use data to prune unused features' point. 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.

163 points by gsands 12y ago

zedpm 12y ago

The notion of holding a Code Purge Day (as Quora did) is excellent. Searching out and removing cruft in the code base results in a benefit that's hard to measure but easy to understand. Having more compact code without confusing distractions leads to easier comprehension and ought to make for faster bug fixes.

aswanson 12y ago
Exactly. The best line of code is the one you dont have to write. The second best is the one you can delete.
- hawkice 12y ago
  My favorite aphorism for this is "There's no code like no code."
arthurjj 12y ago
One of the neat things my company does is give out a monthly award for person who (net) deleted the most code that month. It's in the form of a little rubber duck called the deletion-ducky. Competition can get pretty fierce for it. The nice thing about it being monthly, instead of one off, is that it keeps simplicity in the front of everyone's mind

logicallee 12y ago

This article repeats a meme, but is total BS. It's similar to saying "the hidden costs of being a founder" and then stating that if you do ever make a successful exit, you will have a lot of your time wasted by having to select bedlinen and other hidden costs of having made an exit. (the hidden cost to being a founder - you will be forced to work unpaid hours shopping for luxury bedlinen. so consider carefully.) Well guess what: that's not real technical (or founder) debt! 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-technical-debt-its-an-unhedged-call-option/ 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.

aba_sababa 12y ago
And then your teammate then takes a week to build an API that's only compatible with your hacked out code you wrote in twenty minutes. Now you've wasted both your time and her time when both need to be re-written.
- logicallee 12y ago
  Yes, consider what has happened here carefully. Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) That does not make it technical debt of 1 day. It means it didn't actually exist. 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.
  - samstokes 12y ago
    Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) 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.
hw 12y ago
While I agree with you that the notion of 'technical debt' is being overused, I don't think the article is talking about hidden costs as technical debt, but is instead about how product and code complexity incurs hidden costs, some of which but not all can be construed as technical debt. 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.

stefs 12y ago

currently it looks like they ignored the hidden cost of being on the hn frontpage.

jonpress 12y ago

The problem is that as requirements grow, class structures are often kept the same but the 'glue logic' which operates on these structures becomes increasingly complex (you have to handle a growing number of edge cases). 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.

cam- 12y ago
If we get several bugs or the team recognizes that an area is becoming brittle we make a bug that one/two team members work on for the sprint to clean that entire area up. The PO has become used to these kinds of bugs/user-stories and prioritizes them.

wavegeek 12y ago

There is a good book about this. It changed my thinking about complexity. The key insight is that if you don't manage complexity you will drown in it. Complexity is OK as long as it really earns its keep. And a lot of complexity is not worth it. (I speak as a person who just spent 20 hours - less than the IRS's estimated 30 hours - filling in form W-8IMY for the IRS, a form which started as a bright idea by someone in congress). "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

codezero 12y ago
Thanks for this, very interesting, I'll give it a read. I've long wondered if the aversion to complexity in SV is at times pathological, that is, "it adds complexity" is often used as a reason not to commit to building something that would absolutely add long term benefits that outweigh the costs. I guess it's just harder to quantify potential future benefits against immediately obvious complexity, but all the same, I think pathologically avoiding complexity is just as bad as pathological complexity :)

seivan 12y ago

You can't do this for games. Sometimes a game needs a particular feature that has a ton of states and complexity. 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.

yuliyp 12y ago
You can't do what for games? Avoid complexity? You can certainly try! Some bits of complexity will creep in. The important thing is to be aware of the cost and judge it appropriately, don't give low estimates for complexity-adding features. Include efforts to refactor complex stuff in the time budget. This is the same for games as other things.
ars 12y ago
> You can't do this for games. 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.

soup10 12y ago

As a one man army indie game developer I basically can no longer maintain my code-base without going crazy because it's grown to the point where it's no longer a one man job. I knew this would be a problem, so keeping code complexity to a minimum has always been a priority, but it's no longer possible to keep up. Thankfully it's reached maturity as a product and is a fun and profitable game. Many people think i'm 'brilliant' when they see the product and they hear i'm the only the developer and it's a custom 3d engine. But truth of the matter is much of my brilliance was stubbornness and cleverness in keeping things simple and code complexity to a minimum. The problem is you run out of memory in your brain. You forget how systems work. You have to trace back through the code and "reload things". When you have to make a modification. 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

soup10 12y ago

mrlyc 12y ago

What worked for us was to do two versions of the program at the same time. 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.

gsands 12y ago
I love this. For a couple of reasons. 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.
Kiro 12y ago
We were doing something similar but the result was a mess. Sometimes version 1 needed something that depended on unreleased stuff in version 2. It lead to fragmentation where we developed two implementations of the same functionality.

saosebastiao 12y ago

Unfortunately, sometimes the simpler system is the one you don't yet understand, and the more complex system is the one you can create on your own using tools you do know. This is the reason we still see homegrown business rule systems despite the fact that they were pretty much perfected them by the late 70s, with several open source implementations as of the late 90s. It is also the reason you still see deadlocks and race conditions in parallel code. And it is the reason you see matrix factorizations using hadoop map reduce instead of MPI. 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.

jaynate 12y ago

In the world of enterprise software it's also easy to overlook the cost of implementation/setup of features on the services teams and customers. Is helpful to define nonfunctional requirements that deal with these ancillary concerns. 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.

gaius 12y ago

Matching passengers and drivers while adjusting prices to balance supply and demand is a complex and hard problem. So is routing questions and answers to the people most likely to answer and read them 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.

nmjohn 12y ago
This point is quite nitpicky, no? The sentence you quoted could have been removed from the article and the article would have largely been unchanged - my point being it seems dubious to critique an article for a tangential point in the introduction which has nothing to do with the premise of the article. 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.
- gaius 12y ago
  Not at all; the structure of the piece is, these are all the impressive things I've done, so you should listen to my ideas. It would have been a stronger piece of writing if he'd just jumped straight in. Or, actually had done some impressive engineering. 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".

sunasra 12y ago

I am totally agree with 'Use data to prune unused features' point. 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.