Tooling And Manholes
I found that any substantially intricate system eventually grows a need for tooling so that it can be readily introspected. Every time I got to spend substantial time of working with a product I wrote myself a bunch of tools that I could use to inspect the system faster and automate most of reoccurring maintenance work.
E.g. often I was trying to debug an issue within an application by starting up my local web server, logging in using my browser and only then performing this particular test just to find out that the issue was not a bug but misunderstanding of the application domain. As the time spent introspecting the system accumulates you cannot fail to notice the overhead all this UI cruft has imposed on you that you have to navigate through.
A bonus point of writing these tools is that you get yourself an additional use case for your problem domain model code, so its design improves earlier, an effect that is similar to what you would get using TDD.
I prefer making command line tools for this kind of job as those:
- are composable when using a proper shell (i.e. almost anything but Windows cmd.exe), and
- can be launched and tested fast, using just the keyboard, rather than the unwieldy GUIs.
Composability is very important here because I can then use the whole UNIX toolset or the Powershell to easily build higher level tools and scripts for the maintenance of an application.
Published: 2012-09-29