Everyone Should Bea Toolmaker

Inspired by EveryoneShouldBeaMethodologist.

I've said to people that I've mentored in ObjectOrientedTechnology?, that it's important to feel free to make the tools that make sense in your situation. One individual had asked for the templates he should use, in the sense of, "just give me the formula I need, and I'll crank out the result."

Software development is more dynamic than that, being a game played by and for people. It's much more important to know what the goals are than a particular template. Of course this is just my opinion, I realize.

An analogy can me made with planning a menu (of meals). One approach could say, "Some GreatWisePlanner? created a menu with exactly the right nutritional content, calories, etc. and I will not deviate from that plan" - even if it bores you to tears and other problems ensue that were not anticipated by the GreatWisePlanner?.

The other approach (which I advocate) is that one has a sense of or specific knowledge of the nutritional needs of the body, and of the nutritional content/value of a variety of foods. This allows one to create a smorgasbord of combinations that are satisfying and interesting.

I think some methodologies/methodologists underestimate the importance of keeping interest alive by allowing variations. I believe people need a sense of "spice," a sense of freedom to vary the approach within a set of goals. When the method is fixed as well as the goals, people tend to feel like cogs in the system, robots.

-- JeffMantei 2000-11-29

See: EveryoneShouldBeaRobot

Perhaps I should have been more precise when I said "everyone." The context was of course software development. But, on further consideration, the idea really does apply to other areas of life - just maybe not as consistently.

On EveryoneShouldBeaRobot, a good point is raised: how do you reconcile the customer's needs for a simple, reliable service with the servant's "needs" for a satisfying, interesting job? (In some contexts, the servant's needs are not considered, but I'm talking about a FreeSociety? (oh boy, what will this start?)). It appears to me to be another facet of the DifferenceBetweenSpecificationAndImplementation, which is a fuzzy gray line (more on that page eventually). The key question there is, "Along which dimensions and to what extent should one allow degrees of freedom for implementation in the specification?"

Another aspect of EveryoneShouldBeaToolmaker is the idea of a LearningOrganization. People that have some freedom to make their own tools should also have the opportunity and incentive to share those tools with others. They may also learn even more from doing that. For instance, a coffee server may discover that if he always restarts the pot when it gets to a certain level or a certain age, instead of waiting until it is empty, he gets much more satisfied customers that come back again and again. If he is able to share that with others, you get more satisfied customers served by the other servers. And he may encounter a server that did something a little different, so they take the best of both approaches. Or he finds out that throwing the coffee out is too costly the way he does it, so he finds out how to minimize the waste while still pleasing the customer. (You get the idea...)

If the specification is too tightly constrained, or if the culture does not support inventive implementation, the "learning" is mainly at the uppermost levels of management, when actually, the one on the front line has a lot of information and immediate feedback with which to improve.

This is not a simple issue. And I am aware that other cultures have other biases. For example, Europeans tend to favor a more hierarchical approach, where the decisions are made at a higher level. Americans tend to be "cowboys" in this respect - individual initiative without or in spite of management direction. Someone once put it, "It's easier to ask forgiveness than to ask permission."

More good thoughts:

There was a phrase on QuickChanges I like: WithFreedomComesResponsibility?. That plays in here. In the "European" style (please forgive the stereotyping here), the responsibility lies with upper management; in the "American," it lies with the individual.

-- JeffMantei 2000-11-30

P.S. I do reserve the right to revise my remarks as I learn more about this topic of being a servant and having a ServantAttitude?. This is a topic that I feel is especially important for CommittedChristian?'s to understand and live by (that's all I'm going to say on that - no flames please). I think ServantAttitude? may be closely related to CustomerOrientation?, which is vitally important in business. And a ServantAttitude? does not necessarily guarantee the freedom of implementation I describe above. (The key is to have the right Master to get your freedom, but I said I wouldn't say anymore... :-) Actually, there is an analog to this in business, called ChoosingYourCustomers?.)

Ugh...

"just give me the formula I need, and I'll crank out the result."

This must be among the most scaring words you can hear from someone you know has the potential to be a good programmer.

Part of this toolmaker vision I think comes from my exposure to TheSmalltalkExperience and UnixOperatingSystem. Both of these seem to encourage the blurring between JustaUser? and a co-contributor. A lot of today's IDE's and the WindowsOperatingSystem? and WindowsUserEnvironment? don't encourage extensions to the system.

Another related topic is OnReflection (not written yet). Languages that support reflective capabilities can sometimes encourage extensions.

-- JeffMantei 2000-12-01

Jeff, permit me my standard observation :-) The conclusions that you draw (honestly of course) about TheSmalltalkExperience, et.al. blurring and Windows "not" needn't be due to some advanced planning, insight or what have you by their respective authors. Like so many things it just shakes out that way. The average user of a PC isn't using SmallTalk and they are not using Unix. If they were (and adjusted things) you would notice chaos and an extension would be added to prevent it. Things don't happen as part of some grand plan but rather are incrementally added to solve problems which occur as a result of earlier (more open) decisions. Microsoft has a different audience than say Sun just as Boeing has a different audience than Northrop Grumman and Beachcraft.

One thing I was trying to point out in EveryoneShouldBeaRobot is that "most" people don't want the phone operator, Starbuck's register person, gas station attendant, et.al. making adjustments to the hardware and software they use to service their account. Much less have them pop the hood and make a tweak to the software that controls the fuel-injection on your car.

There is no correlation between being good at a specific service and the ability to adjust software which happens to control the accounting processes for that service. Excellent graphic artists are unlikely to have the requisite skill to customize the code that renders their images hence the user-selectable option rather than the "go ahead an rewrite the DailySales?() method" solution. -- tl

Fascinating discussion. Let me offer a potential counterpoint. To what do you attribute the eternal popularity of ScriptingLanguages in places like MicrosoftOffice if people don't want to build tools?

Being able to "program" is seen as a sign of intelligence, not unlike the Scarecrow and his Brain, so everyone wants to be able to call themselves a programmer. Also, the developers often want a way to let the EndUser handle cases that the developers do not want to. Also, Also, the EndUser often requests such things, necessary or not. -- PeteHardie

Like so many things... it becomes a matter of definition. "People" meaning everybody or programmer-types? Roughly 90% (just my guess) of the MS-Office owners don't know there is a scripting language available.

Next comes "what is a tool?" A macro that types in one's name and address at the start of Word Document? Is that tool making or tool using? We all "use" tools, few of us make tools with significant uses. Twisting a paperclip to hold a joint is toolmaking (in the strictest sense) after all.

And rather than run on at the fingertips... I ask everybody to ask themselves the last time you watched somebody (in your office, at a store, driving a cab, on TV or anywhere) and asked yourself... how did that person get this job? So my question then is. If they couldn't handle whatever task you saw them doing (apparently a regular part of their daily work) what makes you believe that they should have any control over the process underlying it? By that I mean would they do "really well" at developing the software that makes the cash register operate while (seemingly) being unable to make the cash register operate?

Can the bank teller monkey with the ATM machine code? Are we suggesting that software developers don't know how to do it but clerks really understand analysis, boolean logic and the importance of testing? -- tl

An argument can be made that one of the reasons why they can't operate the cash register is because it wasn't designed the way that seems most logical to them. So if given the chance, they could redesign the cash register to make it easier for them to use (but probably harder for someone with a different mindset). But probably not. -- GavinLambert

Everyone is a programmer at least at some level. Working with a drawing package is programming a picture. Writing a graphics program is also programming a picture. The only real difference is the language being used. Maya is more powerful at the high level, Java is more powerful at the low level, Visio has better hooks to other things sometimes etc.