1. 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!

2. 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”

3. 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

4. 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

5. 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.

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

7. Solution B: Improve the process
Make development
cheaper
better
faster

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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.

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