4 ms·

Software development has some “special” traits that are not necessarily covered by this analysis. For one thing, you can’t just measure what a developer has do

Software development has some “special” traits that are not necessarily covered by this analysis. For one thing, you can’t just measure what a developer has done; you need some sense of how easy maintenance is going to be. Given two brilliant solutions that required an extraordinary developer to create, one may be an indecipherable mess and the other may have been built in a way that makes typical maintenance tasks very straightforward. From the outside they may look the same but the cost difference is huge. Some people are really good at writing solid code, and replacing them may mean introducing headaches that you didn’t have before. Also, a particularly weird bug may cost your team tremendous amounts of time (and possibly more), and you may not have the right people to deal with that quickly. Also, “cost of hiring” probably isn’t referring to the cost of having a really bad hiring staff. If those people are not doing a good job of filtering résumés or otherwise finding the right people, or if they leave good candidates dying on the vine due to slow response times, there is a big cost. It is extremely important for companies to look good from the outside to attract candidates.

Bartweiss 10y ago
Maintenance (and maintainability) are definitely key questions for software development. The first point, about keeping people who write maintainable code, I agree with 100%. The second one, about keeping codebase expertise, seems complicated. On one hand, we all know there are weird bugs and edge cases best handled by knowing the code intimately. What's 20 hours of QA and engineering for an unfamiliar team can be a 5 minute tweak for the guy who wrote the method, even with clear code and good tests. Weird bugs do happen, and just knowing that what it isn't can help with finding some awful probabilistic issue. On the other hand, I wonder if this is a "controlled burn" kind of issue. Everyone's heard of systems that work fine for 20 years and then explode as soon as the expert leaves. Normally that's a design and maintainability issue, but at some level we're talking about bus factor here. You're definitely trading fewer crises for worse crises, but I don't know the rate on the tradeoff. Obviously unplanned turnover is still a huge issue, but I do wonder what the right balance is on "just knows how to fix it" versus "institutional knowledge is safer than personal".
- humanrebar 10y ago
  It's possible to write bug or enhancement requests against the system if it takes too long for new contributors to come up to speed. I do this from time to time. It's important to remember that specify specific exit criteria, like "it should take one command instead of fifteen to add a new request to the XYZ endpoint."
lutorm 10y ago
I'd venture to say this is not limited to software. If you design some hardware, or mechanichal machine or whatever, future maintenance const is a key factory. Just look at e.g. cars.

Bartweiss 10y ago

Maintenance (and maintainability) are definitely key questions for software development. The first point, about keeping people who write maintainable code, I agree with 100%. The second one, about keeping codebase expertise, seems complicated. On one hand, we all know there are weird bugs and edge cases best handled by knowing the code intimately. What's 20 hours of QA and engineering for an unfamiliar team can be a 5 minute tweak for the guy who wrote the method, even with clear code and good tests. Weird bugs do happen, and just knowing that what it isn't can help with finding some awful probabilistic issue. On the other hand, I wonder if this is a "controlled burn" kind of issue. Everyone's heard of systems that work fine for 20 years and then explode as soon as the expert leaves. Normally that's a design and maintainability issue, but at some level we're talking about bus factor here. You're definitely trading fewer crises for worse crises, but I don't know the rate on the tradeoff. Obviously unplanned turnover is still a huge issue, but I do wonder what the right balance is on "just knows how to fix it" versus "institutional knowledge is safer than personal".

humanrebar 10y ago
It's possible to write bug or enhancement requests against the system if it takes too long for new contributors to come up to speed. I do this from time to time. It's important to remember that specify specific exit criteria, like "it should take one command instead of fifteen to add a new request to the XYZ endpoint."

lutorm 10y ago

I'd venture to say this is not limited to software. If you design some hardware, or mechanichal machine or whatever, future maintenance const is a key factory. Just look at e.g. cars.