5 ms·

I've had occasion to think a lot about the relationship of quality to long term productivity. The remarkable thing about building software quickly is that if yo

by Joeri 12y ago

I've had occasion to think a lot about the relationship of quality to long term productivity. The remarkable thing about building software quickly is that if you focus on speed, cutting quality where needed to "move forward", you end up slowing down after a while, due to the build-up of technical debt. A continued focus on speed will typically result in slower development, and a low-quality product, a sort of worst of both worlds scenario. On the other hand, if you focus on quality, you end up making choices that enable fast development. You make sure you have high-quality requirements and a deep business domain insight in the whole team, which means you end up writing only that code which you truly need, and write it in the right order (most important features first). You make sure you have code that is well-covered by tests, which as a happy side-effect makes it easy to adapt to new requirements. You focus on having a high-quality deployment process, so the amount of customer issues that result from a broken deployment go down reducing the load on your dev and support teams. Focusing on quality first is not about gold-plating code, it's about making conscious decisions to have a high-quality process from front to back, and those decisions typically result in a highly efficient organization. It's no accident that those teams which manage to ship releases every few weeks (e.g. firefox, chrome, facebook) have world-class products. You have to focus on quality to go fast. This isn't just theory. Capers Jones actually measured this. The fastest delivery schedules were produced by teams with the highest quality product. http://www.parasoft.com/products/article.jsp?articleId=2769 http://www.parasoft.com/products/article.jsp?articleId=2769

mattgreenrocks 12y ago
This has been my experience as well. There is only one speed, and that is doing things well. I'm convinced a lot of developers have been completely brainwashed by the Business in believing they don't need to ship good code. They absolutely do, and the cost of it is high. The cost of maintaining bad code is much, much higher, however. Abdicating this responsibility reflects poorly on you, the developer. Much of the populism in software targets the insecurity of those who don't push themselves to ship great code: "getting things right is so hard! Just do the best you can and don't sweat those edge cases too much!" I sweat the edge cases when I'm writing the code in the first place because I'm incredibly lazy: I know the mental cost of re-creating all the context necessary to solve the problem later is very high, and I'd rather not return to the feature ever again.
- pandler 12y ago
  "A week of coding saved me 30 minutes of planning." That's one of my favorite sayings. >I sweat the edge cases when I'm writing the code in the first place because I'm incredibly lazy I like to front-load any problem solving and make sure I understand what I am getting myself into. What that looks like in practice is that, when designing architecture, I will write up a list of every scenario I can think of (within reason of course, also including future plans), and verbally test each scenario against my ideas. Essentially I try to build up the largest image I can of all the moving parts, and then narrow the scope back down to the present problem. Initially expanding the scope to include edge cases and potentially fictitious scenarios not only helps me isolate concerns, but I consequently understand the limitations of my implementation (which of those scenarios failed my verbal testing) and I have my notes for when/if I return. It's how I sate my natural desire to be overly-comprehensive without actually over-engineering everything; I am confident that what I build today is flexible and extensible enough to grow as it needs to. Sometimes I open a file I haven't opened in ages and I read a comment saying, "You're welcome to my future self", and I can't help but be thankful.
- sanderjd 12y ago
  There is a lot of truth to what you're saying, but while it sounds great for software that is built for its own sake, it sounds too uncompromising in most business settings. The fact is that most software is built in service to a business and the developer is (quite rightly) judged by the extent to which the software serves the business well, rather than the extent to which the code behind it is "good" or "bad". Ignoring that and attaching your identity to that quality of the code rather than the service to the business is folly. Having said that, it is all a short-term / long-term trade-off; "bad" code can be expedient and beneficial short-term while "good" code is almost always better in the long term. Deciding when to serve short-term and when to serve long-term business goals is the Hard Part, but the answer isn't to stubbornly apply one rule or another.
silverbax88 12y ago
I agree with this. I think sometimes it's hard to keep the balance between the developers who want to 'do things right' but spend far too much time designing a perfect solution, as opposed to many coders who rush to 'get something done' and build systems which quickly become impossible to maintain. I think after about 5-6 years of coding was when I came to the realization that everything you build 'the best way' will become awful coding practice in a few short years. But that writing things at blazing speed just to hack it together and get to work invariably leads to code which is written to work a single way and is a nightmare to maintain. I try to build small, flexible solutions which are as adaptable and maintainable as I can, with the awareness that whatever I build will be looked as as archaic in a few years, but it might still need to be maintained and upgraded. So, slow down a little, think a little, code a little slower, but don't spend 6 months planning the perfect code weapon either.
- mattgreenrocks 12y ago
  > everything you build 'the best way' will become awful coding practice in a few short years Disagree. Good architecture is almost timeless. It isn't always en vogue, but it is recognizable by being pleasant to maintain, conceptually cohesive, and simple. It usually resembles a domain model, with the UI, persistence, and everything else being built around it. It is a force at least as strong as the language used.
  - slightlycuban 12y ago
    > Good architecture is almost timeless. Never dismiss the dangers of over-engineering. While not as terrifying as under-engineering, how useful is a feature that exists only for the purity of design?
    - sheepmullet 12y ago
      Over-engineering is a problem because it usually results in a much more complicated design than you really need and wastes a lot of time. However, over-engineering and spending quality time thinking about the design and domain are two separate things and typically the more you think about the design and domain the less likely you are to over-engineer.
opendais 12y ago
As someone who works at a place that has tons of technical debt yet is able to release daily, I have to disagree. We have things that are 6+ months old without any of the normal best practices and are able to continue to ship w/o delay. Hell, for a new project/service two of my coworkers completely bypassed version control and unit tests. You can achieve high velocity without high quality. The cost to do that is sometimes you have an expensive production bug to fix. Please note, I'm not endorsing the way my coworkers do things but I've given up fighting any of it outside of my narrow slice of turf. ;)
- vinceguidry 12y ago
  This is a giant mess waiting to happen. Eventually the pace of development will slow to a crawl as incoherence of the technical decisions made build up. Then when the developers leave, forcing the next guy to work to understand now-legacy projects, all of a sudden the velocity the company has heretofore enjoyed will be gone.
  - opendais 12y ago
    It has been this way for 10 years and predates me working there. The pace of development remains unchanged as far as I can tell over the time I've worked there, regardless of whom left and was hired. I was pointing this out not to say it was a good thing but rather that the premise of [Quality == Speed] is flawed.
- sheepmullet 12y ago
  It sounds like releasing daily is part of your testing strategy in that you simply let your customers do the testing for you. Making small incremental changes with extensive manual testing can work. It just looks like you don't have to pay for the test effort. I've seen it a fair bit with internal projects at larger companies but most external customers I have met in my career would quickly switch products. Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason....
tfb 12y ago
Very well said. It's a shame so many project managers (and coders!) don't understand that any sufficiently sized project is a million times better off when investing more time at the beginning to lay a solid foundation. I like that more and more people are beginning to understand nowadays.
EdwardDiego 12y ago
> I've had occasion to think a lot about the relationship of quality to long term productivity. The remarkable thing about building software quickly is that if you focus on speed, cutting quality where needed to "move forward", you end up slowing down after a while, due to the build-up of technical debt. A continued focus on speed will typically result in slower development, and a low-quality product, a sort of worst of both worlds scenario. We're a typical "launch in 3 months!" start-up that is now 7 years old, and we've were so focused on growth and feature development to meet the market that technical debt just accumulated and accumulated. Eventually, technical debt began to have a real impact on business feature delivery, so we talked about it with our business team and came to an agreement that 30% of development time was ours to reduce this major risk. The end result is that over time, as quality improved, our business feature delivery has gotten better and faster - less bugs, and more features per sprint. We're very lucky to have our business team, I think.

by Joeri 12y ago

mattgreenrocks 12y ago

This has been my experience as well. There is only one speed, and that is doing things well. I'm convinced a lot of developers have been completely brainwashed by the Business in believing they don't need to ship good code. They absolutely do, and the cost of it is high. The cost of maintaining bad code is much, much higher, however. Abdicating this responsibility reflects poorly on you, the developer. Much of the populism in software targets the insecurity of those who don't push themselves to ship great code: "getting things right is so hard! Just do the best you can and don't sweat those edge cases too much!" I sweat the edge cases when I'm writing the code in the first place because I'm incredibly lazy: I know the mental cost of re-creating all the context necessary to solve the problem later is very high, and I'd rather not return to the feature ever again.

pandler 12y ago
"A week of coding saved me 30 minutes of planning." That's one of my favorite sayings. >I sweat the edge cases when I'm writing the code in the first place because I'm incredibly lazy I like to front-load any problem solving and make sure I understand what I am getting myself into. What that looks like in practice is that, when designing architecture, I will write up a list of every scenario I can think of (within reason of course, also including future plans), and verbally test each scenario against my ideas. Essentially I try to build up the largest image I can of all the moving parts, and then narrow the scope back down to the present problem. Initially expanding the scope to include edge cases and potentially fictitious scenarios not only helps me isolate concerns, but I consequently understand the limitations of my implementation (which of those scenarios failed my verbal testing) and I have my notes for when/if I return. It's how I sate my natural desire to be overly-comprehensive without actually over-engineering everything; I am confident that what I build today is flexible and extensible enough to grow as it needs to. Sometimes I open a file I haven't opened in ages and I read a comment saying, "You're welcome to my future self", and I can't help but be thankful.
sanderjd 12y ago
There is a lot of truth to what you're saying, but while it sounds great for software that is built for its own sake, it sounds too uncompromising in most business settings. The fact is that most software is built in service to a business and the developer is (quite rightly) judged by the extent to which the software serves the business well, rather than the extent to which the code behind it is "good" or "bad". Ignoring that and attaching your identity to that quality of the code rather than the service to the business is folly. Having said that, it is all a short-term / long-term trade-off; "bad" code can be expedient and beneficial short-term while "good" code is almost always better in the long term. Deciding when to serve short-term and when to serve long-term business goals is the Hard Part, but the answer isn't to stubbornly apply one rule or another.

silverbax88 12y ago

I agree with this. I think sometimes it's hard to keep the balance between the developers who want to 'do things right' but spend far too much time designing a perfect solution, as opposed to many coders who rush to 'get something done' and build systems which quickly become impossible to maintain. I think after about 5-6 years of coding was when I came to the realization that everything you build 'the best way' will become awful coding practice in a few short years. But that writing things at blazing speed just to hack it together and get to work invariably leads to code which is written to work a single way and is a nightmare to maintain. I try to build small, flexible solutions which are as adaptable and maintainable as I can, with the awareness that whatever I build will be looked as as archaic in a few years, but it might still need to be maintained and upgraded. So, slow down a little, think a little, code a little slower, but don't spend 6 months planning the perfect code weapon either.

mattgreenrocks 12y ago
> everything you build 'the best way' will become awful coding practice in a few short years Disagree. Good architecture is almost timeless. It isn't always en vogue, but it is recognizable by being pleasant to maintain, conceptually cohesive, and simple. It usually resembles a domain model, with the UI, persistence, and everything else being built around it. It is a force at least as strong as the language used.
- slightlycuban 12y ago
  > Good architecture is almost timeless. Never dismiss the dangers of over-engineering. While not as terrifying as under-engineering, how useful is a feature that exists only for the purity of design?
  - sheepmullet 12y ago
    Over-engineering is a problem because it usually results in a much more complicated design than you really need and wastes a lot of time. However, over-engineering and spending quality time thinking about the design and domain are two separate things and typically the more you think about the design and domain the less likely you are to over-engineer.

opendais 12y ago

As someone who works at a place that has tons of technical debt yet is able to release daily, I have to disagree. We have things that are 6+ months old without any of the normal best practices and are able to continue to ship w/o delay. Hell, for a new project/service two of my coworkers completely bypassed version control and unit tests. You can achieve high velocity without high quality. The cost to do that is sometimes you have an expensive production bug to fix. Please note, I'm not endorsing the way my coworkers do things but I've given up fighting any of it outside of my narrow slice of turf. ;)

vinceguidry 12y ago
This is a giant mess waiting to happen. Eventually the pace of development will slow to a crawl as incoherence of the technical decisions made build up. Then when the developers leave, forcing the next guy to work to understand now-legacy projects, all of a sudden the velocity the company has heretofore enjoyed will be gone.
- opendais 12y ago
  It has been this way for 10 years and predates me working there. The pace of development remains unchanged as far as I can tell over the time I've worked there, regardless of whom left and was hired. I was pointing this out not to say it was a good thing but rather that the premise of [Quality == Speed] is flawed.
sheepmullet 12y ago
It sounds like releasing daily is part of your testing strategy in that you simply let your customers do the testing for you. Making small incremental changes with extensive manual testing can work. It just looks like you don't have to pay for the test effort. I've seen it a fair bit with internal projects at larger companies but most external customers I have met in my career would quickly switch products. Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason....

tfb 12y ago

Very well said. It's a shame so many project managers (and coders!) don't understand that any sufficiently sized project is a million times better off when investing more time at the beginning to lay a solid foundation. I like that more and more people are beginning to understand nowadays.

EdwardDiego 12y ago

> I've had occasion to think a lot about the relationship of quality to long term productivity. The remarkable thing about building software quickly is that if you focus on speed, cutting quality where needed to "move forward", you end up slowing down after a while, due to the build-up of technical debt. A continued focus on speed will typically result in slower development, and a low-quality product, a sort of worst of both worlds scenario. We're a typical "launch in 3 months!" start-up that is now 7 years old, and we've were so focused on growth and feature development to meet the market that technical debt just accumulated and accumulated. Eventually, technical debt began to have a real impact on business feature delivery, so we talked about it with our business team and came to an agreement that 30% of development time was ours to reduce this major risk. The end result is that over time, as quality improved, our business feature delivery has gotten better and faster - less bugs, and more features per sprint. We're very lucky to have our business team, I think.