thinking in rules

Tool Oriented Development

Loren Goodman | 11/13/2013

Hammer

In the early nineties we took everything that was on the mainframe and smeared it out to the edges with client server, after that we spent the rest of that decade putting it all back on the server again with web and service based development. Now we are in the midst of another shift with apps and mobile. What has not changed a whole lot is the person that is actually doing the technology creation; the person known as the developer. The converter of concept into reality.

Over the course of my career there have been plenty of software development themes that have come along. Things like event driven, data driven, smart client, object oriented, contract based, service oriented, service based, test-driven, waterfall, agile, DSLs, 4GLs, etc. Some of these were a better and more formalized way of organizing code and separating concerns, others streamlined the project process and communication. Each was an improvement on its predecessor, and once adopted, we never looked back.

Another trend, fourth generation languages, or 4GLs, suffered a different fate. 4GLs addressed the complexities of code creation by shielding programmers from code with a unified tool that generated the application’s code base from higher order constructs, a worthy goal. The thing with 4GLs was that they tried to abstract *everything* and many programming tasks that used to be simple became difficult or even impossible if the 4GL had not accounted for that specific need. As projects failed, 4GLs left a permanent stain in the minds of developers and project sponsors with regards to the value proposition of code generation.

Tool Oriented Development is an approach to software development where the focus is on the creation of narrowly scoped tools which are subsequently used to render portions of the solution’s code base. Unlike typical software development today, where the focus is centered on creating code directly, with Tool oriented development, the focus is on identifying repeating patterns and creating small tools specific to each pattern. These tools generate the code for you. Regardless of whether you type code in directly or use a tool to generate it, the ultimate output is the same. The tool is not part of the finished product.

Tools don’t make creation possible, creation is something that happens in your brain, what tools do is make the act of creation easier and repeatable. If you were in the wilderness and needed to put a nail in a tree, it is much easier to pound that nail in using a rock than it would be to create a hammer. Suppose you had to put a hundred nails in, or a thousand, or a hundred thousand? At some point it would be worth the effort to create that hammer (or even a nail gun!) after all. In addition to reducing the cost of repetitive tasks, things created by tools tend to also have an inherent consistency which supports future operations against them. Moving from a rock to a hammer does not preclude the need for saws or screwdrivers or sanders, all of which make specific tasks easier and improve consistency.

Code generation is a power thing, far more powerful than it is given credit for in my opinion. When tool oriented programmers create these tools, they are leveraging technology for themselves - they are using technology to reduce the effort of creating technology. When it comes to building things, productivity is correlated to how well you can apply the tools you have. Going back to the rock/hammer story, the productivity boost from a well design tool can be measured by orders of magnitude.

The best programmers are awesome at setting up their code for future copy and paste operations. As an example, after adding the code for Address Line 1, the creation of Address Line 2 is nothing more than a copy-paste operation followed by changing all the instances of 1 to 2. Tool oriented development is a similar concept, but instead of leveraging copy and paste to simplify future creation, it leverages a tool to achieve the same end with less effort and more consistency, by letting the computer do the repetitive work of generating the code instead of the developer.

A great tool oriented developer knows when they have hit the point of diminishing returns. The key thing is that this concept can so easily be taken too far where you end putting a lot more time into creating a tool than you save from using it.

So what makes a tool cool? A cool tool is one that becomes an extension of the person wielding it. A cool tool is one that unambiguously does what you expect it to, every time. A cool tool is understood, bounded, and predictable.

Thank you for reading this. I have been toying around with formalizing this concept for quite some time and would be more than excited to get your feedback as to whether or not you think that would be a worthwhile effort.


comments powered by Disqus