Time and again, I’m astounded when potential clients come to me with their vision for a software development project, along with a budget.  Not because they actually have a dollar figure in mind, but because they think that the coding is all it will take to get the job done.

In fact, my experience is that the actual programming part of a project is about half of the cost. Maybe as low as 20%, depending on the project and its objectives.

First off, you’ve got the discovery phase.  What’s the problem that’s being solved?  Sure, you might have a spec, but really, what’s the problem that’s being solved?  Where will this project be in a year? In two years? How should we best structure the underlying system to be best positioned to deal with these future plans? No code is written here.

Then there’s code, but it’s not really code that gets kept, even if it’s really brilliant. In over 20 years of coding for money (ewwww that sounds dirty,) I don’t know if I’ve ever been given a spec, coded to that spec, and delivered exactly what was asked for without changes.  Sometimes seeing a feature in an early iteration sparks a new idea in the client’s imagination, sometimes enough time passes in the development cycle that a new business driver gets introduced, and sometimes people just change their mind, and woe be unto those who are on jobs where the budget is fixed to a certain overall cost no matter what. Code is written here, but it gets scrapped.

Oh, there’s actual code too. The stuff that makes the final product shine.  This is where the coding lives.

While all that’s going on, there’s infrastructure and documentation. Many projects don’t get a binder full of documents, but every project gets added to a source control system with comments on each check in, and a bug tracker with all issues and their resolutions, tied to the patches that fixed them. Typically, the client never sees this work, but it’s vital to the success of any project that takes more than 30 minutes to finish.

Finally, there’s the post-release phase, where typically the project enters the real world. With real conditions. Things nobody thought to try during any of the testing cycles.  As the technical resource, it’d be great to just walk away here, and the contract often says you can, but in reality it’s best to at least be aware of the long term baggage of even a successful implementation. Code is written here, but is it budgeted?

And yes, those are all parts of “the project” that I’m being paid to do, and I’ll cost out the quote to make these things fit, but too often the value I’m seen as delivering is what I call “the typing,” when in fact that’s a really small part of the puzzle.

This is an evolving list, but it’s one I’m working on building based on past client work. Hopefully, by focusing and expanding on it I can approach projects (internal and external) in a more holistic way so people can understand the true cost, and value, of a professional software development project. My job, as I see it, is to take that budget and put it in the various buckets in a way that ensures the best outcome, which might not involve a lot of actual coding at the end of the day.

(Oooh, look, a technical post, finally! Er, kind of.)

The Lettera 32 would be an awesome netbook if you could type silently

Lots of saved browser tabs accumulating (and some old mental bookmarks as well) surrounding Cormac McCarthy, who apparently wrote the book No Country for Old Men and The Road, both of which were movies as of late, though he’s been published since 1965, so it seems shallow to just highlight the stuff he’s written in the past 10 years.  I mean, they guy’s typewriter sold for a quarter million, and it helped build way more than two books.

But hey, it’s not like I’ve read anything by him.  I just accumulate the links and tabs and bookmarks until they spill over.

So.

Item the first, which is the most recent, is from this week by Hugh MacLeod, in which he retells the story of a young aspiring writer asking McCarthy for advice on starting writing.  The response was “Don’t do it unless you have to.”

That reminded me of a post from way way back on MemeMachineGo, which retold comics writer Alan Moore’s (Watchmen, V For Vendetta, lots of other good stuff) 5 tips for would-be comics writers.  The first, almost not surprisingly “don’t,” with tips 2 and 3 mirroring tip 1 in Fight Club style, but the one that always stuck in my head was item 5, paraphrased thusly: “if you’re going to be any good, you have to commit yourself to it like an ancient Greek or Egyptian commits himself to a god.”

That always stuck with me, but before we drill into that, we’re going back to McCarthy, who John Gruber quoted from a WSJ profile: “Anything that doesn’t take years of your life and drive you to suicide hardly seems worth doing.”

I liked that bit, but that same interview yielded this gem, which was a little less bleak until you think of the ramifications: “If you’re good at something it’s very hard not to do it.”

You know, writing good code isn’t that much different than writing great works of literature, at least from a mindset perspective.  I think the biggest thing the blog and Twitter world has exposed is the (not altogether new) talent of making it look like you’re not working very hard on an all-consuming passion.

OK, so in FogBugz, there’s this fancy pants “Add case” link at the bottom of the list where you can enter one-liners and quickly enter cases into the system, and it’ll even assign them to the project that the list is reporting on.

Visually speaking, clicking on this:

Gets you this:

Then you can type away, hit enter, add another case, hit enter, etc.  It’s a really painless way to add items to the system, and painless means there’s a better chance you’ll actually do it.

It’s very cool, and possibly the best thing in the latest release (we don’t schedule releases in a way that makes the otherwise very cool evidence-based scheduling feature handy for us – yet.)  There’s just one thing…

I was having this problem where all of the new cases were all being added as bugs, which meant that features and inquiries required that extra step of selecting the new items and doing a batch edit to change the category.  More work means less chance of it getting done, which leads to a less accurate task tracking system, which leads to anarchy and cheese flavoured ice cream and whatnot.

Here’s the way around that:

If you sort the items by category, it’ll group the lists by bug, feature, etc.  Each list has an “Add Case” link at the bottom, and if you add under the appropriate one, it’ll be entered in the right category, no second edit required.

But wait!  You can’t click on the category to sort it like you can the other columns!  Turns out you need to customize the filter through the Filter->Customize menu.  Scroll down to the “Sort by:” section and make the first item “Category” (I’m using Status and Priority for the other two at the moment, but that might change).  Save that filter (I’m making one per project, but you can also do it for all the cases assigned to you, for example) and you’ve got something that you’ll be more likely to update.

Plus, the cheese flavoured ice cream forces of darkness will be forced back to their caves for another day.

Common sense that’s worth remembering:

The smart game is building a robust API and let others get creative.

(via A VC)

Everything I do from now on needs to start with an API. We started a 3rd party integration project recently where I had to make one, and it was amazing a) how much re-work was required to expose functionality that already existed and b) how much of our internal code is rapidly migrating over to use the API calls.

I heard this advice a while ago and discounted it because I didn’t want to take a latency hit from a web call within my app to more code that’s essentially in my app, but I finally realized how much of an idiot I was being: your app doesn’t have to use the HTTP interface. You can just call the internal libraries (because you are decoupling your web interface from your core code, right?)

The agony… of waiting…

So I’m chomping at the bit to dig into Visual Studio 2008 with C# 3.0, and I’ve been skimming C# 3.0 in a Nutshell, and we’ve got two new projects on the way that would be awesome to just start with the new versions, but… dependencies…

Web Deployment Projects haven’t been ported over yet.  ScottGu says it’ll happen in the two weeks or so following VS2008′s release, but in the meantime it looks like you can just use VS2005 for deployment.  Not a deal breaker.

ReSharper won’t support C# 3.0 until version 4.0, which will hit EAP in January (not that I’ve heard good things about ReSharper EAPs).  In the meantime, there’s a version of  3.0.2 compiled for 2008 that’ll at least suck less.  Of course, that won’t help people like me who are still running 2.5 and are waiting to hear the upgrade plan (I’m not paying a $150 tax for a month and a half or so of development).

Visual Studio without ReSharper is a deal killer, especially after the last week or two of TDD practice.  The thing integrates so seamlessly into Visual Studio that I can’t tell where one ends and another begins, and I can’t imagine cutting out so many features from an IDE.

Oh well, at least nothing happens in December anyway, right?

Inspired to do some penance following a late-night “there’s a bug in the app” call (OK, 10pm isn’t late, but it’s later than I want to be working), I spent some time yesterday working TDD-style, which I’ve played with before, but this time using mock objects, which I’ve never used but have the potential to make my tests actually meaningful.

The net result?  a thirty minute job took three and a half hours.

Granted, some of that was learning curve.  A lot of that was learning curve, really.  Still, it took a lot to keep telling myself that I shouldn’t abandon TDD, MVC, etc. and just go back to stuffing everything in the codebehind.  After all, I’m competing with other companies whose developers do that, and fast turnaround is all the client cares about, right?

Well, I’m keeping at it, and it’s Donald Belcham‘s fault.

After a long day of patching code and getting the crap kicked out of my by new tools, the last thing I wanted to do was go to a user group meeting and listen to someone talk about Alt.net, but somehow I managed to drag myself there (the fact that the venue was almost directly on the way home helped a lot.)

Wow.

I thought that the talk was going to be mostly about CC.Net and nAnt (which was the original plan, apparently), but it ended up being a two-parter:

1) How to be a better developer

I can’t tell you how much I needed to hear that what I was going through was normal, that nearly everyone gets kicked in the teeth when they start changing their development style, that the code I’m writing now is going to embarrass me in six months, and that it’ll all be worth it.

In the daily scramble to juggle multiple projects (before we finally started hiring), I lost track of what I loved most about software development: continuous personal improvement.  Donald pointed out that learning to write good code just like going to the gym: you need to practice regularly (he had an interesting practice of holding “corporate retreats” where he’d hole up in a hotel for a weekend just to write new code.)

I really wish that our new hire was able to make it to the talk.  Now he’s going to have to listen to me go on and on about it.

2) Code examples

Time was getting tight, but Donald managed to show us some examples of Monorail, which is apparently the most production-ready MVC framework for .Net out there right now.  I need to take another look at it – while there are some issues with NHibernate and MySQL, it’s a good candidate for a practice session.  If nothing else, I jotted down about a dozen future search terms for the google.

I wasn’t able to implement any of the ideas right away due to some other deadlines, but I did manage to see my TDD adventure in a new light.  Yes, it was a frustrating few hours, but in the process I managed to come up with a new refactoring for our data access layer that looks promising, I discovered a few coding practices that I need to stop (boolean functions that always return true, for example), and in theory I’ve got code that’s going to warn me if I inadvertently break it by making a change somewhere else.  Cool.

Thanks again to Donald as well as the Metro Toronto .Net Users Group for hosting the talk.  I went in wishing there was wireless so I could get some work done, and I left regretting that I couldn’t stick around for drinks.  I don’t want to tag it as “life-changing,” but I think it’s pushing me down a path that’ll make for an interesting few months while I try some more of this stuff out and see how it fits in our organization.