Projects

/* If you try to teach a physicist how to throw a ball you basically have two options: you can describe the forces that affect the ball (hand, gravity, friction) or the transfer of energies (chemical, kinetic, potential, heat). The first is a detailed, moment-by-moment account while the second is a simpler, high level description. It will give our guy some insights as to what goes into throwing a ball with no serious danger of unleashing a ball-hurling-physicist unto an unsuspecting world.

Ready? Here is everything you need to know about software projects, provided you never try to actually execute one (if you want to learn how to do that, I recommend failing miserably at your first project and never repeating the same mistake twice).

A project, any project, is about trading money for some desired output. The trick about managing them is optimizing your expenses and output so your customers and CFO are equally happy (or miserable, depending on the industry you happen to work in).

With software, there are two surprisingly common misconception regarding each side of this simple equation:
(a) Optimizing programmers' time instead of cost. It doesn't matter if you measure your input with dollars - the question is how freely can you use your budget to purchase things that improve quality, such as training, services, hardware, software, etc. If you can't, your input is actually man-months and not money.
(b) Targeting the agreed (and often signed) scope of work. More often than not this approach will involve post-delivery-lawyers or at the very least slowly eat away at a firm's reputation. The real output of a software project is Quality.




On one extreme you can drive down cost by doing nothing. On the other, you spend eternity perfecting your software. Just before that there is a green zone that means your users are at various acceptable degrees of happy.

There are managers, often senior, who'll do anything to cut down the cost of a project. These managers are usually not technical and consider the developers a bunch of misfits that wouldn't be able to find their desk in the morning if it wasn't for them (so they build a maze of cubicles, just to prove their point). They know about the red zone just beyond quality and are terrified of it. They believe it is the source of all their trouble (it almost never is) and often use it as an excuse to ship horrible software ("it would take you forever to get it right so just ship it now"). They are the main reason software is in such a bad state and I hope hell has a special testing department just for them.


Although time goes hand-in-hand with cost it deserves special mention because while the law of Diminishing Returns is at its worst when applied to software, it is often ignored to simplify project planning (by developers too!). Also, managers believe that they can do that because the effort estimations are exaggerated anyway (and they are: if management believes that the budget is exaggerated the only thing left for the developers to do to protect their project is overestimate).
There are no shortcuts: if you want to change your work force for a particular project, you have to make sure you can re-plan it so you actually finish sooner. I've seen projects where taking a few people off the team actually reduced time-to-deliver (btw - if you haven't read the bible, go read it. now. seriously).





Cost and Time are just two (albeit important) factors that affect project success. There are countless others. Every decision during the life cycle of a project trades off some parameters, more often than not, affecting quality.
Which technology to use? What development process to apply? Do I unchain the developers from their cubicles at night so they can go home and watch Seinfeld reruns?
Some ad-hoc decisions are just other ways of looking at money and do not deserve a place on the circle. The ones that do, are the ones that deal with principles or general guidelines that are easy to dismiss in favor of short-term goals. When you draw your circle you have to decide which values are part of who you are and how you envision your work.
Take for instance the happiness of the team. A happy team will create better software. However, happiness costs both money and time (also, too much beer and your happy team might yield some silly creations). There is no "right" place to put the X but you have to make a conscious decision of where you want to be - it will make sure you will get there when the pressure starts to build.




Future and past projects often affect your current project far more than the decisions you are currently making (this also gave me a chance to test 3d modeling software to find the one intuitive enough you can use without permanent brain damage - Rhino). For instance, a common development approach, formally known as Quick-and-Dirty (QaD) trades speed for future quality (watch this for a good description of the effect and other interesting ideas).
Using new, unproved, technology trades present quality for future quality (or, if you happen to choose wrong, for the money it costs to redo everything). If you don't train your people you will get better cost and delivery time until one day you won't be able to deliver anything, etc, etc.
I once worked with a team that wouldn't upgrade their development tool because they were afraid it will let in bugs they weren't testing for. Seven years later they had to upgrade six major releases and ship a version that had some major new functionality, all in one shot. As you might guess, it wasn't their finest hour (the previous versions weren't that great either - teams that do silly things tend not to stop at one).




The Orange tells you everything you need to know about software projects: Quality is what you are aiming for but be careful of overshooting, a lot of other constraints make quality hard to achieve, your decisions in previous projects affect your current project which in turn affects your ability to deliver quality in the future.

The rest is details.

And like any good model, when you run out of dimensions you can put on paper, it's done.
*/

public class U {
 
    public Action solution(Problem problem) {
 
        int timeToThink = problem.getComplexity();
 
        // Turns out it is more important to get
        // it right...
        // if (World.getPressure()==Pressure.HIGH) {
        //   timeToThink = SHOOT_FROM_THE_HIP;
        // }
        return courseOfAction(problem, timeToThink);
    }
}