Campfire Engineering

This is about a methodology.  A way to build, or more accurately, not build, complex systems.  It will not be useful to you other than providing some trivial satire and a thread of solidarity for those engineers who are stuck in the Wild West, victims of endless death marches and tireless heroics of one epic Spaghetti Western after another.  It’s been around forever, under various names, but I’ve come to call it Campfire Engineering,  and it mirrors the cultural trends we have seen over the last two decades.  We have anorexic attention spans, a demand for spoon-fed, rapid fire convenience and instant gratification.  Maybe we’ve always had this lust for fully-automatic shortcuts, now we’re just getting better at it.

What is Campfire Engineering?

In a nutshell, it is a complete anti-methodology.  Its nihilistic approach dictates that nothing matters short of delivering “something” to the customer.  If you’re any kind of engineer and find yourself in this situation, you may begin to wonder what you really got out of your engineering degree other than some decent hookups (yeah right) and a few great parties (maybe).  It means that whatever it is you are working on is not serious, or, as some of my colleagues once put it, don’t worry, it’s just a movie.

If Ivory Tower Engineering is the tyrannical adoption of engineering standards, implemented with textbook perfection, Campfire Engineering stands in stark contrast, at the other end of the measuring pole — a complete and utter bastardization of the Agile methodology.

The fire and smoke is symbolic and bedrock to the methodology — the dazzling fire serves to distract stakeholders and projects teams working in constant crisis mode.  Work is getting done, albeit less about enhancing the system and more about fighting fires.  And if a particular fire gets too large, or the frequency of fires too alarming?  Enter the smoke.  The smoke provides layer upon layer of obfuscation to hide incompetence, lack of discipline, or just plain laziness.  Charismatic smooth-talkers, masters of the art of smoke and mirrors, deftly navigate mine fields of angry customers and stakeholders.

Writing — A Disappearing Art

Conference Tables.  Meetings.  White boards.  Emails.  PowerPoint.  One drive thru conversation to the next.  Groups of professionals and project teams gather around, talking boorishly about possibilities and schedules and budgets — maybe even drawing some stick figures and conceptual diagrams to illustrate architecture and design principles.  But writing things down is just a side note.

Buzzwords fly across tables and blank stares are replaced with nods of affirmation.  Bullet points are projected for rapid consumption.  Smart people dribble smart things that sound important.

Writing is hard.  If forces you to think.  It forces you to conceptualize ideas, systems, plans, and processes, and communicate them in a clear, consistent manner.  It forces customers to dig deep and become experts on what they need, and in turn, project teams translate these needs into requirements.  If you are dropping $300K on a project, wouldn’t you want to be sure the project team is building what you want?  Maybe not — customer representatives can find themselves hopelessly lost in the art and science of effective project management, and worse, they can be so far detached from the actual source of funding that costs become less essential than “just getting something done.”

Need requirements?  Just have a meeting and talk about what the customer wants.  Something breaks?  Just have a meeting and smart people will tell you how it will be fixed.  Stakeholders are pissed?  Just have a meeting and charismatic smoke and mirror artists will assuage their anger.  Rinse and repeat this cycle as needed.  Documented Requirements, Systems Engineering Plans, Test Plans, Configuration Management Plans — these are all side notes.  Superfluous fluff.

Standard Operating Procedure (SOP) for Campfire Engineering

In conclusion, I’d like to provide a general SOP for the Campfire Engineering practitioner:

  1. Always exploit the short attention spans of stakeholders.
  2. Master the art of improvisation and “smoke and mirrors” techniques.  Learn how to talk your way out of anything.
  3. Stove-pipe information whenever possible — this will increase your individual value and job security.  If you write anything down, keep it to yourself.
  4. Master the art of off-the-cuff analysis.  Reports are for desk jockeys and people who want to appear smart.  Use email, phone conversations, and meetings in place of technical reports.  See #3.
  5. If you have to write a plan or report, scour the Internets and find some material to cut-and-paste.  You’ll feel better because no one is going to read your crap anyway and you didn’t waste time writing it.
  6. Requirements are overrated.  Stakeholders don’t know what they need.  You know what they need.
  7. Don’t worry about testing.  Just check the boxes and get it out there.  True testing is performed in a production environment anyway.
  8. Risk Management?  Don’t bother, it’s for geeky statistician types and we rely on recurring realization of risks so the high frequency of fires distracts stakeholders.  See #1 and #2.
  9. Security?  Of course it’s secure.  Just check all the boxes on the security checklists–this is all the auditors care about.  Who’s really going to have the nuts to ask questions and jeopardize our deadline?
  10. Keep project team roles and responsibilities obfuscated.  Everyone can do everything.  Everyone is accountable and hence, no one can be held accountable for anything.  See #2.
  11. If something goes wrong, hold a meeting.  Say smart things.  Draw pretty flow charts and data flow diagrams on whiteboards (use multiple colors).  Dazzle the stakeholders!  Treat them to donuts and hot coffee.  See #2.
  12. Engage in “fuzzy” math whenever possible.  Don’t worry about milestone dates — they won’t be met.  Don’t worry about costs — the budget will always be overrun.  If the customer starts whining, see #2.
  13. If things continue to go badly, just call in an expert and have a meeting with stakeholders.  Let the expert tell you exactly what’s wrong and how to fix it.  Treat everyone to donuts and hot coffee and make sure you smile a lot in affirmation.  Ask at least three smart questions.  Tell the stakeholders you will fix it.    Adjourn the meeting and forget about the problems.  The beauty of Campfire Engineering is that it exploits the short attention span of stakeholders — there will always be more fires to distract them.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s