The Consultants' Toolbox

Presentation

Before you buy a suit and enroll in Dale Carnegie, keep in mind that the best presentation of yourself is to present yourself as you are and not some constructed image of yourself. As we've discussed, networked markets are not stupid markets. They know about marketing and media, and they can see through the masks. They also know about internetworking, and the new market expects a different face to come out of it, a human face. A case in point was an online Careers website who caused an explosion in membership on their "resume and jobsearch" portal by changing the name from Career Central to Cruel World.

At the '99 LinuxExpo in Raleigh, I spoke to an old-school MIS person who remarked about the general flavour of Linux presentations, "Everyone says, 'have fun!' I've never been to a conference where every talk ended this way." Your clients are not accustomed to this, but make no mistake, they welcome being granted the right to be human.

The re-humanizing of business through the open source movement is apparent in our presentation materials. No one wants a Powerpoint presentation and a slick 4 colour proposal, and if you look around at the Linux expos, notice how even the staid and conservative stalwarts of big business go out of their way to dress-down. I don't think they know why, but we do: A networked market does not trust a slick presentation; it expects and demands an honest, direct and even blemished communication. It wants a conversation.

Avoid talking down to clients or speaking obtusely; they are well-informed and understand their market and their occupation. If they don't understand what you are saying it is not because you possess some secret arcane knowledge. It is because you failed to explain yourself. To say that in our language, the Client-Server model must be a peer-to-peer model. If I gave you an obtuse and clouded API for RPC, you'd call it a bad design; business communications is exactly the same.

When to say "No (thank you)"

Turning down contracts is one of the most difficult tasks for the beginner, and this is no easier in the open source support world than in any other service industry. Sometimes, you just need to walk away. Newspaper classifieds abound with help-wanted ads for hairdressers and collection agents, and software contract offers also tend to overflow with what I call "suicide missions", jobs you have no hope of completing, and for which the company needs a scape-goat.

The most sure-fire symptom of a suicide mission is a call for a system designer, for a top level architectural job, where the requirements list only constraints, typically a checklist of inappropriate technologies. Most likely, your predecessor presented an ill-conceived plan, was granted a budget, purchased a lot of disjoint toys, and then bailed. Another warning light is stock options in lieu of decent wages; they may very well be legit, but if it runs sour, you're unlikely to ever see those stock options (unless your sister is a lawyer). It's not up to you to finance a new company; we have venture capitalists for this.

As much as you may love Open Source software, as much as you may want to be among the foot soldiers of the Revolution and aid in the indoctrination of yet another corporate shop, always be mindful of your own needs. If you fail to care and fuel the engine, the car stops, and this does no one any good.

Philosophy 101: Project Planning

In preparing your presentation and your project plan, my best advice is to appeal to the original methodology guru, Aristotle. In "The Four Causes", we get an ancient philosopher outlining precisely what is contained in all the volumes of UML guides, but in a characteristically concise and elegant plan:

• Aristotle's first cause for any action begins with the Formal Cause, the plan of what we intend to accomplish. In software engineering, this is called the "Requirements Specification" and lays out the business problem that the software is to solve. In UML, this is the suite of use-cases.

• Once we know what we need to accomplish, the Material Cause follows showing the components we employ to effect the solution. In UML, this is our set of data structures and the data sources our program must handle as illustrated by Class and Object diagrams.

• Given the ground we must dig, the Efficient Cause enumerates the methods by which the components interact; in software engineering, the Material and Efficient causes are generally lumped into a "Design Specification" but this is probably why there are so many bad specs that fail to put the data components first. In UML, the Efficient Cause is our interaction graphs, collaboration and state diagrams

• The last cause to form our plan is aptly called the Final Cause and this is the blueprint for the goal of our action, the implementation specifications, the component and deployment diagrams

Together, these four Causes guide a complete picture of the project, and it is worth noting that none of them include notions of time lines although each does lead to a modular view of a project that can be sifted for milestones. You may also want to consider a fifth cause, proposed by the eccentric particle physicist Jack Scarfatti, that being the Future Cause, but that is material for another paper.

Clarity

A consultant's success rests as much on the art of conversation as on the art of good systems design. With Open Source, the tools and products themselves may not have the best end-user manuals, so a major part of the job will be mediating for that lack of documentation. Contrary to a popular belief, obscure coding and bad docs are not job security; they are an excellent way to squander your reputation for integrity. All we need is one client left stranded with a system of ours to become cut off that entire industry for a long, long time. Remember: Markets are networked, and they talk.

With Open Source, we can afford to talk. We can be honest and open with our time lines and project plans. A schedule based on Apache Jakarta knows and accepts that the deliverables in Jakarta are beyond the control of our PERT chart. If we're really pressed, we can run with what we have, but for the most part, there is a sense of human realism in Open Source, a sense that things happen when they happen, and not a moment before. I believe this is a healthier way to run our projects

Open Source also saves us the rigours of traditional top-down software design and encourages a more rational and organic approach; we still need good requirements and systems documents, we still need to apply foresight to our data structures and tailor our algorithms, and we can still use UML or reverse engineering to map and plan our work, but we move in smaller and more flexible "release early, release often" time-scales. Open source, by being victim to global whims of its community, carries an inherent sense of scheduling fluidity that includes adaptability as a basic requirement.

Requirements vs Constraints

Confusing requirements with project constraints is a common error in creating project specifications; any design specified to fit its constraints will be bound to those constraints, and experience tells us our constraints almost always go away. A corollary rule is that, with a few exceptions, true requirements are never known completely in advance. Invariably there is a list of things the program must do, but no guidance on how it is used. Fred Brooks said, "even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow." and I agree: No one knows what they really want until they see what they don't want. Avoiding wasted time on dead-ends and inappropriate methods is yet another reason to start the conversation, to "release early and release often".

Open Source University

What other technology invites you to contribute even if the best you can do is to run the software and report where it fails? What other technical field abounds with volunteer projects eager to count you among the core engineering team? Even in the Linux kernel, we know we have Linus, and we have Alan Cox, but of the other "core developers", who even knows the number of them let alone being able to list their names? And this week's list will be different from next week's list.

Participation is as easy as deciding what interests you, as easy as finding some software that you need, or very nearly to what you need by, doing a search on FreshMeat or SourceForge, and jumping right in (being careful, of course, to follow protocol and make an effort to fit into the community; these are the people skills). Yes, you can pay $1500 for a 4-day crash course, or you can pay yourself that $1500 to take two weeks off to sit and dissect, and hopefully fix KVoice or Mozilla or Kernel SMP support. How could any college teach you better than first-hand experience working with top engineers on a real-world project? Linux is the world's largest post-graduate university with a full-time co-op program, and its free.

Syllabus

You will already know what technical skills you need: You do what interests you, and keep in mind that confidence comes after success, never before. The very best training is in pure play, in taking systems apart, breaking them, fixing them, breaking them again. My first true lesson in Unix system administration came the day I tried to move my /lib directory to another partition — I quickly discovered the extreme dependence of all other basic commands on those files, and also learned how to boot my machine with the install disk, mount the drive, and fix the problem.

My other favourite training ground was the break-neck speed of the development kernel; by only updating my software within hours of a new release, I encountered more hard problems than I might have in years of academic study, and while I gained the accolade of a "CVS surfer" from colleagues, I learned a broad repertoire of problems and fixes. 90% of consulting is simply recognizing the problem and executing the solution.

Intrinsic to all of this, though, was the network of kind colleagues and patient project members who did not mind 50 repeats of the same question when a kernel release upset some core system tool. Once again, the tool-box of the open source consultant does not end at their own desktop, it includes the world.