Archgrove

Again, the big 3 parties failed to reply to my letter. If nothing arrives tomorrow, that’s an entire week without even an acknowledgement. If I don’t have replies by next Wednesday, I guess I’ll have to find a higher profile method of getting a response.

Programmatic techniques that have until recently been the preserve of the CS students and the scripting elite are slowly trickling down to mainstream languages. Java proved you could have a common, not-entirely-nauseating general purpose language that utilised garbage collection. Now, the very popular Python and Ruby scripting languages are bringing day to day programmers in contact with seemingly scary concepts like closures and continuations.

Well, be scared no more! An excellent post “Continuations-for-Curmudgeons” gives a basic introduction to the concepts without the heavy intellectual overhead normally found in articles of this type. It will pay to become more familar with these powerful ideas, as they will be trickling down to “day to day” languages over the next few years.

Chris Menegay voices similar concerns over the “disparate tools problem” that I believe nTeam will face, giving a more realistic view of the actual problems the lack of a consistent interface will pose.

Though his point on the additional costs a harder to use system will entail is well taken, I do disagree on some of his “must haves” (e.g. Project/Excel integration, distributed load testing), as he seems to think nTeam is actually competing with VSTS in the “huge enterprise project management” arena, rather than being a smaller product for smaller teams/projects. There’s also the issue that most teams currently use virtually no management systems beyond perhaps VSS/CVS and, if you’re lucky, Bugzilla. In this situation, any additional help can be useful.

No new replies to my software patents letter today. I’m still waiting for responses from the Conservative, Labour and Liberal Democrat candidates (and one independent). This is not an impressive showing for the major parties candidates, compared to the responses I’ve already had from Green and UKIP.

The fervour surrounding the VS Team System pricing and target audience has whipped the community up into beginning the nTeam system, an open source alternative to VS Team System (although pitched at smaller development houses). The interest is such that they’ve already been featured in eWeek, before a single “line of code” has even been crafted.

The project is certainly ambitious, and has sensibly decided to leverage a key open source philosophy – that of reusing existing code bases. Whilst this will cut back on the amount of work they need to do, I think they underestimate how difficult it will be to cohere the different code bases together in a way that will actually get used.

Reading over the forum, in the first instance they plan to produce a suite consisting of a rather amorphous “server” that runs code control, server side unit tests, issue tracking and continuous integration. Client tools are also planned, consisting of unit testing, possibly refactoring, and similar. I don’t think the final feature set is nailed down yet.

Before it is, I’ll add my two pence and say I think some of the priorities are wrong; far too little emphasis is placed on the data repository (“source code control”). This is more than just a small server component – it’s the fundamental piece of a team management system. If a test framework fails, it produces an annoying bug, but it can be fixed. If an issue tracker looses an issue, it’s an admin headache, but someone will pick it up. If your SCC system fails, then you’re in deep, deep trouble – your product has just gone up in smoke.

The SCC is the fundamental system that ensures your fixed bugs stay fixed, your new tests hang around, and your continuous build server has something to build. A versioned SCC is not something that will be easy to “bolt on” later – the checkout/edit/commit cycle is pretty different to the “just save to disk” route. If I were designing, SCC would be the first system I would solidify (even if it is just the interface), and worry about everything else afterwards.

My other concern is that bringing together five or more totally disparate products will, without massive work, just feel like five separate products bundled into one installer. The danger being that nTeam could end up being little more than an installation tutorial for all the different projects. This could be valuable, but certainly wouldn’t represent a viable alternative to VS Team System. A lot of work will need to go into making each original product feel like a single system – suitable UI changes as well as a high degree of interlinking will be needed. Retrofitting all these different code bases (as well as continuously incorporating bug fixes from the original projects) could be a mammoth and tedious time sink.

I should disclaim that I’m no expert in team management software, so this is just my opinion. I think what the nTeam group is trying to do is admirable. If I find a sustained interest in the project, I’ll post further. I should also put my keyboard where my mouth is.