Coder()

Rolling your own

Work on the Obsidian Framework is taking a back seat lately as I write a JSP (MySQL, JavaScript, Resin, CSS, etc.) web application. I am hoping that is going to be a nine-week baby…. but we’ll see.

More on the unpleasant state of some of these haphazard technologies later (I am refering[sic] to Javascript and CSS) - but as I write the code I came face to face a number of times with the option to either download and use somebody else’s code or write my own.

 Given that Not Invented Here (NIH) is a perjorative it is obviously unpopular to advocate writing ones own routines when reusing someone elses will ‘work’.

 But there are good reasons to write ones own:

1. When it is faster to write the code that it is to understand how to use the often overly generalized and overly documented alternative (why does a logger, or a dispatch routine, take a whole book to document?).

2. When there is anticipation that the functionality that you require does not quite fit into the set of featrures offered by the exisintg alternatives. A collary to #1, really. It is that the time spent trying to learn someone elses code well-enough to A. use it and B. tweak it often is much greater than the time it takes to write it themselves, which comes with a deep understanding that allows one to customize the solution in the future.

3. The alternatives are so general that they hog way more resources than what is desired, or necessary

This is all extemporaneously written and it is very late at night - and there are more reasons than listed above - but the whole thing should be able to be expressed by an equation:

S - set of features required
TS - time to implement those features
SP - giant set of features offered by the ‘popular’ and more general solutions
TPÂ - The time it will take to understand and customize the features to solve the problem we are trying to solve

I am saying that TS is often less, way less, than TP because S is way less, and somewhat different, than SP - and that over time the indepth understanding of the code that is hand-rolled allows one to customize their solution over time to gain market advantage over the competition.

I am not talking about writing one’s own web browser here (wish I was) or database, typically, but about things like log4j, Junit, Struts, etc.

It is my suspicion that the popularity of this ‘rather download it than write it’ attitiude is because

1. The current industry hype says we should

2. Many programmers do not know how to write code - but stitching together someone else’s code is manageable and delays are more justifyable to management if they can point their finger at a tool insetad of their own code.

3. Many programmers who choose what tool to use do not care if they understand the tool or not - they will be on to something else soon enough.

4. Management wants interchangeable coder-bots and everything that will make coder-bots skill-sets more indentical, like understanding the toolkits that their programmers are downloading- makes them that more interchangeable (i.e. easier to hire and fire).

5. Hand rolled code does not get a cool name that can be put on a resume.

So, here’s an idea, let’s start naming our custom software. Let’s see, I just wrote Dispatchertron 1.0., LoggerSharp and TestBot3000 [this works great - it is able to make a browser navigate the site at random - filling in forms as it encounters them with randomly valid data - can’t wait to see if it can be made to handle stuff like uploads…].

Don’t ya think they’ll look great on a resume? :-)

Â

The advantages of DIY are numerous:

1. Ability to fix bugs yourselves

2. Abiltiy to control the release schedule

3. Ability to control the feature set

4. Abiltiy to control the dependencies

5. Competitive advantage

 Using someone elses code does not let a corp focus on core competancies if it takes them more staff hours to understand and use the externally determined feature set and find and fix their bugs than it does to write a little bit of code that does what you need now - written in such a fashion that it is expandable (Agile is good to a point - but until computers program computers - it is often quicker in the long run to think ahead a little) in the direction the corp wants to go.

Â