3 ms·

Summary: There is a design pay-off line - having little software design may get you to market faster but then hampers you downstream; having too much design slo

by frossie 17y ago

Summary: There is a design pay-off line - having little software design may get you to market faster but then hampers you downstream; having too much design slows you down for no additional payoff. I call this the "less talk more code" point. Of course the trick is figuring out where that point is without the benefit of hindsight. In my experience it really helps to know what the shelf-life of the product is, and the length of the future development cycles, which is not always clear in advance. I have called "less talk more code" on a project thinking we would only need the software for 3-5 years before having more time to refactor; if I had known we would have been still using it 10 years later in its original state, my determination of where the payoff line might have been different.

locopati 17y ago
That seems like a common problem. You gather requirements which suggest that the software will be used once or for a limited time, so you cut corners in order to get it done quickly and then years later the software is still being used and everyone is complaining about the cut corners without understanding the circumstances by which they came to exist.
- frossie 17y ago
  I agree with you, though I am not necessarily talking about "cutting corners", which to me implies slopiness. It's just that you can optimise for a certain environment of use, but if you don't realise that the software will be used 10 years from now, you don't worry about how the usage environment will change. This isn't sloppiness, it's optimisation - as the old saying goes, the perfect race car is the one that falls apart 10 yards past the finishing line; if it lasts for longer it was overengineered. It's just that in software we don't know where the finish line is - or even if there is one.
- hypermatt 17y ago
  One of the dangers is most projects do get killed, and even if it doesn't you put more risk by not releasing it. Once its released and people are getting value from it the project is a lot safer position to put more effort into design.

by frossie 17y ago

locopati 17y ago

That seems like a common problem. You gather requirements which suggest that the software will be used once or for a limited time, so you cut corners in order to get it done quickly and then years later the software is still being used and everyone is complaining about the cut corners without understanding the circumstances by which they came to exist.

frossie 17y ago
I agree with you, though I am not necessarily talking about "cutting corners", which to me implies slopiness. It's just that you can optimise for a certain environment of use, but if you don't realise that the software will be used 10 years from now, you don't worry about how the usage environment will change. This isn't sloppiness, it's optimisation - as the old saying goes, the perfect race car is the one that falls apart 10 yards past the finishing line; if it lasts for longer it was overengineered. It's just that in software we don't know where the finish line is - or even if there is one.
hypermatt 17y ago
One of the dangers is most projects do get killed, and even if it doesn't you put more risk by not releasing it. Once its released and people are getting value from it the project is a lot safer position to put more effort into design.