4 ms·

I managed to read the article before it went down, it was a pretty good read. Hopefully it comes back up soon. Anyway it makes a good point that business objec

by RyanZAG 13y ago

I managed to read the article before it went down, it was a pretty good read. Hopefully it comes back up soon. Anyway it makes a good point that business objectives come before "best practices" which I agree with, but you need to be careful when cutting corners that you don't actually sabotage your business objectives. The real discussion is actually on a risk level: if I cut corner X, I can potentially make revenue Y unless cutting corner X causes a problem and I incur loss Z. Cutting that corner is only good if P(no problems | cutting corner X) * Y > P (problems | cutting corner X) * Z If this equation looks tough, it's because it is tough. This is not an easy decision and you really need to be on top of your game to choose correctly. Alternatively, Y must be much bigger than Z and you have some faith in your shortcut. But for most dev work, a lot of the time you're going to be getting that equation wrong if you just guess it and it's why so many experienced devs will tell you not to cut corners.

codelap 13y ago
This estimate gets easier with a couple decades of experience. Which is why I'm always surprised by the agism vibe that sometimes resonates on HN.
d--b 13y ago
Your equation is quite incomplete. You must add the cost of making the code problem-free without cutting corners... Something like that: Revenue(no cutting corners) - Cost(no cutting corners) < Revenue(cutting corners) * P(no problem) - Loss(cutting corners) * P(problem) - Cost(cutting corners)
fennecfoxen 13y ago
It's also worth noting that he's talking about things like "if your client needs a Christmas promotion and you deliver on Dec 29". This sounds about right. But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I am currently developing and maintaining a system which powers an ongoing core business process. If it goes down, employees basically sit around unable to accomplish work. I hope that this system will be robust enough to continue operating for years, maybe decades, and anticipate that during that time four or five business units will either transition their processes to this system, or create new processes that use this system. Clean, quality, well-tested and extensible code clearly matter here in a way that they don't for a one-off Christmas 2013 promotion.
- Edmond 13y ago
  > But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consuming, we have been conditioned to view every piece of code we write as a "will be maintained forever" proposition. You don't generally see people using excel and worrying about the maintainability of their spreadsheets, because even sophisticated spreadsheets are trivial to create and so the default mentality is use and throwaway. This is a problem we are trying to tackle at my startup, a web developer tool that you can use to quickly put out applications to support day-to-day operations without obsessing about whether you're going to need to build a spaceship out of your current requirement.
  - the_af 13y ago
    I don't know that sophisticated spreadsheets are trivial to create. I've seen way too many weird, buggy and outright broken spreadsheets to believe that. I agree with you we should strive to make trivial things simple to write, and I also agree many programming tools fail at that, but I don't agree the software we write (in general) qualifies as trivial. Even some spreadsheets don't qualify. People writing them often make a horrible mess of it, unless they truly are simple spreadsheets.
    - Edmond 13y ago
      haha, I am sure there are many buggy spreadsheets out there... I didn't mean to suggest that it doesn't require knowledge and effort to put together a sophisticated spreadsheet but relative to building even the simplest web application, spreadsheets are a breeze.
    - arthurjj 13y ago
      As bad as the spread sheets can get it's helpful to have the business side make them. Even if you do have to implement a 'real' solution at least you now have a prototype to go off of
dj-wonk 13y ago
I like seeing this probabilistically! That said, I think the operative decision is "should I cut the corner?". If so, you should also factor in the p( ___ | not cut corner ) probabilities. So, you should cut the corner if the benefits exceed the costs. Written out: p(~P|C) * b(~P) - p(P|C) * c(P) > p(~P|~C) * b(~P) - p(P|~C) * c(P) Symbols: p = probability; b = benefits ($); c = costs ($); P = problems; ~P = no problems; C = cutting corner; ~C = not cutting corner. Rearranging to: p(~P|C) * b(~P) - p(~P|~C) * b(~P) > p(P|C) * c(P) - p(P|~C) * c(P) Then you get a simpler form: b(~P) * (p(~P|C) - p(~P|~C)) > c(P) * (p(P|C) - p(P|~C)) An amazing fortune awaits any person who can simply evaluate this inequality in real-world situations. It is also useful to know when the cost of gathering the information to evaluate the expression is not worth the potential benefit!
- RyanZAG 13y ago
  Definitely, thanks for adding in those terms. I kept it simpl(er) and left out the extra terms because I think that those two terms (benefit from cutting the corner vs loss of not cutting the corner) are the major factors when making the decision as they can have big effects on the business itself, while the other terms are just shifting around a bit of extra money/time. Maybe. It would depend on the corner. Everyone just thumb sucks it in the end anyway - I'll just embed this domain name in the distributed binary, nobody will ever steal our domain name! Technically someone at this point should pull up the statistics for stolen domain names to get an estimate for the probability, and work out how much it would cost to set up a system to pull a correct domain name from a backup, and then work out the cost to redistribute all the binaries to end users whose software won't be working for some time. I doubt anybody has ever done that particular calculation.

by RyanZAG 13y ago

codelap 13y ago

This estimate gets easier with a couple decades of experience. Which is why I'm always surprised by the agism vibe that sometimes resonates on HN.

d--b 13y ago

Your equation is quite incomplete. You must add the cost of making the code problem-free without cutting corners... Something like that: Revenue(no cutting corners) - Cost(no cutting corners) < Revenue(cutting corners) * P(no problem) - Loss(cutting corners) * P(problem) - Cost(cutting corners)

fennecfoxen 13y ago

It's also worth noting that he's talking about things like "if your client needs a Christmas promotion and you deliver on Dec 29". This sounds about right. But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I am currently developing and maintaining a system which powers an ongoing core business process. If it goes down, employees basically sit around unable to accomplish work. I hope that this system will be robust enough to continue operating for years, maybe decades, and anticipate that during that time four or five business units will either transition their processes to this system, or create new processes that use this system. Clean, quality, well-tested and extensible code clearly matter here in a way that they don't for a one-off Christmas 2013 promotion.

Edmond 13y ago
> But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consuming, we have been conditioned to view every piece of code we write as a "will be maintained forever" proposition. You don't generally see people using excel and worrying about the maintainability of their spreadsheets, because even sophisticated spreadsheets are trivial to create and so the default mentality is use and throwaway. This is a problem we are trying to tackle at my startup, a web developer tool that you can use to quickly put out applications to support day-to-day operations without obsessing about whether you're going to need to build a spaceship out of your current requirement.
- the_af 13y ago
  I don't know that sophisticated spreadsheets are trivial to create. I've seen way too many weird, buggy and outright broken spreadsheets to believe that. I agree with you we should strive to make trivial things simple to write, and I also agree many programming tools fail at that, but I don't agree the software we write (in general) qualifies as trivial. Even some spreadsheets don't qualify. People writing them often make a horrible mess of it, unless they truly are simple spreadsheets.
  - Edmond 13y ago
    haha, I am sure there are many buggy spreadsheets out there... I didn't mean to suggest that it doesn't require knowledge and effort to put together a sophisticated spreadsheet but relative to building even the simplest web application, spreadsheets are a breeze.
  - arthurjj 13y ago
    As bad as the spread sheets can get it's helpful to have the business side make them. Even if you do have to implement a 'real' solution at least you now have a prototype to go off of

dj-wonk 13y ago

I like seeing this probabilistically! That said, I think the operative decision is "should I cut the corner?". If so, you should also factor in the p( ___ | not cut corner ) probabilities. So, you should cut the corner if the benefits exceed the costs. Written out: p(~P|C) * b(~P) - p(P|C) * c(P) > p(~P|~C) * b(~P) - p(P|~C) * c(P) Symbols: p = probability; b = benefits ($); c = costs ($); P = problems; ~P = no problems; C = cutting corner; ~C = not cutting corner. Rearranging to: p(~P|C) * b(~P) - p(~P|~C) * b(~P) > p(P|C) * c(P) - p(P|~C) * c(P) Then you get a simpler form: b(~P) * (p(~P|C) - p(~P|~C)) > c(P) * (p(P|C) - p(P|~C)) An amazing fortune awaits any person who can simply evaluate this inequality in real-world situations. It is also useful to know when the cost of gathering the information to evaluate the expression is not worth the potential benefit!

RyanZAG 13y ago
Definitely, thanks for adding in those terms. I kept it simpl(er) and left out the extra terms because I think that those two terms (benefit from cutting the corner vs loss of not cutting the corner) are the major factors when making the decision as they can have big effects on the business itself, while the other terms are just shifting around a bit of extra money/time. Maybe. It would depend on the corner. Everyone just thumb sucks it in the end anyway - I'll just embed this domain name in the distributed binary, nobody will ever steal our domain name! Technically someone at this point should pull up the statistics for stolen domain names to get an estimate for the probability, and work out how much it would cost to set up a system to pull a correct domain name from a backup, and then work out the cost to redistribute all the binaries to end users whose software won't be working for some time. I doubt anybody has ever done that particular calculation.