~ryanlowe/blog: Engineering or Art?

Engineering or Art?

To hack or not to hack, that is the question. Hacking is becoming a lost art some would say. Software projects are too large for one person to keep in a single brain. Process becomes necessary. This doesn't sound like a lot of fun.

But here's the deal -- it's all about who you are writing your software for. If you're writing it for you by all means hack away. But if you are a real software engineer you should be able to put your stamp on it. You should be able to say "I did the best I could to ensure good quality here" and that doesn't include hacking up something.

Of course it all depends on the quality threshold you are aiming for but companies don't bring in software engineers to hack little pieces of code together. They expect large projects and for them to be done with a relatively high level of quality, which admittedly in software isn't saying much.

Hacking is definitely an art -- if you've ever seen someone pour out code from their head rapid-fire you know what I mean -- it's pretty amazing. But I'm beginning to think its day has past. In a way it's sad but it looks as though, probably for the better, new software will be engineered stronger than art.

Posted at October 08, 2003 at 05:45 AM EST
Last updated October 08, 2003 at 05:45 AM EST

Comments

I disagree and agree with your comment. Hacking is still alive and well, it's just most software engineers preffer getting paid, so company procedure it is!

However, like you said, any self respecting soft. Eng/Comp Eng./Comp Sci./Programmer...whatever you wanna call yourself, should not be putting in "hacks" into large scale projects because there are so many dependencies, and clarity is of the utmost importance. I comment/document/review all my code so that my ass is covered, and for clarity to others and myself.

On the otherhand, even in a large development group, there are plent of awesome utils that are definitely hacks. Think of them as the "Macros of the application world". We all need some "tools" in our toolbox, and sure enough, there's always someone that makes a clever little app that was quickly coded/hacked up, yet saves many developers time in their day to day development.

I've seen this in the Private and Public sector. Inhouse clever little handy apps. No documentation neccessary. Just use!

» Posted by: roy at October 8, 2003 12:06 PM

It also depends on what your role is I think. Developers work under different rules than maintainers. For people that are just doing minor changes on systems, depending on their workload, how many tickets that you clear can be the "goal". If downtime is the enemy, sometimes getting a solution that *just works* to fix that problem is all they worry about.

This probably only works on web stuff where you have the code / app on your machines, vs. where the app is on other people's computers and getting the solution / fixes to everyone is costly / embarrassing.

» Posted by: Jim at October 8, 2003 12:19 PM

Yes it depends on the size of the project and quality you need. Sometimes a hacked bit of code works just fine. Software engineers don't have to write those kinds of programs though, anyone can hack/fix/hack/fix ...

» Posted by: Ryan at October 8, 2003 03:09 PM