Wherein I discuss how to do things that you should be doing and how not to do things that you shouldn’t be doing…. Sometimes you tweet something and it makes sense to you, but then you realize that it also kind of begs for more discussion. For instance: “Things move so quickly that doing the *one* most important thing means it’s less likely that you’ll do the wrong things in the long run.” I thought that a little more explanation would be in order. Let’s say you have ten cool features on your “Things Customers are Screaming For” list. There are two basic approaches you can take to getting them done: You can do them in series or in parallel. If you do them in parallel, you’ll get them all done sooner, but you may not get them done as thoroughly. If you do them in series, it will take you longer to do them all, but you’ll likely get each one done more thoroughly. However, doing them in series – that is, sequentially doing only the most important remaining item – has an added benefit: It can help you not do things that you shouldn’t do. You may have ten things on your “We need to get these done right away”, but as time passes, some of those things may prove to be not needed, overtaken by events, or just plain dumb ideas. Doing things in parallel may mean that you get everything done sooner, but it also means that you might do something that proves to be a waste of time later on. For example, if you have a team of five folks, and you have five ideas that take six man months each, you might give each person one idea to work on, and then six months later, you have all five ideas done. Great! But uh oh! — as it turns out, over the course of those six months, things changed and events transpired in such a way that two of the ideas weren’t really good ideas after all, and at the end of the six months you regret ever starting on them. So in the end, you have three things done that needed doing, but have wasted your time on two ideas that you should have left undone. Furthermore, since you only had one person working on each idea, you may not get a fully fleshed out solution, but instead, one that may have missing features or is not complete in some way. But consider what happens if you work on them in series: say that instead of starting in all at once on the entire list, you pick the single most important of the ideas on the list. You focus your whole team on doing that one idea. You will likely be able to get it done somewhat sooner, say in one or two months instead of the six months in our example. (Five team members working on a six man-month project will likely take a bit longer because of transaction costs.) In addition, you will get a “five-headed” solution instead of a “one-headed” one, and thus the solution would likely be more complete, fleshed out, and feature rich. In other words, you might very well end up doing one thing properly and thoroughly instead of doing five things not so completely. The added benefit comes when, after doing the most important project, you realize that one of the ideas you had originally thought was awesome isn’t really that awesome, and that you can take it off the list and not waste time on it. You might add another item to the list, or another item that was on the list suddenly becomes vastly more important than it was at the start of the first project. Instead, you can repeat the process and start working on the next most important thing. You end up with a very nice implementation of each project you do undertake, and you don’t do the projects that shouldn’t be done. In a rapidly changing technical environment, that which looks like a no brainer in January might be old news by July. Obviously you want to avoid working on that project. A practical example might be that you are a software tools vendor, and people are pressing you to do, say, a development tool for Windows Mobile 6. You could choose to add staff and get that request done sooner, or you could stay the course and do more important things, only to discover with massive relief that you didn’t do Windows Mobile 6 at all when Windows Mobile 6 becomes a legacy technology. (Sound familiar? ) Now, I’ll grant that if you follow this plan, you’ll end up with fewer features in the long run. But you’ll also end up with more complete features with less wasted effort. You won’t have spent time on things you ultimately should not have. It might take a little longer to get any particular feature to market, but in the above example, you’ll end up with three really solid features and no time spent working on things that you should not have worked on at all instead of five half-baked features, two of which were a waste of time. Repeat this process enough, and it becomes much more likely that you will end up with a product that has the right – and fully rendered — feature set. In many ways, inefficiencies are the result of choosing to do the wrong thing. If you keep your choices finely grained – that is, always put your efforts only into the things that are obviously the very most important thing to do do right now – you will end up doing the right thing every time, even if there is slightly less of it. It’s often been said that knowing what you should do is easy; it’s knowing what you shouldn’t do that’s hard. If you repeatedly focus on and complete the one single thing you absolutely should do and do it well, it will be more readily clear what those things are you should not do. So, I guess ultimately, you have to choose: More features done less thoroughly with time spent on things that turn out to be a waste, or fewer, more complete features with fewer projects that you shouldn’t have done.
Embarcadero: Firemonkey OOP
Embarcadero: Firemonkey C++