Jay Kimble recently put up a great post about 'Git R Done' coding (great title) to call elitist shenanigans on the TDD/Agile/ALT.NET crowd (with whom I'd have to side with on most arguments) for a lot of recent preaching and Mort-bashing.

I must say, Jay's post strikes a chord with me -- in my seemingly-vain attempts to maintain some semblance of TDD/Agile/ALT.NET in my multi-project, many-meetinged day, I frequently find myself asking "is this all worth it? Wouldn't it be easier to sling some VBA in Excel for this?"

I posted two comments to his post, but I think they deserve their own post here (below)

In summary: In my mind, we software developers have to make a choice -- do we want to just keep Gitting R Done all the time like we essentially are today, or do we want to grow up and ENGINEER software for long-term stability and maintainability instead of just DEVELOP software to solve the immediate problem and damn the future? 


If you ask any Professional (yes, upper case 'P') to do something they know is wrong or will lead to disaster, they will tell you "NO!" -- Ask an Architect to place the walls such that they don't load the weight properly, or an electrician to wire the outlets in one big circuit, etc.

But it seems that everyone, including us developers constantly seem to delude ourselves that 'software is easy' when it's really not and needs to be treated with a measure of respect. Perhaps not so much like bridge building, but certainly like any other non-life-endangering engineering activity.

The problem with doing just what the customer asks you is that they're not aware of all the problems they're creating for themselves when they ask you to do X, Y, and Z and it's up to us to explain to them the risks and trade-offs and explain that you can't 'just' (just is a dirty word, I've come to find out) whip up this or that app based on Access because it won't be long before they'll have a data contention disaster and it'll be all your/my/whomever's fault for not pushing back and saying "NO!".

Git R Done is good, but not if the 'Done' involves endangering the customer's software's long-term stability.

No one takes software seriously, they treat it like an easy-built, easy throw away as-needed business tool and don't invest in long term, reliable, maintainable solutions.

And the only ones to blame for that is Us, the software developers, for not standing up and saying "NO!" when the customer asks for a gun to shoot themselves in the foot.

I think why many people slam on the designers and drag-n-drop and such is that it's an effort (no matter how successful this or that one may be) to move down the 'software is easy'.

I think we all need to stop deluding ourselves into believing that one day there will be drag-and-drop development and we'll never have to write a line of code.

MSFT has been promising that year after year, VB after VB, now XML-based BDUF framework after XML-based BDUF framework and we're really no closer. In fact, I seem to be writing more code, but it's much BETTER and REUSABLE code and I've found that BETTER and REUSABLE are infinitely more valuable than less-code-but-miles-of-tangled-executable-XML-and-designer-puke.

I think it bothers me, among others, that MSFT wastes heading down the never-ending, never-producing 'software is easy' road when they can finally give up and starting producing tools for the 'software is hard, handle with care' road which is the road many of us have started embarking upon with great success.

That we slam MSFT is a compliment to them, really. It means we have hope. We see glimmers of intelligent thought and huge promise -- squandered on tools which ultimately drag down the state of the art and do nothing to advance software engineering as less art than science.

EDIT: I forgot to link the 'just is a dirty word' part to Gary Sherman's blog. Sorry Gary, I really did mean to do that!