Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Start-Up Trap

blog.8thlight.com

Post reply on HN
Print view View original

141–145 of 145 posts

Re: The Start-Up Trap

#141

Post by gearoidoc »

freshhawk wrote: post #137
gearoidoc wrote: post #104

Earlier quoted context omitted.

But what if the debt outweighs the benefits? What if you can't measure the debt?

If the debt outweighs the benefits you don't take it, I have a project right now that I "know" will be fragile and a maintenance headache later. So even though it's urgent I'm writing the appropriate tests and doing all those best practice things that you know will pay off 10x later but often skip because you don't want to take the time now. You could measure how much debt your team tends to take on, by measuring how…

A good response :)

I think we just lie on different sides of the fence on whether to apply best practice early and suffer the initial time cost upfront versus getting a rough around the edges product in place and refactoring later.

Do you have links to articles about companies whose business failed due to lack of technical agility? I was thinking about this recently and don't believe I've ever read about such a case, but its highly likely I'm looking in the wrong places :)

Re: The Start-Up Trap

#142

Post by JoeAltmaier »

unclebobmartin wrote: post #116
JoeAltmaier wrote: post #110

Earlier quoted context omitted.

And you come in 2nd or 3rd in the race, and lose.

That is certainly your fear. It is a fear I don't share. Firstly, I think you'll get there faster if you work well. Secondly, as MySpace showed, being first isn't really all it's cracked up to be.

Im not making myself clear. You might beat me, personally, once. But you won't beat that one lucky guy that didn't do the testing, got his code to work the 1st time, and got to market before either one of us. That's how the game's played. Conservative, careful, correct coders don't win that game.

And if your business plan is to be 2nd to market, well, good luck with that.

Re: The Start-Up Trap

#143

Post by freshhawk »

gearoidoc wrote: post #141
freshhawk wrote: post #137

Earlier quoted context omitted.

If the debt outweighs the benefits you don't take it, I have a project right now that I "know" will be fragile and a maintenance headache later. So even though it's urgent I'm writing the appropriate tests and doing all those best practice things that you know will pay off 10x later but often skip because you don't want to take the time now. You could measure how much debt your team tends to take on, by measuring how…

A good response :) I think we just lie on different sides of the fence on whether to apply best practice early and suffer the initial time cost upfront versus getting a rough around the edges product in place and refactoring later. Do you have links to articles about companies whose business failed due to lack of technical agility? I was thinking about this recently and don't believe I've ever read about such a case,…

I look at it as a spectrum rather than a binary choice. I find, for myself, that in the last few years I've gotten screwed too often by spending weeks (amortized over a few months to a year) fixing bugs and patching up hacks that I could have avoided with a few hours of upfront cost.

So I try to move my default a little more to the best practice side. I also don't see this epidemic of overdesign in our community, although it exists. I see people hit a design debt wall and have greatly reduced velocity more often. Sometimes laziness reinforces a desire to move quickly and the wrong tradeoffs are chosen. Sometimes the upfront cost is higher because you have to train people in those best practices, or at least teach them the new tools.

I also have noticed that different fields of programming have different sweet spots so it's not surprising that people don't agree on the one true way either.

Re: The Start-Up Trap

#144

Post by thenonsequitur »

barrkel wrote: post #65
dasil003 wrote: post #59

Earlier quoted context omitted.

First of all I agree with the idea that automated testing is not a guarantor of quality. Rather automated testing is one tool, along with exception notification, logging, and a fail-fast philosophy that each shines a light from a different angle to help overall quality. And if you need the strongest possible guarantees against failure then you have to go with a more fundamentally strict language such as Haskell. But…

I just see it as good code hygiene. I think it is necessary hygiene for Ruby. In dynamic language web apps, everything is so loosely coupled together by a mixture of conventions and magic strings (or symbols, if that makes you feel any better about them) that it's very easy for one of the strings to break without noticing. But IMO you are mostly (perhaps 80%) working around an inadequacy in the tools. It is not a vir…

You are conflating Ruby with RoR. You start by saying "I think it is necessary hygiene for Ruby." but then go on to say "RoR is very error-prone and a lot of work by comparison" and "So many bits and pieces need to be glued together, from attr_accessible through to update params slicing..." -- that's Rails you're talking about. And I don't blame you for that. As a long-time Ruby developer, I can say with no qualms that Rails is a not a very good web framework, way too buggy and full of magic. But please don't conflate that with Ruby. Ruby with Sinatra is a hell of a lot cleaner and it's much easier to structure your code well.

Re: The Start-Up Trap

#145

Post by thenonsequitur »

unclebobmartin wrote: post #138
tmoertel wrote: post #130

Earlier quoted context omitted.

The benefits that you attribute to TDD are not exclusive to TDD. They are the benefits of having well-tested code, and TDD is only one of the ways to get there. The problem with the TDD way of getting there, however, is that it's expensive: It makes programmers see their code through the pinhole of one failing test at a time, blinding them to larger concerns, which are important. As a result, a lot of avoidably crapp…

The idea that TDD involves some kind of blind faith that the tests will generate grand designs and beautiful code is both silly and wrong. You are right about that. Good design and good code require skill, thought, and knowledge irrespective of whether you are using TDD. So as I practice the discipline, I am thinking all the time about larger scale issues, and I am _not_ being blinded to those concerns. However, the…

"However, the act of writing tests first has a powerful benefit: the code you write _must_ be testable. It is hard to understate this benefit. If forces a level of decoupling that most programmers, even very experience programmers, would not otherwise engage in".

I'm sorry but I really find that sentiment to be totally inaccurate. I've never seen a good experienced programmer write hard-to-test or coupled code, regardless of whether they are using TDD or not. A hallmark of when makes them good is that they all have some testing methodology that enforces this and works for them. TDD is one, but there are many others (and yes, that includes good manual-only testing).

I also don't see why you believe TDD is the only way to successfully refactor code, or that only developers who use TDD continually refactor their code to eliminate technical debt and increase productivity. Again, every good programmer does this. TDD is one way to get there. It is not the only way.

Post reply on HN