A Wikipedia One Up Isn’t Sufficient For Your Resume

It’s not in the nature of most people, developers even more so with our huge egos, to admit we don’t know something.  But if you have a life outside of your compiler, you know that some things can’t be read about; they have to be experienced.

For a while recently at a place called Ingenix (United Health Group) I was a development manager dropping in Scrum and Agile practices.  I came to a few realizations:

  • Many say they know how to do Agile, but they do not.  They have not experienced it, and they have read to little about it and reinterpreted what they read into their own understanding (thus learning nothing).
  • The struggle at most organizations is to get the correct tooling to support doing Agile.  This can be CI servers or even the availability of freakin’ meeting rooms.  Without these basic simple things the modern practices of Agile, or any new way of doing things, will fail.  Again it ties back to the simple pattern of learning just enough to be dangerous, but not enough to really understand.

Simple as that.

This stuff is difficult too.  If you want to use Maven on a project, it can take months.  Try telling a VP you want to drop his investment in CVS to switch to Mercurial.  Sit in a scrum with scrum-inexperienced team and watch the waste of time add up.  At my first United gig the scrum master made us report to the business in non technical terms for 45 minutes each day.  We were not allowed to talk to each other as developers . . . we had to do it after, another 15-30 minutes.  Yeah . . a big WTF … One hour everyday of meetings versus the old waterfall one hour every week?  And this person was certified!  (Maybe sometime I’ll discuss the “spirit” of all this, which seems to be more dangerous than just plain ignorance of methodology.)

I am currently working a gig trying to assist a bit in adding Agile practices to their structure, but it has been near impossible.  People get all pissy if you try to “coach” them as to simple meanings of things.  And then, they say the processes fail.

Examples:

  • One developer started listing things like “gather requirements for migration” and “code daos” as spikes.  Spikes are proof of concepts, not actual tasks.  Spikes are like “see if Mercurial will offer something that CVS can’t.”  Etc.  I got my head bit off.
  • TDD.  Oh how I hate it for fuzzy logic workflow/user gesture driven software.  But you ask any of the developers around my current place and they are “experts” on TDD.  “Yeah we’re writing unit tests.”  That’s not TDD!  If they have not done it for real, just read a one-up wikipedia page, then nothing is brought to the table.  TDD is a design methodology – you write a test, then write code that breaks it, then fix the test with the code.  Its not by any means the same thing test-after-development; and it has to actually be experienced day in and day out to fully appreciate its pro’s and cons.
  • Same with pairing.  Pair all day for a few weeks, see what that’s like.  Pair when you do not want to pair, pair with someone you do not like . . . until you do, its just something you read.

My advice is this: remain open minded about these until you’ve actually experienced these things. If you lie about it you are damaging the project and the relationships around you at your gig.    After all, we are supposed to be the modern day rationalists, right?

Comments are closed.