Comments on: How Experienced Developers Can Handicap a Lean Startup

By: Cogblog » Blog Archive » Is Minimum Viable Product Your Excuse For Shoddy Work?

Thu, 28 Jan 2010 16:31:53 +0000

[...] I see a blog post like this one. And my reaction is, “sounds like you are working with the wrong engineers”, not that [...]

By: Jason Huggins

Jason Huggins — Sat, 07 Nov 2009 20:12:43 +0000

I was with you until the “is Selenium really worth the hassle” part. Before Selenium existed, let me assure you, verifying javascript-heavy web apps in IE and Firefox was an even bigger hassle.

By: CHagner

CHagner — Sat, 07 Nov 2009 03:54:19 +0000

It comes down to figuring out what’s the biggest risk that you’re facing?

1. Not being able to solve the problem at all
(or put another way: not bringing a compelling enough solution to market)
or
2. Not implementing the solution TRW.

If you’re scared to death of #1, then #2 shouldn’t be driving how you spend your time and energy.

Put another way, if you suffer #1 because you spent too much time solving #2, then you missed Kevin’s point completely.

By: Tom Zinter

Tom Zinter — Sat, 07 Nov 2009 00:42:47 +0000

“Inexperienced developers have one big advantage: they haven’t been programmed to work for perfection and they’re not afriad to make mistakes.”

Yeah, because we all know this is by no means any sort of generalization or anything. Its unequivocally true. Experienced developers only want perfection and are deathly afraid of mistakes. Definitely don’t get one of them.

By: Christoffer Du Rietz

Christoffer Du Rietz — Sat, 07 Nov 2009 00:16:43 +0000

Great article. I’m not a developer but a designer and I can totally relate to this. I’d say that in most companies the exact same thing goes for designers. On the web today were time-to-market is the difference between success and failiure, experienced designers (including myself) tend to want to spend way to much time perfecting the product before getting it out the door. I hate to say it, but for most businesses online, design isn’t more important than time-to-market. So all you designers out there, get over yourselves!

I must say though, that there of course are exceptions. But mostly only in the premium market and when design is mean to be your main competetive advantage in a very crowded marketplace.

By: Rob

Rob — Fri, 06 Nov 2009 21:56:48 +0000

What’s missing here is the question that doing things TRW begs:

When you were taking the time to do things TRW, did you not have to (or wish you could) throw everything away as soon as you released version 1?

Many assume that heavily front-loaded architecture/plumbing/etc. design processes (e.g. “you start an agile project with 3-4 architecture sprints, right?”) consistently yields better results and by results I mean “increases the chances you won’t have or want to just throw it all away for v2.”

When in your experience have you ever really gotten it right during this period? You’ve spend loads of time up front except you’re spending time solving problems you haven’t run into yet, which you may never run in to.

By the time you hit v2, you’ll wish your product was scaling in ways you couldn’t have anticipated, being deployed into environments you never considered, etc.

If our experience tells us that’s the case, why do we continue to front-load engineering initiatives with activities that mostly do not pay off?

By: TKL

TKL — Fri, 06 Nov 2009 21:06:44 +0000

I agree. Having worked in both a 2 man shop and a 9,000 person development organization there comes a point when you need to match your development approach with your purpose.
If you are trying to build an critical enterprise app then by all means use a full SDLC. But I’ve seen many cases when the app concept is not yet proven or that it is even disposible… ie: will be used one time and then never again. In those cases you need to just make it happen.
There are cases when a better/smarter method is not more time consuming and provides more flexibility down the road. In this case experience is key.
Advanced error detection for example is something that I often come back to. No need to spend hours coding around ever conceivable way a user could skrew it up if it doesn’t do what the user wants in the first place….. Get it working first… then refine as you go.

Again this is for non-critical apps…

just my 2 cents

TKL

By: kevindewalt

kevindewalt — Fri, 06 Nov 2009 19:49:36 +0000

Looks like I touched a few nerves today. http://kevindewalt.com/blog/2009/11/06/h... and on Hacker News: http://news.ycombinator.com/item?id=9259... Interesting debates

By: Augustine Koshy

Augustine Koshy — Fri, 06 Nov 2009 18:47:15 +0000

I am not sure Rudolf O. really understood the message here. The author is not promoting anything dangerous or poisonous here. He is talking about how experienced enterprise developers can go in the wrong way to cause a startup burst. Quality itself is an attitude and perception. However Rudolf O lacks on both. Rudolf O’s tunneled thoughts are the real dangerous and poisonous one. May god help your brain to think straight and right

By: Gabe da Silveira

Gabe da Silveira — Fri, 06 Nov 2009 18:31:06 +0000

There is definitely some truth here, but on balance I tend to agree with some of the other commenters–this article is likely to encourage young developers to dismiss their older counterparts as over-careful and out-of-touch.

It doesn’t matter whether you’re working in the enterprise or for a seed-stage startup, there is both throw-away code, and long-term production code. In both cases, code written today is going to be more painful to modify tomorrow, often by several orders of magnitude.

I agree that in a startup you need to cut corners in order to even figure out what you should be building, but you still need to know which corners to cut, because 3 months from now those corners you cut are going to be divided between the things you threw away (good) and the things that are calcifying into the backbone of your application (bad).

As always, the real (and largely unmeasurable!) talent is the clairvoyance to determine which is which far in advance. Experienced developers have an edge here. And obviously this is much much harder in a startup here the product is still in massive flux.

The “experienced” developer who rigidly does things a certain way based on past experience is a red herring. This person is simply not cut out for a startup either way. If they were a younger version of themselves sure they might move faster, but how soon before their ignorant mistakes bring them past the point of diminishing returns? What happens once the agility of the lean startup is squandered on unmaintainable legacy code?

By: David

David — Fri, 06 Nov 2009 17:48:40 +0000

How odd that you equate “experience” with “enterprise experience”.

There are plenty of experienced engineers who have spent their lives hacking and/or working in startups.

By: Brian

Brian — Fri, 06 Nov 2009 17:40:15 +0000

Great post. This is a tricky problem. It can be incredibly frustrating for a developer who is coming from a more structured coding environment to move to a start-up environment. The answer is certainly not to throw out all those good coding practices and go completely cowboy (no tests, no plan, etc…). The key is knowing what are the critical paths in the software, the core features, and testing those at the right level (unit, integration, story, etc…) so that the moving target of what-the-product-will-be doesn’t invalidate all your work. As the product matures and the company figures out what features sell then more tests need to be added and the code re-factored. Rinse and repeat. Oh, and the code should do as little as possible to get the job done. Coders (myself included) often have the habit of trying to predict features, these predictions are often wrong and add needless complexity.

By: Ben

Ben — Fri, 06 Nov 2009 16:08:04 +0000

Great Article, I keep running into this dichotomy.

IMO, this is what differentiates Good developers from Rockstars. A Rockstar knows how to ride the line between the “right” way and the fast way.

By: Rudolf O.

Rudolf O. — Fri, 06 Nov 2009 16:06:48 +0000

This article is dangerous and poisonous to the computing industry.

A working prototype usually becomes THE PRODUCT! it mutates into the final buggy product that is shipped or if it doesn’t, why the fuck are you wasting time building a prototype at all?

If you have the time to build a prototype, and then the type to create a properly designed product, then you have the time to do things right in both cases. On the other hand, if you don’t have the time, well you’re going to fail as a computing scientist or a software engineer (whichever you see yourself) because you will be shipping a buggy product that was initially a prototype.

I understand that a business wants to cut costs, but when that comes at the expense of quality, then you’re doing society a disservice by shipping the product.

By: Ron Leisti

Ron Leisti — Fri, 06 Nov 2009 16:02:14 +0000

On foreign keys, I’ve actually seen the opposite effect as far as programming experience goes. For better or worse, what I’ve seen is a pro-foreign key attitude coming from freshly minted programmers (because they teach that stuff in school), followed by the gradual disenfranchising in older developers. I’m not saying that foreign keys are bad necessarily, but experience does tell programmers when they can be a pain in the arse.