Analyst v developer

An analyst is just a developer who can’t code in the chosen implementation technology.


the reason I bring this up is:

We are always told we have to use tortuous programming languages because English (or your choice of normal language) is too imprecise. Our ability to code in higher and higher language is developing slowly as people write layer upon layer to translate our higher language to computer meaningful stuff.

But if an analyst is writing specs that someone is going to code in this precise programming language, how come they can get away with using an imprecise language? How does the coder move from vague to precise? (hint: personally I go and ask the customer, but that’s just me). Don’t say CASE tool, unless you genuinely, regularly use one, in which case, which? why? strengths? weaknesses?

I’m only asking because this analyst thing came up in conversation recently, and for business systems development in higher level languages* I think this role separation is ridiculous. Sure plenty of people don’t have the full set of business and technical skills to cover both roles. IMO those people should be developed where possible to enable them to cover the full lifecycle. Not compartmentalised and forced to communicate via the 2 cans and a string that is specs written in Word.

[* by higher level languages, I’m thinking of the stuff business systems are generally built with, thats most of the stuff we discuss here, C++ I’m willing to concede may be out of reach for some business analysts, but I don’t think SQL or C# should be].

I think the analyst being a separate person from the dev is pretty unusual in Excel/VBA. Have you seen it? I’ve worked from specs before rather than users, its crap, and you always end up going to sit with the users anyway. WOT. (hint)

Do you think it would work? Does it make sense to split the roles?



11 Responses to “Analyst v developer”

  1. Andy Cotgreave Says:

    Great point, Simon. I’m seeing a change where I work in the right direction. I’m in the business end of the institution, and increasingly, we are doing the analysis, specification and development using the tools we have (Excel, Tableau, SQL connections to our data warehouse). As a result, we are relying less on our IT Infrastructure section. End result? We talk to users, we prototype with users, they get what they want.

    It’s created lots of politicial friction though, as the IT sections feel increasingly disenfranchised. But then, most systems they implemented didn’t go down too well with the user base….

  2. Andy Cotgreave Says:

    PS – our team haven’t written a user specification for a long time. Instead, we develop a prototype in conjunction with the user. This “picture” is infinitely more effective than a 20-page specification document.

  3. Andy Wall Says:

    I have recently moved into this dual type of role (my first contract) and, having experience of both the trad analyst and dev functions, I’d have to say the combined function is the way forward. Prototyping and a ‘release early, release often’ mindset seems to get the customer what they need in the best fashion, which is completely alien to most IT departments.

  4. ross Says:

    >>An analyst is just a developer who can’t code in the chosen implementation technology.

    No. Don’t agree.

    Do agree that most specs are not very good.

    However, this does not mean I think devs should go straight to the business and start writing code.

    Specs may be a very poor way to develop applications but that because it’s very hard to write good software. There are many draw backs to not having specs, and analysis, in some case. What happens when the user changes their mind after the prototype has been made into production, how do you cost such things, who can check the scope, and the spec – might you build 3 things when 1 could do? what happens when the app does not do what’s needed, who’s fault is it? What happens when the developer forgets something, what documentation can be used to prove whos in the right.

    For sure spec suck, but they do have there usages, especially if its contacted out development type stuff. in house has more flexibility.

    Also don’t underestimate just how bad a lot of developer are at talking to other humans. Developer, especially ones outside of office development, often live if a closeted world, not understanding businesses demands or the realities of the “real world” – sure thats a really sweeping statement, but I do see it, A LOT!

    I think the real issue is, that we (all, business and dev) are really bad at specs, and it’s very hard to be a great Analyst, there just to many places where it can go wrong.

    I don’t think devs need better business skill,s I think the business needs to better understand IT development process. The reason why this has not happen is because developers and software house are very bad at pushing back…

    Just my 2 cents anyway!!

  5. Biggus Dickus Says:

    “Do you think it would work? Does it make sense to split the roles?”

    Absolutley not !! We (and our clients) are lucky that we can be both in our apps and it’s just lucky that our apps are not so big and complex (mostly) that yu have to split the team into Analysts and Devs.


  6. Harlan Grove Says:

    Depends on what the nature of the application may be. There are math and physics PhDs (at least around by age) who can’t program but who can be exactingly precise in specifying a series of calculations.

    Another possibility is that analysts have some specific knowledge and understanding of the business/industry which coders lack. Such analysts could express (possibly ambiguously) business rules which coders couldn’t. Unfortunately, not all analysts have such backgrounds.

    In my own personal experience, analysts usually struck me as overpaid overhead.

  7. BGone Says:

    ross raises an unfortunate reality of modern, litigious society. You “need” a papertrail so someone can be blamed at the end of the day. So – if paper is viewed as a requirement – the company can actually be more efficient when an analyst with more practice in setting up meetings and assembling paperwork handles that part, while a developer handles the code.

  8. Simon Says:

    All good points Ross
    I think that specs are hard because it is utterly unrealistic to expect someone to specify what they want, without seeing how some parts of it might fit together.
    And further it is close to impossible to validate that all parts of a spec do not conflict without coming very close to writing the app.
    I totally agree on the interpersonal skills of some devs, but generally I would have thought it in the orgs interests to help them develop, not shut them in a dark room and feed them bullshit.
    Harlan I agree on the specific business knowledge.
    BGone, too true, but isn’t that the tail wagging the dog? (not saying it doesn’t happen – just the opposite, that is exactly what happens, but it a bit crap IMO)

  9. Charles Williams Says:

    I think it very much depends on the scale of the project.
    The projects I work tend to be small-scale (typically less than 2 man-months). So we try to iteratively evolve towards a prioritised agreed high-level design where both sides think they understand what is going to be developed.
    Then we try to deliver prototypes in stages for testing and feedback.
    For large-scale projects (man years) I am impressed by the MSoft fusion of developers and planners.
    The real problem comes with medium-scale projects: fortunately I don’t want to do those!

  10. sam Says:

    Specs dont work unless its a small project eg – some engineering calculation for Earhing design.

    Typically if it is a data entry UI/analysis/reports kind of stuff…It best discussed face to face with the end user followed by Beta 1.0, 2.0 and 3.0 before you deliver ver 1.0

  11. Dimitri Says:

    I had something to do with a fairly large project where specs were a Word document with many pages of unstructured text narrating what the system should do. I remember a period in the project where customer and vendor were engaged in as series of passionate debates on the meaning of this or that passage from the specs document.
    I recently came across an article in a legal journal describing a case where a contract had the word “punctual” in it and the whole case depended on that word. The High Court took 3 days debating the meaning of the word and how it should be interpreted.
    A while ago I read an article about a successful IT project. The article went through the ingredients of success, one of which was the insistence on using UML for communications between devs and users.
    My personal opinion is that English, or any other natural human language, was not designed and is not suitable for communicating precise technical specs well. It is just too ambiguous.
    Combining dev and biz skills in one person may not be practical for obvious reasons. Maybe the trick is to use some kind of communication system (UML, good CASE tool, something else?) that will be understood by both and will be precise enough to do the job?
    I recently witnessed a failed attempt to use a CASE tool because it was assumed that anybody can use it and can interpret it’s output without any extra education. It is a language, and need to be learned for it to work.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: