Gritty Software Engineering

What comes to mind when you think of the word grit?  My first thoughts are John Wayne (in the western True Grit), sand paper, and that white, lumpy breakfast cereal thingy.  Ultimately, I think of a firefighter knocking down doors and pulling people to safety in the face of deadly heat and flames.  Things and people that are gritty have that extra oomph or irritation, just what is needed at times to affect some kind of change.

Probably one of the last things you would consider to be gritty is a software engineer.   As professions go, engineering in general is pretty soft.  Even within engineering, civil engineers, industrial engineers and mechanical engineers are higher up on the grit totem pole than software engineers.  Software engineers sit around all day, typing and thinking big thoughts about how to make something happen on a screen.  The thing being produced only exists because electricity is bouncing around inside a box, or maybe a whole room full of boxes running “in the cloud.”  How fluffy is that?

Let me pull up my fluffy cloud pillow and think about how my app is going to change the world.  Imagine inviting, user-friendly forms, with flowing animations, pre-filled with just the right data.  Ponder the beautifully structured and organized code, with layered abstraction upon abstraction.  No possibility is too small to consider.  Why not bake them all in from the start?  That way our code will be so perfect that it never has to change.

Software is, well, soft.

What makes software hard (as in difficult) are deadlines.  Without a deadline, there is no end to the fluffy thinking, the re-organization of lines of code, the re-design of how some widget or adapter would best work.  With a deadline, choices have to be made and something useful must be shipped to those boxes in the cloud.  Here’s where the real tension and pressure are in software engineering.

Even as my own boss, I have to give myself deadlines.  Having a definite time by which to deliver useful bits to the world begs the question, what needs to work by then?  Answering that question defines the scope of the project, and the scope sets the boundaries that make the work finite, and therefore achievable.

So let’s say I have a deadline, the date by which I choose to release the software, and I have defined a meaningful scope, the features and capabilities the software is to have.  How do I know that everything that needs to happen to achieve the scope can be done by the deadline?  Answer: I don’t.  I never do.  And the problem is worse with a large group of people, compounded by different skill levels, self-awareness, and risk tolerance.  Estimation in software is notoriously tricky, and estimates are always to be taken with a grain of salt (or sand).

After considering everything that needs to be done, weighing tasks I have done before, and lumping in new tasks, creative tasks, and tasks that will require research and learning, at the end of all of that, I have at best a guess as to how long it will actually take to produce a piece of working software.  Divide that guess into the number of working days between now and the deadline, and I have a rough idea of whether it can be done or I’ll need a long ride in the TARDIS to find enough time.

Here’s where grit comes in.  Despite the uncertainty of my estimates, despite the fact that I literally could spend the rest of my life thinking deep thoughts, I choose to deliver something in the next few weeks or months.  So I go for it.

And a few days in, things get tricky.

Hmm, I didn’t realize there are six possible solutions to a problem, all working to some degree the way I need them to, but none quite exactly right.  Do I shift scope (i.e., change what I thought I would produce) or roll my own (i.e., write code from scratch)?  Maybe the requirement isn’t well enough defined anyway, or it was based on no more than a hunch or my own uninformed opinion of how things ought to work.  More research might helps, and that takes time.  Ahh.

Hmm, my mental timeline had me spending a couple of days on a widget that has already taken a week.  Should I rethink it and start over?  Should I abandon hope for now and surf YouTube?  Sometimes yes, and sometimes no.  It can help to step away from a problem to allow the subconscious time and space to figure things out.  And time is running out.  Ahh.

While producing software, unexpected blockages and obstacles keep popping up, and getting past them requires bearing down and pushing through.  I am talking about mental grit.  The oomph to work through problems, the irritation that nags and tells you to keep at it until things work smoothly.

It is the opposite of curling up in a ball, which I could do now that I am working at home.  Not so much when I was in the office.  In an office setting, people surf the Web or head to the water cooler.  Or call a meeting.  Instead, the good engineers work through the problems and deliver on time.

On the grit-o-meter, firefighters have software engineers beat, hands down.  But software doesn’t ship itself (not yet anyway, though the robots may be coming…), and I have never produced a meaningful piece of software without a bit of mental toughness to see it through.

Speaking of which, I am on schedule to deliver the next version of StoryTime, soon to have identity management (login / logout, with an editable player profile).  According to my schedule, the release is due next Thursday, and I have a lot to get working still.  Time to get gritty.

2 thoughts on “Gritty Software Engineering

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s