Stop Being So Damn Clever by Matt
March 08, 2009 in Implementation with 3 Comments
At least for the hard software problems. Let's define easy and hard software problems.
- Posting a form to a server - easy
- Hacking http to implement a server push - hard
Solving the easy problems is trivial. Even if you have not solved them before someone else has, and they published a tutorial with pretty diagrams. It's paint by numbers, and the biggest number you're going to have to deal with is 9. Hard problems are daunting. It can feel like being asked to create the Sistine Chapel with nothing but a fist full of sharpies.
Luckily for us software problems conform to certain rules that art does not and we can offer the following advice on attacking these problems.
It's business time
When you decide to start in on a hard problem get right down to business. Do not start by checking your email, or tweeting 'Solving a hard problem', that would be lame. Tell your co-workers to shut their pie holes and turn off the Rammstein.
Remember what you have learned
Solving software problems does not typically involve inventing new solutions. You may think your solution is novel, but you're probably just as lame as your 4th grade reading partner who claimed to have invented Lego time travelers. I mean seriously, letting the Lego pirates play with the Lego astronauts takes no stretch of the imagination.
What you're really doing is applying techniques you have seen before in new and imaginative ways. To get there you have to use your existing knowledge to explore the problem before going directly for the best solution, which brings us to the most important point...
Don't be clever
At least not at first. Start with the simplest brute force solution that gets the job done. Cherish the moment when you see the problem solved, and then ride this confidence boost to apply what you have learned to a more elegant and robust iteration.
Someone explained it to me with the following anecdote.
Take the problem of creating an algorithm to solve a maze. The simplest solution is to follow the right wall until you reach the exit. It's not the shortest path but now you know there is an exit and you know how to get there. Now you can go back over your path and cut out the unnecessary segments and produce the shortest route.
If this is truly a hard problem then you don't know jack about how to effectively solve it. Going full bore on a three layered redundant fault tolerant cached architecture is going to be a waste of time when you realize that the do_what_you_expected() method does the opposite and you really needed to build the thing in assembly.
3 Comments
Jeremy (ZURB) says:
First of all, wouldn't you just call this being 'goal-oriented' or 'staying scrappy'? When the destination is what you're passionate about, you don't let yourself dick around with clever ways to make the journey.
Or put another way, people won't care about how neat your solution is if it doesn't really solve the problem. And that's the risk you run if you don't get the solution fast.
Secondly, if you're gonna cross that line between space and pirate LEGO, you're on a slippery slope. Why not toss your sister's Barbie in there while you're at it? There are rules. It's complicated.
Matt (ZURB) says:
I would call this a way to stay goal oriented and improve scrappiness.
And you better get a patent on this Lego Barbie thing. I have a feeling that Space Pirate Lego Barbie is going to be huge.
Anthony says:
I had a college professor summarize design patterns as "known solutions to known problems". He was right. He also explained the process of SDLC like this: Do it, Do it right, Do it faster; Sell it, Sell it right, Sell it faster.
Add your comment...