Friday, September 21, 2012

Tool Based Development vs Tool Based Developers

Tools are meant to increase the efficiency of putting knowledge into practice, not to replace knowledge itself.

A chef prepares a meal. He cooks nearly everything from scratch. There is one particular part of the meal (the sauce) that he could prepare in its entirety, but instead he chooses a popular "out of the can" sauce that tastes just as good as his "from scratch" recipe. He has the knowledge, but uses the tool to increase his efficiency without losing quality. He is a chef who implements tool based cooking.

The tool based chef, however, can't cook anything that doesn't come in a can. He may make a fair meal, but it isn't the best possible, and there is a direct relationship between the weakness of the tool (the stuff in the can) and the weakness of his meal. If one is bad, the other will be as well. He has limited himself, and those eating his food because, although fed, they may suffer adverse consequences (i.e. a bad tasting meal or upset stomachs).

This, in essence, is the difference between tool based development, and tool based developers.

Tool Based Development
A good developer is an efficient developer. For this reason, it is folly to simply reject IDEs and WYSIWYG editors for the command line and hand coding everything. If there is a tool available that can help get a developer's job done more quickly without sacrificing quality, then the developer uses it.

Thus we arrive at the concept of tool based development. A core part of our development methodology is the proper utilization of tools. A developer should be aware of the best tools available to do a job. A developer should understand the quality of the resulting output of such tools. A developer should be willing to use a tool if it saves time and money.

Those who employ development tools (such as Visual Studio among others) have a thorough knowledge of the tool. They are aware of all of its facets that apply to their development needs. A development team should standardize on a set of tools, and be willing to upgrade or change if better tools become available.

The developer is also aware of the weaknesses of the tool. The developer does not immediately implement a process through some device the tools offers, without first lowering his abstraction point to examine the entire scope of the entire project or process, and its ultimate goals. If the tool's methodology saves time in the immediate, but greatly complicates later stages of development, extensibility, or maintainability, then that tool's methodology is rejected.

The developer who implements tool based development is not afraid of problems which the tool cannot solve. He or she has an understanding of the process the tool is optimizing, and dig into that process to get the most out of his development environment.

Tool based development involves using the tool where it increases efficiency without losing quality, and ignoring the tool where it does not.

Tool Based Developers
There is a large difference between tool based development, and tool based developers. The tool based developer sits in a dangerous abstraction point. He is aware of the tool, and the results of the tool, and yet lacks knowledge of what the tool is actually doing to accomplish its task.

There are many weaknesses to the tool based developer. If you make an honest self-examination, and discover that you fall into this category, you must be aware that your reliance on others' work stifles your growth, and ultimately will be to your detriment.

Below are some of the weaknesses of the tool based developer:

Fragile abstraction point
The abstraction point of the developer is extraordinarily fragile. If any requests are made that fall outside of the scope of the tool (or the scope of the developer's understanding of the tool), the developer will be unable to implement an elegant solution.

In fact, the developer may be unable to implement a satisfactory solution of any kind - resorting instead to a tool based solution that resembles at the surface to be what was requested. However, upon deeper examination, the solution will show itself to be at worst inadequate, and at the least extremely difficult to extend or maintain.

Lack of problem solving ability
The tool based developer is weak in the area of problem solving ability. He or she has become so reliant on the tool to do their work for them, that problems which fall outside of that scope of knowledge (i.e. below their abstraction point) are met with confusion, disappointment, desperation, and sometimes anger.

This developer spends an inordinate amount of time searching for other person's solutions to various problems. Failing to realize that every scenerio may be different, the developer reacts to every problem below his or her abstraction point by looking for "the code to" solve it.

Fragile results
Many times what the tool based developer develops at first seems to satisfy all requirements. It "works". However, the process is extremely thinly abstracted making it very difficult to satisfy user requirements once change requests are made. Extending the application to service other needs is difficult, perhaps even impossible.

Ultimately both the user and the developer will regret his or her methodology. Their applications are burdensome (to both the user and the developer), inefficient, and ultimately more financially expensive because the difficulty of extensibility and maintenance.

Deceptive qualifications
The tool based developer may have read every book on his or her field, and can often sound knowledgeable in an interview. He or she may be able to throw about technical terms and buzz words - however this banter is surface only. While able to quote from a book about what a particular concept is, they lack actual understanding.

As a result of this, the tool based developer's qualifications are deceptive. The developer finds his or herself in a job being given an assignment, and the developer's qualifications pass initial inspection. However, as time passes, their inability to problem solve, the inefficiency and lack of scalability of their applications, and the time it requires to implement a solution become manifest.

The tool based developer may find him or herself without work on repeated occasions, which is unnecessary since they are quite likely a bright person who simply does not understand their abstraction point nor how to change it.

Every developer must be wary of being or becoming a tool based developer. Do not simply accept new tools without understanding what they are doing for you. Lower your abstraction point. Only then will you build quality applications, and be able to grow to your fullest potential.


Here is a classic example. HTML (HyperText Markup Language) is the core language of the internet. It (along with the CSS specification) defines how an internet browser displays a web page.

Here are two examples (based on the web development world and HTML) of the difference between tool based developers and tool based development:

Example #1: Page layout

Tool based development
The developer chooses a WYSIWYG tool (like Dreamweaver or Frontpage) to layout his page. The tool greatly increases the efficiency of doing this work.

Let us suppose developer hits a particular aspect of the layout that is difficult to implement. He switches from WYSIWYG mode to HTML mode (i.e. look at the code rather than the tool's interface), thereby lowering his abstraction point, adjusts the HTML to fit his needs, and climbs back up the abstraction ladder returning to the tool's interface.

Tool based developer
The tool based developer does not know (or does not have an adequate knowledge of) HTML. Although calling him or herself a "web developer", he or she lacks knowledge of the very core of their field! They use the tool, and when reaching an aspect of the layout that is difficult to implement, he or she relies on tricks, workarounds, or "good enough" techniques to be able to simply move past a hurdle that could have helped them grow as a professional.

A "good enough" technique is a technique in which the developer, because of the inability to solve a problem, implements a solution that is "good enough." The solution closely resembles what was required, but is not exact in its response. The solution will pass initial scrutiny, but will be unable to support deeper requirements.

Example #2: Code generated HTML

Tool based development
There are various platforms on which to implement web applications (like PHP, Ruby on Rails, or ASP.NET), however all have the same simple goal: to deliver HTML to the user. They may allow for object-oriented programming, file and database manipulation, and business rule enforcement - but the ultimate goal does not change. Tool based development involves using the platform to output the desired HTML.

The developers knows ultimately the HTML he or she desires, and manuevers the coding platform to output just such HTML. This means he or she understands how the coding platfrom generates its HTML, so as to be able to adjust accordingly.

Tool based developer
The tool based developer does not appreciate that the coding platform is merely rendering a service, and is not the ultimate medium through which the user is interacting with the application. Because of this the user interface may be sloppy and disorganized.

The developer fails to understand that when he or she (for example, in Visual Studio, or Dreamweaver) "drags and drops" a multiline textbox onto his WYSIWYG editor, that visually displayed item is a translation of a simple "<textarea>" tag that the browser will interpret. The tool is doing the same work as the browser: interpreting an abstract concept, thereby raising the abstraction point of the user.

Because of lacking knowledge of HTML itself (and we may go to lower abstraction points, as in the way individual browsers interpret HTML, or as in how the Internet actually works) more intricate and elegant interface designs are beyond his or her ability.

There is also the danger of attempting to learn the needed core knowledge solely by observing what the tool is doing (in our HTML example, drag and drop followed by looking at the HTML generated). This is a fine way of gaining some knowledge - but you are potentially limiting or even damaging yourself.

Tools are often designed to generate code that they themselves can easily translate back into the interface. Therefore the code generated may not be the best way of implementing a solution (though it may "work"). Observing what the tool does can give you clues and ideas - not an education. Tool based development is good. Being a tool based developer is dangerous. There is a simple rule to remember (for Windows users anyway): if you can't do it in Notepad you don't actually know how.

In other words:

Be able to do it without the tool first, then, once you have understanding, use the tool to increase your efficiency.

No comments:

Post a Comment