CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

If you want your process to be followed consistently...

...make your process easy to follow.  Seriously.  If I have to go out of my way to do some sort of bookkeeping that bookkeeping isn't going to happen with the consistency that the metrics loving guy is going to want.  You really have to question whether elaborate manual processes add any value.

I took a linguistics class in college.  I don't remember much (other than thinking the prof was a total clown), but I do remember that the evolution of a language is often just a constant erosion of sounds in a word until the word is easier to pronounce - especially words that are used often.  The evolution of a process should be the same way.  Anything that's clumsy or manually intensive without adding enough value to pay for itself should get all of its rough edges sanded off until it's easy to follow and smooth.

Of course I've got that Pollyanna idea that the people that have to follow a process should be completely empowered to change, adapt, and modify that same process.  Bad, clumsy processes are almost always the product of somebody that doesn't have to dogfood their ideas.



Comments

Peter Ritchie said:

Not only should a process be adaptable but those who use a process *must* adapt it to their needs and use continuous improvement to ensure it is still relevant and that they're not wasting time on artifacts or procedure that doesn't add value to their particular project.

# June 26, 2007 11:04 AM

jdn said:

When the processes you follow are dictated by an SDLC created to follow a strict interpretation of SOX, 'empowerment' is about the last thing people have.

# June 26, 2007 12:06 PM

Jeremy D. Miller said:

@jdn,

I know.  To go Dr. Seuss on you, SOX is a pox.  Someday we're going to have to figure out how to make adaptive approaches play nicely with CMM, SOX, SaaS 70, and whatever else is out there.

# June 26, 2007 12:14 PM

Tim B said:

Having been saddled with an endless string of manual (and undocumented!) processes in the year since our small-ish company was purchased by a behemoth, this rings especially true with me. Thanks Jeremy - I enjoy reading your posts.

# June 26, 2007 3:49 PM

Dennis van der Stelt said:

The same goes for your weblog posts. If you want people to read them, keep them short! :-)

# June 27, 2007 2:53 AM

Dax said:

Pedantically I'd add that not only should a process be easy to follow but that the real reasons for following it should be known by the people being asked to do it.

Sometimes a "bad" process exists for a very good reason.

Also the very act of communicating the why can mean that a valuable dialogue occurs in which both parties may learn something new eg a better, easier way to achieve the same goal or at the very least a better understanding of how a business (or whatever) operates.

# June 27, 2007 5:53 AM

dave thieben said:

Jeremy, great article.  I'm wondering if you could write a little about a practical example.  I understand conceptually what you're talking about, but it always seems hard to implement in real life.  Also with continuous improvement of the processes...

# June 27, 2007 1:58 PM

Martin Jul said:

Dogfooding your own process. What a great description - and really, your point about inspect-and-adapting the process, too, is really good. Even RESISTING the urge to create a process is often the best advice since processes tend to be like legacy software - in the way, and hard to change.

I have blogged about that in the context of retrospectives in this article about using

<a href="community.ative.dk/.../retrospectives-adapting-to-reality.aspx">using  retrospectives to adapt to reality</a>.

# June 28, 2007 4:55 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP