The distinction between requirements and technical work

Let me tell you a little story from my current assignment.  I have a gig as a developer in a project.  A few days ago I was about to start on a new piece of functionality that nobody had thought much about beforehand.  There were no requirements and only vague ideas of what the functionality was good for.  Given that I have much experience in working with requirements I thought that I was certainly capable of finding out the requirements myself and this would be a much faster way to do things than to wait for an analyst to show up.  So, I started asking questions, trying to get further down in the details of what this new functionality should do, why it should do it and how it should be done.

I have been in that situation many times before.  This time, just as practically all other times, the response from the people around me was not positive.  Instead it was along the lines of “what, you are a technical person; you should not do that work; that is for analysts to do…”

Why is that?  Why have most organizations put in a very high wall between requirements people (analysts, business people) and technical people (architects, developers)?  Why are people so afraid to “break” this boundary?  My latest employer even had distinct lines of organization for analysts and architects and it was very odd to be somebody like me (who is somewhat of a mix between analyst and architect/developer).  Also, since many organizations have this wall in place, there tends to be a focus on some kind of formal handoff from requirements to development.

To me it is obvious that there are great benefits of working on both sides of this distinction simultaneously.  Requirements without the understanding of what really can be done and what is easy and hard in the current environment tend to focus on the wrong things and not reaping the benefits that the technical environment gives you.  Architecture/development without the understanding of what is really needed and why tends to build great technical solutions that few people want.

Ruby on Rails

Lately I have been playing around with Ruby on Rails, mostly to learn a new technology and also to be inspired on what more modern development environments have to offer.

My main source of information is the excellent Ruby on Rails Tutorial by Michael Hartl, who incidentally have made some interesting work on why Pi is wrong, but that’s another topic.

Anyway, these are my reflections on Ruby on Rails…

My first thought is that Ruby on Rails is an example of where we have come quite far with standardized architectures for a domain that is somewhat large, but nevertheless specific.  Over the years there have been many attempts of creating a standardized environment for a specific type of system where the intention has been that developers should only focus on functionality and design, whereas the more technical and architectural issues are left to implementers of some sort of framework.  My latest post was about model-driven-development and this is one (or actually several) example of this kind of idea.  But mostly these attempts have fallen short in one of two ways.  Either the framework is not detailed enough so that any real applications cannot be created without significant framework tweaking/development which defeats the purpose.  Or the framework has been too specific which makes the sweet-spot for applications developed by it very small and therefore few systems benefit from it.  Of course one could argue that Ruby on Rails is an example of a very specific framework for a specific type of system, but that specific type of system (OLTP systems on the web) is indeed quite large in terms of number of applications currently being developed.

Secondly, Ruby on Rails have many variations on how specific things are done.  I guess that this is more a feature of the language Ruby more than the framework Rails.  This is both good and bad.  It is good because it allows for flexibility in development and also allows for a much larger focus on the readability of code.  But it is also bad because it makes the environment hard to understand for beginners.  If two things that look different are actually examples of how the same problem is solved, this could be quite hard to see and this makes the learning-curve steeper.

Third, on a more personal level, I have not quite yet gotten used to using a non-typed language such as Ruby.  Sometimes the old Java-developer in me have a hard time seeing the things that can, and should, be done by using the type-system more creatively.

Why is it so hard to sell the idea of model-driven-development (MDD)

Last night I was listening to a colleague who talked about his experience of using a model-driven-development (MDD) approach to develop information systems to support business processes.  The tooling and approach that he talked about comes from the Swedish company Capable Objects.

I am a bit indecisive of what I should think about what he talked about…

On positive side, I am fully convinced about the merits of MDD in terms of speeding up development, producing more consistent and higher quality systems.  After all: I have spent 9 years at Rational Software and much of that time I was advocating modeling and MDD to a lot of people and organizations.

On the negative side, however, this is something the industry has been talking about for years.  As mentioned above, I too was one of those people talking about it.  But the results of all this talk are very poor.  There are certainly examples of successful MDD usage for specific domains at specific organizations, but the larger-scale usage that everybody was dreaming about 10 years ago has not materialized.  Why is that?  Why has this been such a hard sell?  Why has the industry not embraced MDD?

My theory for the reasons is divided into a few parts

First, the agile movement of the past years has put less emphasis on modeling in favor of doing coding directly.  But proponents of MDD could really use the agile movement to their benefit, since agility puts a great emphasis on development velocity, which is something that MDD should provide.  But this has not really happened…

Second, the available tooling for MDD has not been (at least historically) very good.  Either it has been too simple, which does not give to the level of detail needed to tweak and configure the finished system in an appropriate manner.  Or it has been too complex which makes the transition to MDD too hard and which also requires significant consulting efforts implementing it, which means that the adoption of MDD moves very slowly.  Also, MDD means that much work is required to produce the transformation mechanisms where models are transformed (perhaps in several steps) into executable systems, and this work is only relevant for a rather specific type of systems, which means that this work needs to be repeated across system types.

Third, there has been a significant pushback from the developer community.  Perhaps this pushback has at least some of its roots in the fear from developers of loosing their jobs when the level of abstraction is raised.  Proponents of MDD usually talk along the lines that MDD is so simple that the business people can do the development themselves, which of course scares the developers.  Personally, I do not believe that line of reasoning.  Business people usually have a hard time understanding models so we would still need some type of developer to produce the models.

Going back to banking

The ink was barely dry from my last post, which I wrote yesterday when I got a new assigment and I am going back to banking.

I will do some development of liquidity risk management solutions for a major Swedish bank.  It will be interesting to go back closer to the technology and code once again.  Lately I have mostly been a producer of documents:-)

What’s up with banking people

Over the years I have worked with software development in a number of industries including e.g. telco, defense, law enforcement, real estate, airlines etc. In most of those industries the software and/or IT people are mainly just that, i.e software/IT people. Also, the people in those industries usually approach the idea of other businesses as something they may certainly work in (although perhaps they never do)

But in my experience one industry stands out: Banking. A lot of the people working there cannot envision working in another industry, even if they “only” do software/IT (something not directlyrelated to the business itself). Furthermore, to get a consulting gig in the Banking business it is much more important with industry experience than in many other industries.

Why is that? Why is the banking industry so much more constrained to its own industry?

Perhaps you could argue that software/IT in the banking business requires a deeper domain knowledge than in other industries, but I do not buy that. Other industries certainly have as many peculiar ways of doing things, as much business lingo and as much dependence on odd processes as banking does. So it must be something else, but what?


Hi there and welcome to my blog.

This blog will focus on my work in the software development business and my interests there: agile development, architecture, new and interesting technologies, trends in the larger business etc. etc.