Dave Burke : Freelance .NET Web Developer specializing in Online Communities

iPod and Dog: I'm Agile, you're Agile, we're all Agile

I'm not much for coding methodologies: XP, TDD, Agile Programming, whatever.  As a developer, you either know what the hell you're doing or you don't.

It's real simple.  You approach a project by not over-selling what you say you're going to deliver, and you deliver what you're selling.   The deliverables are documented before work proceeds in a simple yet sufficiently complete outline format that serves as the spec.  You get paid to do the work you do, no more and no less, for an agreed-upon rate (never a fixed total amount for the project), and you deliver each and every item in the spec in as short a time as humanly possible. 

As my client, you'll get the documentation you need, but what you're paying me for is the working software, not the documentation.  Because I respect you and value our relationship, please feel free to email me (don't call, its too intrusive and limits my productivity) any time day or night with any questions or change requests you might have, but if you ask me to do something stupid I'll tell you that its stupid and I may not do it. But it's your money.

Why do you want me to do the job for you?  Basic reasons, I guess.  Honesty, accountability, experience.  Most of all, I think, because I'm what you'd call a "generalizing specialist" who has chops in all areas of the project.  You don't want a database specialist designing your UI for you, or a User Case Specialist designing your database schema.  And anyone I work with is also going to be a generalizing specialist so we can understand all of the project artifacts and business rules, and are able to converse on all aspects of the project life cycle.

____________

I wasn't planning on writing the above, but after listening to this excellent podcast on Agile Programming by Scott Amber I discovered that I've been adhering to most basic Agile Programming principles without knowing it.  I'm certain a lot of other developers do, too.  At least I hope they do, because the more I learn about Agile, the more sense it makes in every way.  So even if you're an innate Agile Programmer from way back, you should still check out the IT Conversations podcast from the SDForum Distinguished Speaker Series.  (Whoa!  I just noticed that it was recorded 2003-03-27.  Oh heck, it's STILL worth listening to.)  If you want a quick summary of what Agile Programming is all about, here's the Agile Software manifesto at http://agilemanifesto.org/. 


Georgeous run of clear blue skies and warmer temperatures in Vermont.  Dogs and I doing the UVM White Barn circuit.



       

Comments (2) | Post RSS RSS comment feed

Posted on 2/3/2005 2:42:00 AM by Dave Burke
Categories: .NET | iPod and Dog
Tags:

Related posts

Comments (2) -

2/14/2005 11:13:00 AM Permalink

I read this a few days ago and had it in my "clippings" to re-read.

I like your comments - they are short and to the point.  How can you or do you get your customer's to see it this way?  Especially if they basically have not knowledge of software or the process of developing it?  Sometimes I just want to beat my head on the desk until I'm unconscious.  I often hear "this is simple and shouldn't take long".  Sometimes they are correct but other times they are not and I'm just thinking to myself "if it's so easy why are you paying me to do it?".

Erik Lane |

2/14/2005 11:30:00 AM Permalink

Erik,  I think the main persuasive determinant is trust.

My experience is that the outline project description (i.e. requirements) are understood by both parties with a sufficient breakout for delivery by phases that keep things moving.

Then we hack through them, deliver as promised, with hourly descriptions for each task, again so the client understands the pieces.  Complete first phase, second, etc., move onto the next.  Client's aware of what you're doing and can gauge where his/her dollars are going.  Its on the bill and on the screen (delivered bits.)

That's where trust comes in.  Client might not understand the particulars, but he's come to trust you.  He knows you deliver, on time, as promised, at a good price, no complaints, everything works, and you keep on coding and following the incremental, phased deliverying approach until the job is done.  

Now, as to your point on why some things take longer than others, again, the trust you've established through performance and delivery buys you the currency to say, "Look, some things are easy and some things are hard.  This particular issue is hard and going to take more time than most."  The client has no reason not to trust you at that point.  Of course, providing a lower-cost alternative is a good move.  I NEVER go into the technical details with the client to justify why something will take a long time.  They don't WANT to know the details.  Heck, those same details often bore me, and the client has other real work to do.

This reply is more of a ramble than an answer, but maybe a summarization would be to represent the project and work performed in small pieces the client understands, deliver in chunks the client can see, don't involve the client in the details unless absolutely necessary, and give them no reason not to trust you.

Speaking of billing, I better get back to Visual Studio.  Great hearing from you, as always!

Dave Burke |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke