3 ms·
From the comments, a lot of people are taking the wrong message from this article. It's not "get stuck in and don't think about it", it's actually: "think abou
by scott_w 14y ago
From the comments, a lot of people are taking the wrong message from this article.
It's not "get stuck in and don't think about it", it's actually: "think about what needs to be done, then start with the hardest".
It's actually something I learned during a group project during university. The process is something like:
* Group all your main features
* Plot them on a graph of importance (y-axis) vs difficulty (x-axis)
* The features in the top-right (high importance/high difficulty) are the first things you do
* The features in the bottom-right (low importance/high difficulty) are the last things you do
This is something you have to keep evaluating over time, using a process/method of your preference (that works, of course).
The reason you do the hard/important things first is because it lets you know whether the project can go ahead for the minimal cost.
To take the group project I did as an example: we had to do a mapping application on a mobile device. Most groups went and wrote some code in Java, and wrote a routing algorithm. A few of us realised that getting something running on a device was the "hard" part, so set about getting that working. Afterwards, we went and drew some graphics, and handled some simple I/O with pre-programmed behaviour. When it came to writing the routing, we again tried everything against the device ASAP, so we knew what its real-world performance was.
Those who started writing Java without the device realised they had to convert it to J2ME before they could make it run, wasting a bunch of time. A good percentage had nearly nothing running by the end of the year demo because of this.
- hexagonc 14y agoNo, this is not the message from the article. Perhaps, it is what the message should be, or what the author wanted it to be, but it is not what was said. Just reread the first sentences. I quote: You have a nice big project you’re about to get started on. Delivery is in a few months, so you have time to plan, sketch out some initial ideas, to let it germinate in your head. Right? No. Start now. He is saying that you don't plan. You don't have time to let it "germinate in your head". Don't look for the hard parts of the problem and tackle them first because, if the problem is nontrivial, you probably don't know what the hard parts are, anyway. The hard parts are the ones you don't expect from the start. The author's thesis is that you should start early so that you can encounter the hard parts as soon as possible. It is about the fact that you will encounter unexpected challenges that will force you to reassess your strategy. I'm not taking a stand one way or another. I think your strategy has its place (and in fact, is closer to the way I tend to do things) as well as the author's.
- scott_w 14y agoI completely glossed over that part, thanks for pointing it out. I don't think he's completely wrong in his assertion. My feeling is that he is aiming that sentence at developers who have a tendency to over-think. I've seen developers (including myself) sit and think and research and think and research and not really do anything. In those situations, just putting your fingers on the keyboard and writing anything will be an improvement.
- tetha 14y agoThis is pretty much what I do, except that I start with the medium difficulty/high importance-problems to establish a base architecture and then test that architecture for durability with the high difficulty/high importance problems. After that, it's usually smooth sailing because the architecture should just carry the project.