Gray's Matter
Justice Gray - North America's favorite metrosexual strategy consultant

I Wish These People Updated More Than Once a Year

Scott Berkun recently listed off some new methodologies he discovered and asked the community if they had witnessed any of their own.  Now, I've seen all sorts of different practices out there, but to entertain you with my vast, near-omnipotent knowledge on the subject would take the entire width and breadth of the Internet.  Thus, I've reduced the number I'm discussing in this post from a million billion down to only four.  Read on for more details.

Resume Driven Development

You want to have an exciting career full of exciting accomplishments and nothing is more exciting than introducing exciting new technologies into a project!  But what do you do when the new technology has no business justification or simply isn't  the best solution for the problem as opposed to something less sexy?  That's the beauty of Resume-Driven: in this methodology, you don't care!  If you think XSLT is cool, how about using them to completely deliver HTML pages with static javascript inside?  Sure it's a maintenance nightmare but with XSLT on *your* resume, what does it matter?  You'll have left this project by the time it gets maintained anyway!  Building a static web page for an a capella band?  Why not use Microsoft Biztalk?  With RDD your career is only limited by your imagination!

Cut and Paste Driven Development

CutPaste
Definitely the most efficient methodology you'll ever see!  Combat Not Invented Here syndrome in the ultimate way and never write another line of code again!  Don't waste your time with any sort of refactoring strategies when you can simply Shift-Del/Shift-Ins your way to coding glory!  Why bother trying to get code reuse if you can simply copy a method here or there with a quick rename to get what you need?  I was lucky enough to work with someone who used this methodology exclusively, and apparently had become a master at it over the course of a decade-long career.  In fact, he had taken this to a whole new level where he would actually copy entire *projects* worth of code and do some quick renaming.  An underappreciated genius, he was removed from the project after our team discovered his practices.   The official reason was "ridiculous incompetence" but I believe the unofficial reason was "developer envy".  What developer wouldn't be jealous when someone can blow the speed of their development away with only two or three keystrokes?

Meeting Driven Development

As anyone in a high management level knows, meetings are the one essential part of any development project.   Nothing screams "skyrocketing productivity" than sitting in a 3 hour, 25 person meeting where your team listens to something entirely unrelated to their own work.  The best part about MDD is that the meeting becomes the solution to *everything*.  Bugs in testing?  Let's have a meeting.  Unit tests failing?  Let's have a meeting.   You think your time could be better spent practicing software development rather than sitting in a conference room for half of the day?  Let's have a meeting about it!  

[A warning - some people make the mistake of thinking that short, focused meetings (like 15 min standups) are adequate meetings for this methodology, and they most certainly are not.  How can you even get anything done in a meeting where people are standing rather than sitting?  Without a rambling meeting that spans hours and covers about 30 different topics at random, how you truly be sure you've covered *everything* that is important to a project, like your VP Development's opinion of the video he rented last weekend?  Remember, if you have a problem, "the big meeting" is your solution.  ]

Note: this is a close relative of checklist-driven development, where the solution to everything is to make a checklist.   For best results, try to combine both of these together and ensure that the end result of every meeting is that a new checklist is created!  Trust me when I say that design headaches or bugs in your application will soon be much less of a relative problem!

Masterpiece Driven Development

Gold plating - it's not just for metal anymore
Here comes the architecture astronaut!  No matter how simple the problem of "Hello World", it's nothing that several whiteboards full of object diagrams can't solve.  Some of your team might say that you're over-architecting, but sternly remind them that you are on a quest for *elegance*!  After all, the best architectures are never truly finished; they just get refactored again!  And again!  And potentially again.

A client will always forgive a project not hitting *any* of its delivery milestones if they know you've spent that time making the code infinitely flexible and pleasing to the eye.  Trust me, when your key stakeholder gets enraged because your project is late and you don't have any sort of functioning user interface, just show them the code to your elegantly refactored and re-refactored database adapter class and tell them that's what you've spent the last 2 months working on!  I guarantee you the client will be reduced to tears - tears because your code is just that beautiful.

Are there any other ones I'm forgetting here?

Friday, June 22, 2007 #