Don't Over Do It

So I recently mentioned building things 'well and in context'. It occurred to me after I wrote that, that someone would assume my intention was to suggest that you overbuild software in order to enable reuse. I would recommend against this. 

As software developers we get paid to deliver solutions. That is, we get paid to put software into production so it can be used to solve a problem. It might seem like we're being paid to create code, deployment is someone else's problem, but I assure you that is not the case. Eventually time catches up with us all, and in the final evaluation, if we have not delivered code to production we will be downsized. 

Time and time again I've seen teams of developers slave away to build a system only to have it shelved. The developers usually survive this and move on to other projects. Someone else takes the hit. Eventually though, an organization will falter and collapse if nothing ever gets delivered. An organization that is paying attention will shed the weight of a dysfunctional development team before that collapse ever happens. Sure, they might do it by re-assigning the developers to COBOL maintenance, but they will solve the problem. Of course if you are a contracted resource, you simply get an email telling you to not show up on Monday, m'kay. 

Anyway, I digress. When I talk about building things well and in context, I'm talking about staying focused and creating only the code necessary to solve the problem at hand. That code should be well crafted. It should have a complete set of unit test, integration tests as necessary, and of course, acceptance tests. Everything should be well named, formatted, and clean. But it shouldn't do anything other than what it was intended to do.