Cross-posting on: http://teamsystemrocks.com/blogs/chris_menegays_weblog/default.aspx

Someone pointed out Jeremy Miller’s thoughts on a VSTS talk I gave in Austin on Monday. Of course, I’ll have to comment on the “Menegay was completely off his rocker” comment – I’ll get to that in a minute ;-)  

First, some background - The whole talk was about an hour and a half, so I wasn’t able to cover everything in detail, and I wish I had been able to show some more demos – as I think that would have helped with some of Jeremy’s concerns. My overview talk is generally not targeted at developers – mainly because I largely agree with Jeremy that things like unit testing, etc. don’t add a ton over what’s available today for developers. I do think that VSTS offers more than the open source tools, but that’s because I’m a buy, not build, guy. The open source products always make me think of some child’s toy with “some assembly required”. The lifecycle aspects of VSTS are the real value. If a company adopts VSTS for just the developer features, they are really missing the point, IMO. 

That leads me to the “mindless zombies” comment. For those that have never seen my talk on VSTS – I try and drive one point home that is “my vision” of how things should be.  MS doesn’t make you do this in VSTS, and I try to be clear that it is MY vision. That’s probably why Jeremy thinks I’m off my rocker, rather than the team at MS. So here is my vision - I think that ALL work on a development project in VSTS should be driven from work items. If you are working on a task, you are doing so because a work item tells you do so. You then figure out what doing that task means – so you’re not entirely mindless. That should not be terribly foreign to most people, as generally we bend to the will of a project manager and we do the tasks they assign. The problem is traceability. Work items allow the project manager to communicate what to do, without having to tell people in person. Work items allow traceability.  

This is entirely my opinion, but I believe that many developers are an impediment to getting software delivered, because they feel somehow privileged – as if no one needs to know what they are working on, even the person paying them to do the work.  Imagine a doctor that is performing heart surgery and thinks, “You know, I’ve got all the tools here, why don’t I go ahead and remove this guy’s appendix.  He doesn’t need it anyway.” Obviously – the average person would throw a fit if that happened – especially after getting the larger bill for that “extra work”. But that is what programmers do all the time. And doctors are in a more specialized field that requires a higher level of training than programmers do. Yet they aren’t exempt from policy, procedures and PROCESS – but developers think they should be. So – while I don’t think developers should be mindless zombies, I do think they should do what their management tells them to do – if they don’t like it, they are free to get other jobs.  If a developer is told to do task XX, they shouldn’t be doing task YY instead, or worse, some task ZZ that isn’t even a part of the current project scope. This is called unsanctioned work, it is work that hasn’t been agreed to, and might be out of scope and cause problems with other aspects of the system. I have no issue if a developer finds a problem while fixing some code and makes a quick fix – it would be nice to have them document that by creating and closing a work item for their change. 

Process isn’t for programmers, it is for all the poor schmucks that pay for those programmers to have jobs. And THEY are the customer. If a developer isn’t willing to help the customer, that’s one developer that doesn’t need to be “retained”. So developer retention isn’t a real problem IMO. To use the worn-out house construction example: Would you hire a builder to build your house if he had no process? If you KNEW he was just going to hire 10 workers and say “go build a house”, would you feel confident that your money was being spent?  Especially if you had to pay for the entire cost and the money was 80% spent before you got to see the house?  This is pretty much how a lot developers want to work, they want to just go grab their hammer and start putting up walls, regardless if there is a process in place that says you need to get permits, lay plumbing, etc. 

I actually think Jeremy’s summary was quite good, I didn’t think his “bad” was all that bad, and the “ugly” wasn’t all that ugly. The only thing in Jeremy’s posting that I really have any issue with is that VSTS is aimed at companies that want a highly laborious process. I clearly need to revise my talk a bit so that I don’t give people that impression. I would argue that people doing Agile and TDD are implementing a more laborious process than most shops use, and a more laborious process than VSTS requires. I over-emphasize task tracking in my talk because I think that’s the biggest added value. I’ve never met a project sponsor or IT/Dev manager that said “I don’t care what the developers are doing.”  They would all like more visibility into what’s going on. And if the company’s internal project teams don’t offer that, I would be more than happy to have those project sponsors outsource their development work to Notion, and we will give them that visibility J

Anyway, I don’t feel I’ve offered a lot of clarity into my thinking, and there are probably even more people that think I’m off my rocker now.  If anyone agrees with me and has better ideas of how to articulate the vision – I’m open to suggestions.