Programmer or Analyst Developer?
I know these terms to mean different things in different countries or even different organisations so I'll explain.
I had an interesting talk the other day with a Software Development Manager who was looking at the whole idea of the Business Analyst that so prevails our thinking around software development. A number of years ago there was a push never to allow the programmers to talk to the users. The huge push for Business Analysts was on and the Analyst Developer idea disappeared from our vocabulary.
What this person was suggesting was to reintroduce that idea. He recognised that not every programmer was an analyst developer and there was still room for the programmer in the teams, but that instead of having a number of business analyst producing streams of paper and diagrams, this function was sometimes better produced by an analyst developer.
I admit that my first reaction was several thoughts running through my head that followed through and interesting turn..
- A Programmer is a person who is given a task and codes that task as it is described. Usually this task is described by a Business Analyst in the form of a Requirements Document or a User Story.
- An Analyst Developer will speak to the users to help define what their need is, then code that need.
I had an interesting talk the other day with a Software Development Manager who was looking at the whole idea of the Business Analyst that so prevails our thinking around software development. A number of years ago there was a push never to allow the programmers to talk to the users. The huge push for Business Analysts was on and the Analyst Developer idea disappeared from our vocabulary.
What this person was suggesting was to reintroduce that idea. He recognised that not every programmer was an analyst developer and there was still room for the programmer in the teams, but that instead of having a number of business analyst producing streams of paper and diagrams, this function was sometimes better produced by an analyst developer.
I admit that my first reaction was several thoughts running through my head that followed through and interesting turn..
- Never let a programmer talk to a customer.
- Who produces the documentation?
- But the BA's know the customer!
Then I started to realise two things..
- I'd been an analyst developer myself and I'd seen it work extremely well with the right people.
- I'd seen over BA'd applications that, while they did everything, did not produce a good program.
As far as point #2 is concerned yes, a good lead developer or applications architect can resolve some of these issues but they may not necessarily be in the right space.
I left that conversation wondering if its time for corporates and government departments to again look at the idea of the Analyst Developer for larger teams and programs of work.
I've spoken previously about having once worked in an XP environment where 3-4 analyst developers were able to totally outprogram a large team of over 40 developers by producing a fairly substantial and comparable ERP system in a matter of 3-4 months compared to more than 18 months for the larger team. In the smaller team there were no business analysts; we weren't working to a list of predefined requirements; and we didn't rely on a single person or group of people to define those requirements. In this case, we simply got up out of our chairs and spoke directly to the customer to understand what it was they wanted to do, then knowing how the whole application was forming, we focused on the best and most efficient way of delivering to what the customer wanted.
In a recent large development environment, we had as many business analysts as we did programmers. the documentation was delivered at a high rate and standard to the programmers to code. They coded what was asked for and delivered impressively to the amount of requirements - but the application, while delivering what was required, was not a good application. Not that it had many bugs; it just wasn't a nice program to use and the documentation was not there either as they related to releases and requirements not to the application.
This is getting hard to explain, but this person that I was talking to then produced something I've seen many times before - he drew an axis diagram to where an application would sit comparing "does the right thing" to "doing things right". Where does your dot lie? The focus is to try to move your application towards the top right of the graph.
When you are head down delivering documentation or code without consideration to both, you produce only what is asked for. This recent environment which had many business analysts were certainly producing the right things, but the thing was not done right - I'll stick my head in the air exposing my neck on this one, but I'd dare to suggest that the application was horrible. Everyone there did extremely well in producing what they were required impressively and while it produced everything, it just didn't produce an overall nice application. In this instance, I'd suggest that the dot on the above chart would be somewhere to the top left.
Typically small or one-man teams already work as an Analyst Developer, but even then, not always. I guess it depends on whether the person is a programmer or analyst and both are good.
Now I'm not saying that there are no longer Analyst Developers anywhere, I'm sure there are numerous - just not in the larger corporate or government teams that I have seen. I'm also not saying there aren't downsides to this thinking, but I am saying it's worth consideration and watching what this manager does with immense interest.
Your thoughts? Perhaps you are currently working as an Analyst Developer in a large team and would like to tell us how this is working for you.