Are Business Analysts Ready to Become Programmers?

by James Vastbinder on May 23, 2008 |

At the beginning it was not exactly clear what was being developed. A veiled reference to “Emacs.NET" fueled speculation of an Emacs clone or even a derivative of Lisp. The veiled reference worked and many were confused. Doug Purdy threw out the first clues in this posting:

You may know some folks on my team from either PDC/TechEd, their books, or their standards work: Don, Chris, Clemens, Chris, Gudge (update your blog), Mr. Schlimmer, and many others...

I can't tell you what we are doing exactly (although if you search around enough, you can read between the lines), but I can tell you that we are hiring.

Doug then continues to provide a general description of the types of developers they would like to hire to round out their team. Don Box follows up with a quick public blurb talking about the development team’s methodology:

….we're a relatively small team ( O(15) ) and run the team on the 1 month milestone/continuous integtration/TDD plan and have no traditional PMs, SDEs, or SDE/Ts. Rather, everyone checks in code, writes tests, and writes docs.

Followed by an evening post on the same day, Nov 14, 2007, from Chris Anderson:

We have to be a little vague on what we are working on, but I can say that I'm having a lot of fun...

Then the team went into quiet mode until recently and Doug posted again. This time providing more information and links to actual job descriptions from which can be gleaned more information.

From the recently posted job description they clearly have created a new language and are looking to build a new sub-team that will own the IDE experience:

provide an approachable editing experience for the newly developed language…. It consumes the extensible VS Editor component and the new Managed Extensibility Framework (MEF) Component Model.

Which falls in line with information announced previously from several news outlets using anonymous sources in the February ‘08 timeframe. They reported that the Connected Services Division was working on a new XAML based language with the codename, “D”.

When aligned with the Oslo initiative to create a modeling platform targeted at bridging the gap between the IT professional and business analyst, all the pieces begin to fall into place. Once one puts the early referred to Emacs metaphors aside.

Are business analysts really ready for model driven development and learning a programming language? As the technology world moves to cloud computing and technical barriers for programming are removed by initiatives like Oslo, will marketing managers and business analysts really become programmers?

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

APM Survival Guide from a Veteran Performance Geek

A Unified Mobile Architecture for the Modern Data Center

Enterprise-class API Patterns for Cloud & Mobile

Agile Executive Primer: Partnering Across the Organization

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Re: Not such a new idea. by James Vastbinder

NP - it reminded me of an item that I left out in the article on which I'm not clear. It appears the team is looking to provide more of a textual representation of information in their designer, but maybe I'm reading the clues the wrong way...

D already exists by Lou Marco

There already exists a programming language called D.

And it's not too shabby, if you like the curly brace language style.

And now, back to real life... by Jim Leonardo

I'm all for simpler programming languages. It's a constant cycle though. You start out with a new language that "does one thing well". It becomes popular, but people pack more and more into it until it "does everything poorly". Look at the evoltion of VB, especially from 4 onward. We need that new one once in a while to pull all the complexity together so we can move on to bigger and better things.

However, I challenge the assumption that you can make analysts into programmers. Why? It's not that analysts can't be programmers. It's that there's only so much one person can do. Simplification can reduce the number needed, but at the end of the day, one of the common patterns for increasing the amount of work that can get done is to specialize and not be a group of generalists. Hence, you have analysts and programmers. Then you have UI, BL and DB developers as further specialization.

It's more about the work to be done than the complexity of the tools in many cases. While I'm primarily on the dev/arch side of things, there have been plenty of times where I've been the analyst as well. These are on smaller projects where there really is only one or two people worth of work. The larger the project, the more chance you could solve scaling people by specializing and letting some folks know what the app is supposed to do and letting others make that happen.

Every person has a complexity budget. It then follows that every project has a complexity budget. When you make it simpler to implement functionality, then you can implement more. We'll still want to spend that complexity budget though. Thus, I think we're a LONG ways from seeing the notion of seperate analysts and developers go away. If the tools make it simpler, we'll just build more complex applications.