|Pathologically Eclectic Rubbish Lister|
YANPP: Yet another non-Perl post by Ovid :)
I was once assigned the role of coordinator between project managers and technical staff on a highly sensitive internal project to improve our cost accounting processes. One of the difficulties that needed to be overcome was how to distribute payroll data across four states without this data being compromised. It was decided that we would use Lotus Notes to do the distribution and I was asked to find the programmers who could determine what information we would need to implement this solution.
In another instance, one of my coworkers sat down in a meeting for a non-critical project and was informed that the project needed to be finished two months from the date of the meeting that she was in. Part of her role was to ensure to determine the scope of the project and the resources available for it. The deadline was chosen to ensure that people working on said project would not have to deal with it during their Christmas holiday.
Both of those scenarios has a serious flaw in the reasoning. In both cases, the scope of the problems had not yet been determined, but specifics of the solution had. These are the sort of subtle issues that we tend to overlook, yet they come back to haunt us. Worse than haunting us, these decisions often make us look like fools.
On Perlmonks, we routinely hear posters saying things like "I've chosen this technology, but I am not sure how to implement it." When I hear someone say things like that, my gut reaction is to think "glad I'm not working with that person." Technology is part of the answer, not part of the question. Don't make choices only to then try to figure out how to twist the problem in such a way so as to fit your choice. This will often result in your solution being more convoluted than my previous sentence.
When you have a problem, any problem, the first thing you need to do is gather all of the information about it that you possibly can. What problem are you trying to solve and why are you trying to solve it? After you've clearly outlined the scope of the problem, figure out what resources you have available in terms of time, money, people and technologies. Further, figure out your opportunity costs. Opportunity cost is a fancy economic term that boils down to a simple concept: what do you give up by continuing on your current project? If you want to divert your resources to Project Foo, which is projected to increase revenues by 3%, but the identical resources need to be taken from Project Bar, which is projected to increase revenues by 7%, Project Foo is dead in the water.
Here's a slight more complicated example. Imagine that a software glitch is causing your company lost revenues of $5,000 per month. That's $60,000 a year. After analyzing the situation, you determine that the problem stems from a combination of limited hardware capacity and a bad database design. The project to redesign the database, rewrite the code base, and upgrade the hardware is expected to cost $250,000 and take a year. Maybe $60,000 isn't that bad of a loss. But wait! You still need to think further. Are your sales expected to increase, along with the projected losses? If the costs of fixing the problem are the same, maybe it is worth fixing.
Of course, there's also the matter of your company's reputation. Are customers also getting affected by these losses? Are their orders delayed and sometimes incorrect? It's tough to quantify how that can affect revenue. Further, do the people who would resolve the problem have other projects to do? If they're just sitting on their hands waiting for the next big contract, having them fix the glitch might at least allow you to minimize losses while you wait for more work for them (though if you're waiting a year for your next big contract, you have bigger problems :).
If you're just doing a small project at home, these concerns usually aren't that big of a deal. But if you're doing work that you're getting paid for, it's unethical for you to start making decisions about implementation without having clearly defined the scope of the problem. Choosing the database, choosing the programming language, choosing a due date are usually terrible things to do when you don't even know the question (of course, sometimes there are financial and legal constraints that interfere with "proper" decisions).
I'll finish this with a perfect example of someone "missing the point". I read this on a debate over whether or not MySQL is a reliable database (this was before MySQL started implementing transactions (with a tip o' the keyboard to chromatic for alerting me to that):
Well, that almost sounds reasonable, yet this is another person I probably wouldn't hire. This is a slipshod analysis of the situation. Let's say we go ahead and spend $20,000 on an Oracle license, another $20,000 to train our DBA's, and let's say that it winds up costing us another $50,000 to implement this database. We have great scalability and transaction support and no longer lose even the $150,000 in sales that MySQL loses us. That's a net gain of $60,000 for the first year and much more for subsequent years. Further, our Web site winds up having a better reputation for reliability. Who knows what that is worth? While my analysis is just as slipshod (I plucked the numbers out of thin air), it does show that an ad hoc analysis of a situation is not appropriate. Further, the person posting the comment above simply didn't seem to get it: don't pick a technology and then figure out how to justify it. Figure out what your needs are and then pick an appropriate technology.
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.