Hacker Newsnew | comments | show | ask | jobs | submit login

In startup world, the difference is:

Hacker: beta is out the door in a month, features get tacked on every 2 days in the middle of the night, million users in a year, $100M exit in 18 months, anyone who sees the code would cry.

Engineer: can't release the beta because no proper QA cycle, no features can be released until the beta code base has been refactored with proper unit tests, less than 2000 private beta users after a year, $10M series B round after 18 months to keep the company afloat, everyone cries when they see their hacker competitors' new automobiles




Mixing metaphors from the post a little bit, but yes, in the startup world, if you take time to engineer before you have a proven product, you'll get squashed. On the other hand, with a proven and successful product, if it's poorly engineered, it will be too expensive to scale or modify. Different situations, different priorities.

-----


What this says to me is that:

    hacking: 0 < version <= 1.0
    engineering: version > 1.0
In other words, as soon as the product is "established" as a pile of hacks, all hackers should be taken off the project (temporarily) and a complete white-room rewrite should be done by a team of engineers, with one of the criteria being "to closely match the original product as possible while creating room for future expansion."

Then, the hackers (now known as "R&D") can have at the new codebase, but in a distributed SCM way--a hacker can only work on their branch, and any approved branch must be white-room redeveloped by an engineer before being put into the clean code-base.

...or, "What I Would Do If I Ran Some Sort of Military Project With Unlimited Funding and No Time Constraints"

-----


"a complete white-room rewrite should be done by a team of engineers"

NO! NO! NO!

Never allow your engineers or anyone else to do a full rewrite of anything that currently works and serves the needs of your users. While they're busy rewriting (and it will take SOME TIME) you're not pushing out new features and your competitors are (remember Lotus 1-2-3?). And if you are pushing new features while your engineers are doing a rewrite they will NEVER catch up.

The solution: Make sure your application has tests from the start (and don't allow any excuses for not writing tests) and you can slowly refactor and rewrite small parts of your app, one bit at a time.

There are some exceptions to this, some companies have managed to successfully rewrite their software from scratch. But consider that a statistical anomaly and don't try to replicate it (and chances are it was rewritten by a team of super hackers, not a bunch of engineers trying to find the most perfect, scalable solution).

-----


This reminds me of the saying that Java is a great language if you already know what you're trying to build.

-----


<quote> hacking: 0 < version <= 1.0 engineering: version > 1.0 </quote> nicely put! in the early stages it helps to "hack" at the early versions,people with inter-disciplinary skillsets.

i also think,guess its easier "to manage" engineers. that said - i think its easier for a hacker to manage /steer a bunch of engineers, than for an engineer to lead a bunch of hackers.

at the end of the day, i think a hacker something creates out of nothing. an engineer thereafter tries to keep it afloat without screwing around.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: