If you’ve worked around software engineers before, you probably have heard them talk about things such as “source control”, “object-oriented design”, or “Agile project management”. If you’re a non-techie, sometimes the tendency is to wonder, “Why do you need all these rules and tools? Can’t you just write code?”, or to suspect that maybe you’ve got a case of “whiny developers” on your hands.
The truth is, the reason why developers want to follow these kinds of dogmatic rules is because there are two things developers hate more than anything else:
- Writing a bunch of code just to see it get thrown away
- Writing the same code over and over and over again
Developers, by nature, are a lazy bunch. And that’s a good thing – you want a lazy developer, because it means they are going to find the quickest way to do things. As the comic Dave Attel once said (paraphrased), “If you want to get somewhere quickly, you ask the man with one leg – because he knows the shortest route there, and it ain’t going to involve jumping over any fences”.
In the same way, a “lazy developer” will know the quickest way to get the entire body of work done – in a way that is maintainable for the long term, even if it seems like it takes more effort in the short term to do things “the right way”.
Following along with this, the reason that developers want to follow their somewhat dogmatic rules is because most of those rules and processes – most, not all – boil down to one core purpose: reuse.
If you don’t have your source code inside a source control management system (such as Subversion, Git, or TFS), then it’s really hard for developers to share code, or know what changes have been made to a set of code, or merge pieces of code that do similar things together so they can become one.
So without source control, reuse suffers.
If you don’t practice object-oriented design (which we can mentor your team on), then you can’t really break out sections of code that do some useful feature and then use them all over the place. You also can’t create business object structures that allow chaining of behaviors in ways that is easy for other developers to follow. For instance, in a non-object oriented codebase, your developers will be writing multiple lines of code to “verify login security” all over the place – instead of just calling “User.VerifyLogin()”.
So, without object-oriented design, reuse suffers.
And lastly, without a shared project plan that allows developers to see and understand what the rest of the team is working on, you can’t provide for the kind of innovation by developers where they say “Hey, wait, you’re doing the same thing I’m trying to do – let’s break this out and make it a shared object.”.
When developers can’t see in real-time what each team member is working on, reuse suffers.
The benefit of all this potential reuse is simple: it saves you money. Every time a developer can pull up a shared library that he wrote because he had a strong object framework, could see other code being checked in for a similar task and grab it, or saw that there was overlap in the task list, you ought to be hearing your cash register ringing. Not only have you saved valuable developer time, but you’ve also saved having to test the different pieces of code that do the same thing, and fix any resulting bugs in all those separate piles of code.
So, in the end, it’s all about reuse.
