Having had time to ponder the world of IT over the rainy summer days in Luxembourg it's time for a non-technical blog entry. The entry is about amortized productivity, or more specifically, about being strategically lazy in order to be more effective over the medium to long term.
I am lazy
I have to admit it - I'm a lazy person. If I can automate automation (meta automation?) I'm all for it especially when it comes to developing IT products. There is a crux though; some work has to be put into the part that automates automation. As long as the work in automating the automation outweighs the work that would have to be put into manually creating an automated product it's a win situation.
This blog entry is about automating automation, a concept I call being strategically lazy. By that I mean that in the long run I benefit in putting in what might look like useless work (it has no functional benefit) so that I can reap the benefit later on. It is done in all types of industries. Unfortunately there is a clear lack of it - with a few exceptions - in the IT industry. It developer and manager use tools like compilers, linkers, IDEs and other industry accepted tools, but they seldom develop their own tools to automate automation.
Being strategically lazy
It is baffling how often IT managers and developers apply different standards to their own work methods than the standards which customers of products will apply in their work when using a finished IT product.
Everyone knows that (one of) the purposes of IT is to automate tasks. That is, IT makes life simple and easy for someone out there in the real world because tasks are being done automatically. For this to happen someone must have put in work, usually lots of work, so that the tasks can be automatically executed.
The users of IT systems are smart since they realize that to be productive they have to be strategically lazy. That is, they can't be lazy in the short term (they have to make money to buy the IT system) but in the long term, ones they have an IT system they can sit back and watch the work being done automatically.
In the world of IT things are often different. In IT shops it is not uncommon to manually create many products which any non-IT person would simply assume should be done automatically by IT if someone just had the skillset to create an IT system. Managers cringe when developers spend time developing non-functional tools that helps them automate tasks. However, managers are not the only problem. Many developers will go straight for the functionality without even blinking when a smarter approach would have been to develop some scaffolding before dropping the first piece of code on the disk.
Being lazy is a good thing and eating your own dog food – here using IT when developing IT – is also good as long as there is a benefit to it. The idea that being lazy in a smart way and using IT for being lazy when developing IT systems should help in working less and producing more.
Being lazy when writing documents
The first activity that comes to mind where as an IT developer I would want to be lazy is of course the task of writing document. IT departments are notorious for pumping out documents at an ever increasing rate. Here I mean manually written documents that take both time and effort to write and which are often out of date when they hit the printer tray.
When really thinking about it, it's astounding that documents are not automatically produced in IT departments. There is no magic in doing so. All it takes is to develop models which are programmatically accessible. As soon as a model is implemented and can be accessed programmatically, an almost innumerable number of views of the model can be created and mapped to text and diagrams.
Let's take a concrete example. The description of a large architecture containing systems, interfaces and processes among other things can be described using hand written Power Point documents, which by the way is most often the case. It can also be described using a programmatically accessible model– typically realized in a relational database.
Yes, it takes a little more effort to do so but ones it has been done it can be extended little by little without having to manually update and rewrite documents. And by the way, we are IT developers so it really shouldn't be a big deal. Once a model has been built, documents can be automatically generated by mapping projections of the model onto text and diagrams.
Being lazy when developing larger IT system
Another example where IT developers are in generally not lazy enough is in the area of managing execution of a number of tasks. Yes, I know that many IT shops use cron or write scripts to execute a number of sequential tasks. But what happens when more than one chain of tasks must be executed, or when the chain is not a simple chain but a DAG of tasks? This type of execution is usually described as a business process.
The problem here is that most IT shops do not lay down the fundamental ground work for implementing business processes and as a consequence end up with hundreds or thousands of scripts, each executing their own business process. Sometimes even worse, they go out and buy an expensive business process engine framework (usually based on BPMN/BPEL which in 98% of the cases is a complete overkill) requiring employess to take courses to make it perform even the most rudimentary operations.
To be fair I don't lay the entire blame on IT developers. The blame should to a large extent be laid on IT managers. Most often, managers don't understand the virtue of being strategically lazy.
Being lazy when monitoring IT systems
Monitoring of IT systems usually do not add much functional value to a system. As most developers know, not having automatic monitoring of an IT system can be frustrating and result in having to do repetitious tasks like greping log files every so often.
The lazy approach to functional monitoring is of course to inject probes at various points in the system where information is logged in some structured storage like a database. Ones the information generation machinery is in place it is simple to write tools that runs checks and produces reports on the structured information.
The idea of logging structured information which is programmatically accessible makes it simple to generate a large number of projections showing how the system behaves. And by the way, it is nothing revolutionary. There is no reason to settle for unstructured log files from which it is excruciating difficult to understand the behavior of the system as a whole. Again, the key is to have the ability to generate projections from structured data in order to understand the behavior of a system better.
Sounds obvious, doesn't it? But again, I have seen many IT shops where developers, functional analysts etc. spend an hour or so every morning checking for potential problems in log files. Again, the solution is to be strategically lazy and apply IT knowledge to our own work.
Conclusion
Being strategically lazy is important in almost any area. However, IT by its very nature is in a very special position since it is in the business of automation. Because of the inherit knowledge of automation within IT shops together with the knowledge of IT I believe it is important that both developers as well as managers explicitly acknowledge laziness as a tool for being productive. Being lazy does not necessarily mean that you are productive - but not being lazy certainly means that you are not productive in an efficient way.
By the way,C++ meta programming comes across as an excellent path towards Strategical Laziness!
No comments:
Post a Comment