Having spent a few posts on .NET specific tools, I'll get back to more process and architecture oriented topics for a bit now...
As a believer in Agile and XP for delivering software (where appropriate), I subscribe to the "simplest thing that can possibly work" ethos - not overengineering a solution based upon the assumption that as yet unknown requirements will change the defined implementation. An application of YAGNI, if you will. Whilst numerous people in the office have taken this mantra on, I've spotted a lurking anti-pattern that's reared its head a couple of times:
"The simplest thing that could possibly get me out of work"
One of the great things about Agile/XP is that it delivers some control back to the developer, removing the need for business analysts that are basically translator-patterns from business -> technology. This is also one of the approach's problems (which I will discuss in another Blog entry soon); If developers cling to a statement such as "the simplest thing that could possibly work", it means that they are using none of their intelligence, experience, and insight to make decisions. Like most maxims, "The simplest thing..." is a principle to use that cuts to the heart of the majority of cases. It is also a rod for your own back if applied blindly rather than judging the implications of all solutions. In my opinion, a developer is a "professional" who shouldn't mechanically apply rules to derive solutions - a modicum of intelligence is required at each juncture, not a parrot-like ability to repeat a phrase.
I've seen this anti-pattern manifest itself most recently where 2 solid man days were wasted on a task that would've taken 10 minutes if there'd been an understanding of what "simple" implied, and the more elegant solution hadn't been discounted for not involving the simplest steps.
This leads, for me, to two rules:
- Whilst in the vast majority of cases, the simplest approach is the best one, there are numerous other cases where something that is only marginally more complicated will clearly give many times the potential going forwards.
- The "simplest thing" and the "quickest thing" are quite often very different. "Simple" could mean going through 100 files by hand, manually searching for similar text and overtyping it where needed. "Quick" could mean hitting Ctrl-R in a decent editor and typing in a simple regular expression. I know which of the two options I'd choose. And, unfortunately, I know people that would choose the other option, protecting themselves with the "shield of simple". The "sum of simple" should actually be: simplicity-of-each-step x number-of-steps.
The problem with simplicity is that it exhibits no intelligence.
I finished the initial release of my latest (and possibly last for a while) MSI plugin tonight. This one, MSI Command Launcher, extends the ability of custom actions to run user-defined code by:
- Supporting the execution of batch files (standard Setup & Deploy packages don't allow this)
- Allowing for roll-back of execution based upon the exit code returned from running a script/executable
- Provides a standardised Windows GUI for showing command-line input/output, rather than "shelling out" to a DOS box
MSI Command Launcher runs as a proper ProjectInstaller and can be run (i.e. tested) standalone from the command line. Documentation on usage is included in the archive that can be downloaded from: http://www.altervisitor.com/software/MSICommandLauncher.msi
When running, the application appears as follows:
This is a first release of this application, and I've not tested it as much as the others, so feedback would be great. The only problem I know about is if you're writing huge amounts of text to the console in an interactive script (one that requires user input) - the RichTextBox it writes to is pretty slow to update, meaning that input may be expected (and output blocked) before all of the preceeding text has been written to the screen. In applications that are more judicious in their usage of Console.WriteLine, and applications that don't read from the console, this problem won't exist.
If you do use this in your projects, please drop me a mail to let me know - I'd like to track the uptake of all the tools I put out on the Net, so I know which ones to support/extend.