Just Be Honest and Tell the Truth

I just read Ron Jefferies latest post entitled My Named Cloud is Better Than Your Named Cloud and it got me riled up enough to post something I've been meaning to write about for at least a couple of years. His post touches on the point I'd wanted to make, but doesn't quite say it as simply as I think it can be said. Here's what I'm thinking:

If we could just always be honest with ourselves, as people, team members and organizations, software development wouldn't be that hard.

There. Simple. Think about it for a second. All this stuff that we label and group together under methodologies and processes is really there so that we can do One Thing. This one thing, I'm assuming, is usually to create software that fulfills a need. Let's pretend that a software team has been assembled to create an application that fulfills such a need. They've chosen to use the XP methodology while writing this application. I'll go through some of the tenets of XP and run them through my honesty filter:

  1. Pair programming: The team realizes that people will come and go on a project for good (quit, fired, etc), or for short periods of time (maternity leave, vacation, illness, etc). They want to minimize the risk, so they make sure everyone is familiar with every piece of the code base. They also realize that sometimes even the best developers do stupid shit for no good reason, and believe that having two sets of eyes on the screen at all times will lessen the likely hood of this happening.
  2. TDD: The team realizes that writing software is hard, and that stuff that worked last week will have to be changed this week. Since they want to ensure that stuff they worked on earlier still works when they make these changes, they write tests, and ensure that no code gets checked in unless all the tests are passing. They also hope that these tests provide some form of documentation to any developers (and perhaps users/clients) that may come later or who never worked on the feature originally.
  3. Incremental design: The team realizes that there are unforeseen forces that may threaten a project at any given time. A big project entails a large amount of risk for both clients and developers. If features can be developed in incremental fashion, hopefully in an order representing the importance of each feature, then risks can be mitigated. The team is always working with a usable application, so that if something comes up that stops the project, at least the client will have something to work with.

Now obviously there is more to XP than what I've listed. The point is that those three things exist to handle a need that most teams, if they are really honest with themselves have:

  1. Knowledge transfer. Nobody wants to have to rely on one person to get something done. Sooner or later, this always bites us in the ass. Pairing is one way to handle this.
  2. Developed features continue working. Nothing is more frustrating (to users and developers) than having something that used to work perfectly stop working. Testing is one way to handle this.
  3. The need to guarantee that something will come out of all the money we're spending. What happens if the development shop you've contracted goes bankrupt before they've finished your application? Incremental design is one way to handle this.

Listen. We have methodologies and processes for a reason (I hope). Some of these processes may work for you. However, maybe only some parts of a process work for you. The point is, it's not about the process. If you can understand why you're using a particular piece of a process, you can assess whether it's useful for your team. Who cares whether you're doing XP, Scrum, Lean, Kanban, Waterfall, or Hack 'n' Slash. Those are just names. Identify your pain points, problems, worries, etc, and try to fix them. Honestly.


Posted 06-24-2009 6:27 PM by Jeff Perrin
Filed under: , ,

[Advertisement]

Comments

James Gaisford wrote re: Just Be Honest and Tell the Truth
on 06-25-2009 5:18 AM

I agree. I think sometimes we all get a little lost and forget what it is we are trying to achieve. When you strip all the fluff and buzwords away all we are doing is writing software. Admitedly this can become complex, but as sugested here and in Ron Jefferies' post we can pick and choose things that apply to our situation rather to minimise the complexity and help deliver what our customers have asked for.

Julian Browne wrote re: Just Be Honest and Tell the Truth
on 06-25-2009 10:49 AM

So very true - and something that's bugged me a lot over the years.

My theory is that some people feel the need to dress up simple concepts with buzzwords and ideology as a protection mechanism. Mostly because deep down they fear they're not up to the job. And sometimes they're not.

It's a sign of 'good' people that they *can* relax and be honest about what might work, what might not work and (most importantly) what they don't know.

It would make software development easier just as you say, because deep down it is pretty hard to do and none of us have all the answers.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)