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


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 DevelopmentHere 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?