New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Are Business Analysts Ready to Become Programmers?
Posted 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?
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
-
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...
-
There already exists a programming language called D.
And it's not too shabby, if you like the curly brace language style. -
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.
3 comments
Watch Thread Reply