3 ms·

This is such a welcome change. There's nothing wrong with "hacking" and being a "hacker", but it truly does connote the idea of fiddling with something until it

This is such a welcome change. There's nothing wrong with "hacking" and being a "hacker", but it truly does connote the idea of fiddling with something until it works and then saying "tadaa!" As a developer (and sometimes developer lead), I strongly prefer a process wherein "hacking" is only the first step. As the old adage goes: 1. Make it work 2. Make it right 3. Make it fast "Hacking" is only step 1. We've all seen the results of a codebase where there is no step 2 or 3.

wyager 13y ago
I don't know if I agree with that adage. I think "Make it right" should come first. It's very easy to assemble perfectly constructed, but not fully functional, pieces of software into a coherent piece. It's comparatively very difficult to "fix" something that already works, both psychologically and practically.
- lowboy 13y ago
  I think as long as you go with modular design choices, you have the best of both worlds. You apply those three steps to each component in turn, and on the system as a whole.
- breckinloggins 13y ago
  I don't think the whole project should work like that, I think the developers should work like that. Example: I want to make a node.js push server. I've never made a push server, let alone a node.js one. The first thing I'm going to do is make an "echo server" just to verify I understand what I'm doing. If I'm doing this for Unity or Flash, I'll quickly learn I need a separate "policy server" to even make this work, so I'll hack it together until it works. I'll then iterate on this until I have a client sitting there and at random times it receives "push events" and reacts to them by printing something to the console or lighting up something on the GUI. This is Step 1: I've hacked it, I made it work. The point is that I wouldn't dare push my changes to everyone else yet. I'm going to iterate a few times, add a couple more of the features I know I'll need. I'll quickly discover the abstractions I need for this to have something of an architecture. At this point all the little nitpicky things and API calls I needed to do just to "make it work" get put in their proper places. Build scripts are made or modified. Tests are written. This is Step 2: I've made it right. I haven't overengineered it, but I've expressed my solution in terms of the abstractions that make the most sense. I can bring in my experience outside of this specific problem to determine how far is too far. YAGNI and all that. Next, I might throw a wild amount of connections at it. I might have it generate as many push notifications per second as it possibly can. I'll find some crashes, some resource leaks, and some REALLY naive, slow code that an hour ago I thought was OK. But that's alright, it's almost never the abstractions that are slow, it's an algorithm that needs to be improved or replaced, or an API I didn't quite understand. That's Step 3: make it fast. When all is said and done, I probably have 10 - 20 commits in my local repository. The first ones were absolute brutish hacks. The middle ones were factorings and abstraction exploration. The latter ones are performance tweaks and polishing. This never gets pushed to anyone else, it's my private experience and workflow. These commits all get rebased on top of everyone else's finished work and squashed into one commit. I will still HAVE my local history, but nobody else needs to know or care that version 0 of my push server was held together with duct tape and bailing wire. When a whole team works like this (and if you're lucky enough to find a team that can), really good things happen. "Hacking" is still involved, it just turns into "engineering" by the time the code has to move out of my basement and start paying its own bills.
- rytis 13y ago
  I think if you start from "making it right" there is a bigger chance of not getting anywhere at all due to the tendency of over engineering the solution. Can't speak for everyone, but I've seen this hapen quite few times.

wyager 13y ago

I don't know if I agree with that adage. I think "Make it right" should come first. It's very easy to assemble perfectly constructed, but not fully functional, pieces of software into a coherent piece. It's comparatively very difficult to "fix" something that already works, both psychologically and practically.

lowboy 13y ago
I think as long as you go with modular design choices, you have the best of both worlds. You apply those three steps to each component in turn, and on the system as a whole.
breckinloggins 13y ago
I don't think the whole project should work like that, I think the developers should work like that. Example: I want to make a node.js push server. I've never made a push server, let alone a node.js one. The first thing I'm going to do is make an "echo server" just to verify I understand what I'm doing. If I'm doing this for Unity or Flash, I'll quickly learn I need a separate "policy server" to even make this work, so I'll hack it together until it works. I'll then iterate on this until I have a client sitting there and at random times it receives "push events" and reacts to them by printing something to the console or lighting up something on the GUI. This is Step 1: I've hacked it, I made it work. The point is that I wouldn't dare push my changes to everyone else yet. I'm going to iterate a few times, add a couple more of the features I know I'll need. I'll quickly discover the abstractions I need for this to have something of an architecture. At this point all the little nitpicky things and API calls I needed to do just to "make it work" get put in their proper places. Build scripts are made or modified. Tests are written. This is Step 2: I've made it right. I haven't overengineered it, but I've expressed my solution in terms of the abstractions that make the most sense. I can bring in my experience outside of this specific problem to determine how far is too far. YAGNI and all that. Next, I might throw a wild amount of connections at it. I might have it generate as many push notifications per second as it possibly can. I'll find some crashes, some resource leaks, and some REALLY naive, slow code that an hour ago I thought was OK. But that's alright, it's almost never the abstractions that are slow, it's an algorithm that needs to be improved or replaced, or an API I didn't quite understand. That's Step 3: make it fast. When all is said and done, I probably have 10 - 20 commits in my local repository. The first ones were absolute brutish hacks. The middle ones were factorings and abstraction exploration. The latter ones are performance tweaks and polishing. This never gets pushed to anyone else, it's my private experience and workflow. These commits all get rebased on top of everyone else's finished work and squashed into one commit. I will still HAVE my local history, but nobody else needs to know or care that version 0 of my push server was held together with duct tape and bailing wire. When a whole team works like this (and if you're lucky enough to find a team that can), really good things happen. "Hacking" is still involved, it just turns into "engineering" by the time the code has to move out of my basement and start paying its own bills.
rytis 13y ago
I think if you start from "making it right" there is a bigger chance of not getting anywhere at all due to the tendency of over engineering the solution. Can't speak for everyone, but I've seen this hapen quite few times.