modeling, technologies and culture
Looking back at yesterdays Dresden Eclipse Indigo demo camp, I ended up with a couple of thoughts in my mind, both related to the technologies demonstrated there, and related to how to make meaningful use of them in a real-world environment. Overally, this demo camp event mainly was dominated by topics related to modeling tools and concepts on top of Eclipse technology – hardly a surprise knowing that itemis, the company behind tools such as XText, also appeared as main sponsor and organizer of this evening. Consequently, XText also appeared on the agenda in its latest EMFText and how to easily build (or, better, “have around”) an Eclipse integrated debugger for EMFText based domain specific languages at no additional costs. Running a DSL interpreter and doing debugging just the way you’d do it in Java code surely is an interesting experience. Not even talking all too much about ProR integrated with XText for the purpose of capturing requirements in a somewhat formal way. In some situations, this is just what you want or need, and problems to eventually be solved by using these tools are obvious almost immediately…
And yet, it seems that sometimes knowing it’s a good tool ain’t obviously enough. Once in a while, I have been reading articles and tutorials related to new technology, be that in NetBeans, Glassfish, Eclipse or elsewhere, and most of them, same as these presentations yesterday, are likely to reach their aim: They do leave one interested, curious, ready and willing to deal with things more in-depth.
In some cases, dealing with a technology for a couple of days is enough to make you give up on it because you see it won’t get you anywhere, and in other situations, you’ll add a precious and powerful new solution to your ever-growing toolbox and leave it there, waiting for you to need it and make use of it. From a technical point of view, as soon as you dealt with it for a sufficient amount of time, you will have a clear idea what it is capable of doing, even if you don’t immediately master all of its capabilities to their full extent. The tool itself will become familiar. Which is good. So now for the next problem: Technically adopting the tool, which, in some situations, seems more difficult than others. If you earn a living off doing developer training and education and working in customer projects, maybe some of them even being greenfield with you to decide how to (not) do things, you’re likely to have a good time making the most out of your newly gained knowledge. Unfortunately, in reality things hardly are as good as this. Being a real-world consultant you are eventually supposed to deal with legacy systems, with old code bases and business logic locked up into “information silos” unaccessible either to other processes or other software systems. Or, to push this even further, maybe you’re an in-house developer working with a given software system all day, where you know what you see is what you got and you can either improve it, trash it and start all anew or leave it alone and start on your own elsewhere. If you’ve been into it for quite a while, neither of these solutions ain’t really promising, not even “trashing everything”, as Robert C. Martin illustrates in ‘Clean Code: A Handbook of Agile Software Craftsmanship’, talking about the “Grand Redesign in the sky”. So, in the end, it will be all about slowly, and as good as somewhat possible, rebuilding, refactoring the guts out of your system, hopefully this way not breaking everything beyond repair. It is a challenging process, at times, and might involve quite a bunch of temporary and rude solutions to make it even work technically, but in the end, it’s something, and in the end you might get all your existing and all your new tools somehow merged in a meaningful and even working way.
Which, by then, might leave you end up with the third, and, as it seems to me, the most solid of these problems. Culture, and culture change that comes all along with tools. Yes, I think and firmly believe that the availability of tools does change culture in all areas of software development from requirements engineering to implementation and maintaineance. It might come with some paradigms required to shift, in order to work effectively.
As a simple example, there’s the conception of shifting from a proprietary, locked-up, vendor dependent environment to an open, “ecosystem” based development and runtime “community” like Eclipse. If you or your colleagues spent a sufficient amount of years working in a proprietary, locked up environment, they eventually got used to doing most if not all the work on their own simply because there is no “outside world” to ask for help, maybe there’s not even meaningful or economically acceptable support to get from the original vendor of the system. And yet, business had to move on, so everyone got used to figuring out workarounds to “get it to work”, no matter how good or bad. Everyone got used to working within a small, well-defined environment with little choice. Everyone got used to knowing that implementing business features takes rather long, because a lot of time always has to be spent on dealing with the platform, “old” workarounds introduced before and new workarounds to be introduced now in order to make it work at all. Now, this all does change when moving out of this into a Java / Java EE / Eclipse world. All of a sudden, the environment ain’t limited or well-defined anymore. Where before one had to deal with limitations and workarounds, all of a sudden developers are forced to get acquainted to knowing that the concept of choice gets important now. People need to get used to knowing there are dozens and dozens of frameworks, tools, technologies out there, they need to learn how to easily and meaningfully navigate this whole world of choices, how to make smart “make-it-or-buy/use-it” decisions. They need to learn how to pick from a huge toolbox and build a working solution by putting things together. If you grew right into Java and the Java ecosystem, eventually you slowly learnt to get used to this, but if you got used to writing business logic and boilerplate code in a locked-up proprietary platform, I believe this to be quite a paradigm shift.
This paradigm shift also includes any other (internal, external) stakeholders as soon as it is likely to change the way your development works. If by now most of your development process was about quickly writing code, things get different if you all of a sudden start working on top of some DSL approach, knowing that writing code still is essential but way less than it used to be before. If you got used to finding a small, cozy place where to add your new logic to the existing hunk of code, the approach of actually defining some sort of model initially and, while adding new features, modifying the model first might seem academic and quite away from any real use to you – even more if this is even slightly likely to involve more work than your initial process of development (because modeling, writing test cases, … doesn’t immediately end up in code which can be used in production).
So, overally, what’s the bottom line? Well, from my point of view, technological hazards to adoptions of a new technology are easy to overcome as they are “just” about smart use of technology. Aspects of development culture and communication, however, might be way more difficult to address. Maybe continuous training and qualification can make such things better as it might pull all the girls and guys in your development process to the same level so you can be somehow sure they all do share some common knowledge and language as far as these technologies in question are concerned. Maybe it takes a smart project management with good communication skills to motivate and involve everyone into what is intended to be here to still be productive and working tomorrow. Maybe it’s simply about time and accepting that something that grew in a decade or more is not likely to be changed within a few months. Maybe it’s about quickly building good prototypes and demo applications to prove these “new” solutions and concepts get you quite somewhere once you got started, and not hesitating in trying to get people into your boat if you can’t simply tell them what to do.
But maybe at some point it also is about considering where to spend your energy and enthusiasm. Maybe once in a while it’s also about reviewing how much change you managed to make so far, how much you did manage to push things forth, how much you got ahead with what you intended to do, how much likely it is to be any more successful in this as soon as “culture” is not just an aspect of techno-cultural adherence to existing methods and tools but possibly a result of strategic and political decisions beyond your influence. I am not sure how successful a project ever can be if this does get into your way.