Sunday, 23 June 2013

Programmer or Analyst Developer?

I know these terms to mean different things in different countries or even different organisations so I'll explain.

  • 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..

  1. Never let a programmer talk to a customer. 
  2. Who produces the documentation? 
  3. But the BA's know the customer!
Then I started to realise two things..
  1. I'd been an analyst developer myself and I'd seen it work extremely well with the right people.
  2. 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.


  1. When working as teams, the SCRUM method gives a good potential answer to the issue you are addressing in your post.

    When working "as a team", a SCRUM developer is always an Analyst Developer from its output: the analysis and decisions are taken "as a team", and everyone benefit from others input.

    Everyday, I work in a SCRUM team with others, and it is now natural to collaborate and help each other with one goal: finish the sprint as expected, to fulfill our customers expectations. SCRUM leverages individuals to work as a team. Programmers learn how to analyse, and Analyst Developer do better analysis by being part of a team, focused on customer needs.

  2. Hi Arnaud. Not so. It's not the fact that it's Scrum, it's the way a team works. For example I'm a certified ScrumMaster and have been working with scrum teams for the past few years and there has always been a BA involved. Yes, the developers work closely with the BA, but that can happen with Iterative and Incremental and even with XP, FDD or any of the plethora of other methodologies - but the BA is not the customer. If on the other hand, you are saying that your team works directly with the customer and your Analyst Developers then gain their understanding of the requirement directly from them rather than a BA or a document, then yes, you are operating as an Analyst Developer.

    your comment that the teams works well together is excellent and I have seen that with others as well. The one I referred to in my post was a full Scrum environment and the amount of throughput was extremely impressive - however that did not make them Analyst Developers as described in the post.

  3. The Scrum is about getting things done accompanied by 'never' touching a requirement twice. This is the essence. Scrum is about estimating and planning. Solid estimating even requires a solid underlying. However you setup the underlying. A wide range from infrastructure, technology, frameworks, creativity, skills ...

    What you talked about, is what we call in Europe 'An American idea' little flowery something between very optimistic and naive. MBA - take the best people for the right job and succeed if you combine those into a team - work is done successfully, otherwise we would not have hired the people.

    Everyone estimates correctly over within weeks or months and everything works fine accordant to budgets. The Scrum arrived in Europe already at a point in time when people started to strongly focus on the artifacts. The Scrum arrived as 'nazi' scrum already - optimizing the teams performances by optimizing burn down charts for example.

    If the focus is on the money the user doesn't count. The users requirements flap away on chicken wings if you don't get them early and almost complete in the product back log. That's counterproductive. In a business software project. Chinese whispers. If you have what you described the domain expertise and technological skills combined then you weaken the role of product backlog and put more responsibility into Sprint Backlog. That's customizing.

    I allowed me to extend you graphic. It's about success and the user view and benefit.

    A project success is not equal to it's benefit.

    Success starts a lot earlier than most people think, but the benefit to the users or business processes starts a lot later than most people would assume. The European definition of success is what Americans call the path to excellence.

  4. AnonymousJune 24, 2013

    I rather don't see an army of analysts, because in general they think up alot of ways to annoy the customers/developers, because they think that what they say is how it should be ...

    Anyway I have worked with alot of different type of methods already. And like you said, the ones where we didn't have any analysts or just 1 turned out to be the most succesfull

    Now complex systesm you need to think about, but honestly get your team together, think about it, let it rest, do some more thinking about it, and you will have a solid/scalable system

  5. AnonymousJune 24, 2013

    Projects run and run. Managers enforcing their authority, scrum masters justifying their position, meetings, requirement docs, specification docs, minutes, prototypes built and rejected: Man-hours getting burnt through, more management is introduced...

    When budgets and time run out, the layers of bosses flee in panic and finally the programmer is permitted to speak freely and directly to the person on the customer's side that is to use the product.

    The programmer then works day and night with the user, often moving on-site to the customer. Unhindered by bureaucracy, the programmer at last can learn the business case in all it's detail, not through the filter of layers of management and half-understood requirements, but directly from the user. This perfect communication achieves in weeks what could not be done in months, even years. When the product is completed the user communicates this up the line at the customer's side.

    The managers then reappear and the exhausted programmer watches as each fights to claim credit, explaining why it was their model, their architecture, their methodology that lead to the eventual success, and if only their ideas had been heeded in the first place...

    Then there may be an end-of-project party thrown by management and the customer. The programmer (and usually also the user) are not invited for fear the customer, or top management, may ask questions to which the programmer has to lie or reveal uncomfortable details.

    I have been in this game for decades. In my experience, all projects either follow the lines described above, or continued to run until the finance dept. finally pulls the plug.

    The person(s) doing the programming MUST communicate with the person(s) using it.

    1. Fully agree. That's why the 3-4 XP programmers could beat the team of 40. As a disclaimer it does however required the "Analyst Developer" to be of above average intelligence, quick to get things.

  6. When Project begins a lot of work is started, trying to understand the requirements and delivery timeframes. If the project turns out to be too expensive or unnecessary then all of the work is wasted. Scrum helps teams to deliver better software with faster process. Scrum is so popular that over 30% of companies claim to be using it. Software development team can get their software in front of real people and take their feedback to ongoing development. As a result there is less need to predict user needs and the outcome is software which has a better fit to the real user needs.

  7. Wow that was unusual. I just wrote an very long comment but after I clicked submit my comment didn't appear. Grrrr... well I'm not writing all that over again. Anyway, just wanted to say great blog!!!!
    software development indore

  8. Hi Ella. Because of the "very" high number of spams I get I moderate all comments so they never will appear immediately anyway - however your comment never did get to me and there is no sign of it in my list. Pity, I would have enjoyed reading what you wrote.
    Thanks for the nice words, I get some great readers too :)

    I think there may be something wrong on Blogger as it took me 3 tries to type this reply :( I hope they fix that soon.

  9. In my opinion, if the team is working on a project (the developer and analyst) with customers to meet both of these men. Because the client side should be happy with all the work the team, and to be aware of them. I work in most of the analyst on the project custom application development and I know this from experience. The client will be happy to hear new ideas, can learn more about the work on his projects. So you need to create the most favorable terms for the client. Because it is not only his money, but also our.

  10. Hi friend
    Really great information and nice post

    I like it

  11. If a work done by a team efforts then, it always successful. a programmer need supports and proper requirements about the task which he done.
    software development company

  12. I completely agree with your division concepts. I have personally been working developer software development company and I know that people like us do not need to talk to the customers, because we can see the work from a very different side than analyst.

  13. fully agree .
    Anyway, just wanted to say great blog!!!!
    Symantec Norton Antivirus Software Download

  14. Steve's it is very nice to getting something new about software development and i found very interesting things to read here.Keep posting such nice posts.
    Software Development Company

  15. Hi, Its very good to know the informations of analyst developer and its uses.

  16. Its good to know that people believe that developer analysts could perform this task more efficiently. I also support that a developer should interact with customers and he should also learn the BA's responsibilities to perform this task better. It would just decrease the gap between client and developer and make things go more smoothly and faster.

  17. I´m currently a small team Analyst Developer, and we´re outprogramming pretty much everything I´ve seen.

    The final product is just as good as the number of iteractions between the programmer and the final user.

    When you´re working with methodologies where requirements are not touchable twice, you´ll get very few iteration between the final user and the product, and therefore, It will be only as good as the initial specification.

    Maximum sucess and benefits can be providade by a clean team, using the best tools and adding a little bit of Desing Thinking concepts.

    Also, those who can do well with powerful FrontEnd+BackEnd frameworks (have seen few people so far, including me) can implement their own set of bussiness reusable classes to achieve maximum code reusability.

  18. Really nice, fully agree.

    I appreciate this. Keep the good work!

  19. Excellent blog post. I think you only can get benefits by using proper tools, and with good team members

  20. nice informative post... fully agreed... thanks for sharing

  21. Great... Nice Post. Really i enjoyed to read this post. Keep it Up!!

  22. business analyst certification

    One can clearly see that the field of Business Analysis is a strong emerging field that would be highly sought after by most of the entrepreneurial organizations in the years to come. And hence, it would be a very good investment of time and money into becoming a certified business analysis professional as this would allow one to become indispensable in today’s tough and rapidly changing market scenarios.

  23. Hi, thank you for this article. It's excellent and very insightful. I am now working as a .NET Developer, but I'm planning to go into analysis more. Also, I'm quite interested in Project Management and erp system
    development. I wonder whether there is a vacancy which would put all of these areas together.


Note: only a member of this blog may post a comment.