Hacker News Reader

Comment by dbg31415 | Hacker News Reader

Well, so I can see this article being twisted all over the place.

It's hard enough to get proper time for planning technical projects without this kind of crap.

Guess what, planning time does save time and lowers your cost of ownership. ROI-wise, planning time is the best gift you can give your project.

But... then someone is like, "Speed, I hear speed is good... move faster. Dependencies... fuck 'em... I don't understand 'em anyway so fuck 'em. Let's just go as fast as we can and we'll worry about everything we should have worried about up front over the next few years after all our devs quit because they're tired of working on shitty code that was rushed through."

This article so rubs me the wrong way. "Technical debt? What's that?!"

Anything worth doing, is worth doing right. To the best of your ability. Doing things right takes time. Take your time, do things right.

View on HN

The final lines gives some indication of what delusion the author is labouring under; Don’t let you or your organization use that as a false shield or excuse to lose momentum. The moment you do, you lose your competitive advantage.

This is someone who has either not only drunk the kool aid, but is already on their way back from the store with another carful of it, or someone with very limited experience of business. I have worked for many, many businesses whose competitive advantage is not being fast, but in this author's view, being fast is the only advantage there is. Competence, cost, quality, reliability? Just fairy tales.

However, part way through this breathless look-at-me, the author clearly describes the advantage of a simple price scheme (We offered one price of $50 per employee per year... We just wanted to be able to tell people, “We may not be free, but we’ll be the simplest decision you ever made.”). This actual advantage is then smothered under the breathless fact that it was decided quickly; he made a good decision quickly, and that it was done quickly is apparently more important than being right. What a mess of text, and a mess of self-contradiction. Clearly, someone has decided the correct answer, "speed", and is now trying to mash evidence to fit.

You read my mind. Points from this article need to be taken in context.. especially all the examples from Google. It's one thing to say 'Do it faster!' and have unlimited resources at your disposal (Google), but it's whole different ball game to harp on your 5 member startup. One adds hours via bodies and the other ruins work/life balance. That can really set a negative tone for an early startup trying to attract talent.

I enjoyed the 'GM is slow' comment. While that may be true in terms of innovation, it is the opposite when it comes to manufacturing. I've worked in those plants where the 'speed above all else' sentiment is eerily similar to this article, and is largely the reason I chose a different career path.

The one thing I take away from this is the accountability perspective. It's ok to ask why things will take the amount of time projected. Things often do get tacked on that don't need to be.

I was going to write up a bit of a rip on this as well:

> All else being equal, the fastest company in any market will win.

So, that's why we all still use AOL? And why Microsoft never had to worry since it built Office? Why PayPal squashed Venmo? The point is really that all else are never equal. Speed to market is A factor, but it's not the only factor, or even the most important factor today. Look at Box, vs. Dropbox, vs. Copy, vs... The market is big enough for multiple identical services. Users pick the one that works the best for them.

And I certainly agree asking questions is a GREAT way to start documenting all the stuff that has to go into a project. I'd add a bullet point, "Way more hours than I want for... explaining why setting up Vagrant is important... explaining why unit tests save time, for the 900th time... explaining why QA is needed..."

Things don't often get tracked that ought to be, but PLEASE do not send more meeting requests to your entire dev team asking them to justify to marketing or sales why we need the basic steps we ask for.

(This article hits a bit close to home today, as I'm literally in a meeting with 15 people where only 2 people are talking and I literally just had to defend QA marketing guy who clearly doesn't get it. And the topic... "How we can organize our team to be more efficient.")

Speed clearly isn't everything but I think you picked terrible examples.

AOL might have been first but then they just seem to have quit. They didn't keep up with the times. Their whole paradigm was terrible out of date. They were in the ISP market but extremely slow and it killed them.

Lotus 1-2-3 was before Excel but Lotus took a long time to release new versions while Office did not. You'll notice that MS isn't super quick with releases now, but they do churn out new versions with some regularity.

Business doesn't have a finish line so companies have to start and stay fast. This is why technical debt is a problem; sometimes you need technical debt to get something out the door fast, but it will slow down future releases so you need to get it under control.

In today's market, I don't see any customer being like, "Man, I wish this came faster." Look at Blizzard... they focused on speed for their last expansion, and they lost 3M subscribers. Look at all the automotive recalls this last year. And really AOL... wasn't even first to market, Compuserve beat them but like 10+ years.

There are many ways to get ahead. Bureaucracy sucks.

But just saying, "Speed man, speed... that's the good stuff..." It's only true when it's paired with customer demand, high quality, and all the other things users demand.

ICQ vs. AIM? I can't actually think of a single example of a product being first to market and that making them better than the challengers. Getting to market... no question, that's great. Blowing away what exists in the market... that's what gets you customers. So inherently being first isn't advantageous since you're opening the door to others taking your idea and improving on it.

I'll say again, build the best thing you know how to build... if you don't build it great, people will notice. Nobody wants a quick and dirty solution once they see the well-designed, delightful, secure, improved, etc. solution.

Facebook > MySpace

Instagram > Facebook

Reddit > Digg

Any modern software language... nobody is like, "Man, give me some ASP VB, that came out before Rails or Node... it must be better." We evolve. Speed, it may be a factor. But what you build has to survive past launch. Do your best to give it the legs it needs... and maintain it as vigorously as you can. ROI is in planning.

I don't know. Anecdotal, but I've seen more projects die due to not executing fast enough than due to being overwhelmed with technical debt. There needs to be a balance. If you've gotten to the point where you're refactoring technical debt, then you've probably at least shipped version 1 and have customers to pay for that refactoring.

Yes, this article can be twisted, but the point here another way of saying the most decisions are stuck on minutante and bureaucratic process (mostly with saving my ass moves). The decision makers should be clear about the time-boxing both planning and execution. "realistic and yet, hard deadline" is the key here, there is a balance, but I think the emphasis of getting things right sometimes drags the process than it needs be, because most of the time is probably spent in cognitive overhead or ass-saving office politics.

I guess I see 'Speed as a Habit' and take the article as culture setting and a negative. It seems like you see the article as a way to avoid poor decision making and planning habits and a positive. The truth probably lies somewhere in between.

People can misread or misinterpret almost anything. However, the article had some real points.

tl;dr version: There is an opportunity cost for the time you spend in decisions. If the decision is really the most valuable use of that time, take the time to make the decision. If not, make the best decision you can in the next 10 minutes, and move on.

"Technical debt? What's that?!"

A startup is a system for turning technical debt into financial equity. So long as the founders and VCs make their exit event, it doesn't matter what happens after that.

Reply on news.ycombinator.com