Automating tedious tasks

I've just added a new byline to my blog: automating tedious tasks.

A complaint often levelled at Software Factories is that it will turn developers into automatons, just pushing buttons to drive the factory to do all the clever stuff. I think the exact opposite is the case. The point of technologies, such as DSLs, which we're building to support the Software Factory vision, is that they are focused on removing those tedious and boring tasks, thereby releasing the developer to focus on the creative and interesting parts.

For example, you can write some code by hand which uses the same label in a number of places, as part of a property name, part of a class name, to identify a database, in the title of a web page, and so on, and then every time that term changes (which it will) you have to go and make the change by hand in all those places. Wouldn't it be better if we had tools which allowed you to identify that the particular label was used in a number of places, and then propagated the change to the label in all the places it's used whenever you need to change it? Then, instead of looking at an hour or more spent laboriously working through the code changing all uses of the label, you can do that in a couple of seconds and spend those hours trying to work out that tricky algorithm you've been stuck on. 

DSL Tools supports something like this. We're lowering the bar to defining small domain specific languages from which code can be generated. So the label referred to above will be captured in one place, in an expression of the DSL, and change to that label will be propagated to all the places it's used by the code generators. Now, in DSL Tools at present, code generation is fairly crude (but still useful). You can generate complete text files - as many as you like. This does mean that if you need to write custom, hand-code to finish off the generated code, you need to put it in separate files. With the partial class facility of C#, this is not so restricting as it might seem (assuming you're coding in C#, that is). I fully expect developers writing and adapating the code generators, as much as I expect them to be writing the custom code in the carefully worked out plug points. Our challenge, as vendors of a tooling platform, is to enable this way of working at a finer level of granularity and with an even lower bar to entry.

Comments (1)

  1. I agree the height of the bar to entry will determine whether DSLs are successful or not. If I have to learn a new system and set a DSL up, this will take a certain amount of time, and it’s a risk as I can’t be certain DSLs will be suitable for me and there will ever be a return on this. Ultimately, it should save time, but most people like to be able to show that they have done something that will have an immediate benefit, rather than say they have done something that might bring future benefits.

    As the time to learn and set DSLs up becomes shorter, the risk is reduced. I hope this can be made shorter as I’d like to be able to automate many of the routine things I do, and think of projects at a higher level.

Skip to main content