Monthly Archives: January 2015

Your Tools Control You

Been a while since I have blogged. Will be writing a few over the next few weeks.

Hopefully over time you as a developer change your opinions. One thing I have drastically changed my opinion over time on is tooling. As many know I used to work heavily on a tool called mighty moose (still works and is OSS). One of the things I built into mighty moose was a pretty cool graphing feature I thought was the bees knees at the time that I built it. You can see it and alot of other cool features Svein and I built into it here:

One thing that was interesting with the graphs was people would bring them up and file support complaints that the nodes were too little when they brought it up on their code because there were 500 boxes in the graph (one got an OutOfMemory on it, in debugging it was a graph with over 50k nodes in it). This was never a problem with the graph it was a problem with the code.

I still believe such tools can have value and help make better software however I don’t really use such tools any more. In fact I have gone from being very pro-tooling to being very anti-tooling. Tools control your thinking process. I can probably look at the output of your process and figure out what tools you were using!

A classic example of this many have worked with is a typical .NET 1.1 win/webforms app written in Visual Studio. VS has a great (I mean seriously wonderful) step debugger built into it. The problem is that people tend to use it. A typical workflow would be change some code, hit f5, start stepping through. One of the other cool features, truely innovative at the time, was the ability to easily change code on the fly.

Speaking of ASP.NET have you ever looked at what came out over http from it? If you ever have wondered what a dementor’s kiss feels like I reckon its similar.


The problem in this example is when you are then given the code that was developed in this way. You suddenly find out that is the only workflow that will actually work with the code. You will find other artifacts as well such as nested loops and longer functions as the tools work better that way! Its quite annoying to think step into vs step over.

This is a classic case of tools controlling your output.

Other examples of this can be seen in tools like intellij or resharper. A typical smell of such tooling is that interfaces are backwards in a domain model. Instead of the domain model defining the contract it wants and an implementer adapting to that interface they “extract interface” from the implementer. This is quite backwards but a typical smell.

Another example can be seen in code of people using containers, ask yourself do you use almost exclusively constructor injection? Have you constructor injected a dependency that you only used in one method? Does the granularity actually match there?

Given most of these things are small. But these small changes start adding up.

Back to mighty moose. I found it changed the way I was writing code. One thing I got lazy with was the structure of my code in terms of files because I had graphs to navigate. I also got lazy about tests because the minimizer would not run them most of the time. I even got a bit dangerous trusting my risk metrics.

Today I have gone back to a plain text editor.
I write unit tests but don’t TDD (TDD has its effects)
I like REPLs
I try to log like I am debugging a problem (should be normally debuggable without a debugger, let’s just say when running involves burning eproms you think more about it first)

What’s interesting is I find I am almost back to where I was 15 years ago writing embedded code on 68030/68040s with a VT terminal plugged in for log messages. I see more and more the push back on big tooling and its a good thing (of course the “pushbacks” keep adding more and more functionality and becoming IDEs themselves! kind of reminds me of the 3 year old 50kloc “micro orms”)

p.s. I’m still looking for a nice text editor setup for F# with support for type providers etc if someone knows one.