Hacker News new | comments | show | ask | jobs | submit login

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"


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