Chris Menegay's WebLog

Am I off my rocker?

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.

 

 

Posted: Jul 15 2005, 09:15 PM by cmenegay | with 3 comment(s)
Filed under:

Comments

Jeremy Miller said:

Chris,

First off, I did think the talk was very good and I thought you were clear, I just disagree with the one particular statement. I don't think VSTS brings much to the table for me in specific, but I'm not in a typical situation.

I think I misinterpreted your remarks somewhat, but my point is really that developers *should* be both knowledgeable about the process and have some responsibility for the process. Who in the world knows more about software development than software developers? Much of the inefficiency in software development happens at the boundaries between requirements, coding, and testing. People need things from me and I need things from them. I'll be a better developer if I understand what's going on around me and actively contribute to process optimization. If VSTS helps with that then that's a cool thing. Besides, I can just hear someone on the VSTS team in Redmond saying "Mort doesn't care about process" and that kinda thing always annoys me.

The reason I still think VSTS is targeted at large companies is that they're the folks that have severe transparency and communications issues. Some of the features (especially the policy enforcement stuff) would have been a godsend to me when I worked at a Fortune 100 shop. Being a small shop, our project transparency is already very good. Just using a simple Scrum process for iteration/release management and the daily burndown chart provides every member of my team plus management with visibility into what's going on with not much more sophistication than Excel and a Wiki.

When I said "laborious" I should have said "high ceremony."

Thanks for all the extra blog traffic btw;-)
# July 18, 2005 3:22 PM

TSHAK said:

I agree that we need to hold developers accountable for changes in the code. I also agree that tighter control is required after "code complete". However, for the most part, requiring a work item for every checkin will prove to be a disaster for productivity. Developers are the designers of the software, and they must design within the customers requirements. They must also be free to explore that design, without the burdon of a heavy process. They must also be trusted to work within those requirements. This is why we have small iterations in which the customer (or PM, PdM, or other stakeholders) can review a working build to help ensure that the developers are meeting (or going outside of) the requirements. This is why we have good dev leads that we also trust to keep a good eye on all checkins that are being made.

I don't have any problem with processes like checkin policies and the like. However I agree with Jeff's point on using VSTS to control what developers work. I too think it will affect developer retention, at least of the smart and creative kind.
# August 1, 2005 7:01 PM

AngryJay said:

if you are a rocker you must see this: (heavy mashpits)

nz.youtube.com/watch

# December 21, 2008 1:40 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)