Solving the CF Programmer Shortage The Business Case for Fusebox Joke about 2 women go into a restaurant in New York city. “The food is so bad here,” one says. The other responds, “yes, and such small portions”. 2 studies tell us that we programmers have a 70% failure rate. Yes, says another study, and there aren’t enough of them!

Such a bad deal? Job security Pick and choose from several job offers Higher salaries Easier to negotiate for better perks Who cares if there’s a labor shortage? “Apres moi, le deluge”

If shortage becomes a crisis… ColdFusion? Business will choose another technology that is seen as having greater support. Hint: Begins with an M and ends in a t. Cf  niche player

And if that happens… High salaries Pick your job Great perqs Away go high salaries, ability to pick your job and great perqs I know you don’t care about this, but for the customer’s sake—left to the cruel designs of other developers. Pick your job Great perqs

Is there a programmer shortage? There is only a developer crisis if projects: cost too much take too long to complete don’t work as they should Clients don’t care about how many developers there are in the world.

Solution A: Cloning existing coders One has to like its elegance of approach, but alas, too many bugs remain.

Solution B: Improve the process Make development cheaper better faster

Common development plan Project Start Begins with many people sharing decision making Over time, point of pressure falls on fewer and fewer people who must make more and more of the decisions. Deployment deadline

Fusebox development plan Project Start Cheaper Better Faster Begins with a few people—architects—making specific decisions Over time, point of pressure falls on larger and larger numbers of people who need only make decisions specific to their code. Fusedoc offers a way of allowing the architect to specify the contents and responsibilities of code modules or fuses. BENEFITS: Wide spectrum of developers—including basic HTML layout people—can be involved productively throughout the project. Wide spectrum of hourly rates working on a project. At the critical point we have the most resources deployed—which kind of makes sense. Reduces risk of project overruns, speeds development. Benefits: Deployment deadline

Critical path Dependent Events Independent Events G2 H4 I3 A2 B4 C2 D2 Why care? Critical paths define the shortest possible path through a project. Two types of events: dependent and independent Dependent can’t be started until the previous one in the chain is finished Independent can occur simultaneously All you need to know: Dependent: bad Independent: good

Risky critical path D2 A2 C2 E5 F2 G2 H4 I6 J7 B4 Common cp get some help in the beginning but after a while everything becomes dependant Everything hinges on something else prior to it. 3 mos getting to 90% done and the next three months getting the last 10%. B4

Risky project visibility Ideal project: complete visibility Why? Because we couldn’t really see where the project was. We were relying on hopes, intuitions, words of others. In an ideal project, we can see where we are at all points. There are no blind spots. In a risky project, we catch only snatches. Raises costs, delays deliveries, endangers entire project’s completion Risky project: low visibility * Thanks to Steve McConnell for this excellent analogy

Fusebox critical path G2 H4 I6 I7 D2 F2 A2 B4 C2 E5 Cheaper Better Faster G2 H4 I6 I7 D2 F2 A2 B4 C2 Early stages one doesn’t see a lot of progress Later stages, all the work of architecting pays off. E5

Fusebox project visibility Cheaper Better Faster Ideal project: complete visibility Fusebox won’t get you to nirvana, but it may very well get you to more successful projects. BENEFIT: Reduced risk of over runs. Fusebox project: very good visibility

What about better? Fusebox Supports code re-use Cheaper Better Faster Fusebox Supports code re-use Code has already been tested Supports unit & integrated testing Bugs discovered and stomped as soon as possible—by the person who originally wrote code Increases project visibility These are important, but most projects that die don’t do so because of technical glitches

What about way better? Cheaper Better Faster Wireframe/prototype/architecting process echoes natural iterative nature of defining requirements Lets user balance between speed of deployment and completeness of functionality/bells & whistles Protects company from selling a Toyota and having to deliver a Porsche. Number one complaint in softwae development: it doesn’t do what we want it to do.

Is there a CF programmer shortage? Seat-of- the-pants Fusebox You decide