“For any given project, there is a limit to how much time reduction can be achieved by increasing staff (striped asymptote). Further staff increments do not reduce delivery time; they probably increase it. An alternative way to think of this effect is that productivity is a function of team size. Individual productivity falls off somewhat as the number of people interacting increases.”
- Tom DeMarco, Controlling Software Projects
Archive for September, 2007
Individual productivity
Friday, September 28th, 2007Shared Experience
Friday, September 28th, 2007“There are some things you can’t share without ending up liking each other, and knocking out a twelve-foot mountain troll is one of them.”
- J. K. Rowling, Harry Potter and the Sorcerer’s Stone
I’ve been thinking about what constitutes good teamwork and I’m not sure that I have a lot of answers yet. But one thing that keeps coming back is the idea of shared experience. Here are some of my thoughts about what constitutes team building shared experience:
- It is not something that can be artificially fabricated. It is not something that the H.R. department can make happen.
- It usually involves some kind of challenge that is overcome or some problem that is solved.
- Real work is done that has impact on the project, company, or at least on the team.
- It often takes place outside the normal work situation or outside the normal scope of work. Work in the office during normal business hours just doesn’t seem to build shared experience.
- It often involves food or other social kinds of things.
- Team t-shirts, mouse pads, or other gadgets from a shared experience help cement the experience in the culture of the team.
While I think that shared experience can’t be artificially fabricated, I think there are some things that can be done to provide intentional opportunities for shared experience. For example: as a kickoff for a new project a team could take a couple days, book a conference room at a hotel and get out of the office and do planning. There could be a mix of fun activities as well as extended work sessions. The event would need some concrete goals that would be achieved during the time away. I think that an event such as this is the kind of thing that has a lot of value to a team. Unfortunately the value is not quantifiable so it is rarely attempted.
Unmeasured Activity
Friday, September 21st, 2007“If you measure exactly the work of design, for instance, and then don’t measure the coding at all, people will soon catch on. Their conscious or unconscious reaction will be to push as much of the work as possible into the unmeasured activity.”
- Tom DeMarco, Controlling Software Projects
Interesting. Why is it that people would rather work in unmeasured activity? Is it because we would rather be trusted than supervised, monitored and measured? Is it that we just don’t like structure and control over us? Just wondering…
Developer Productivity
Monday, September 17th, 2007Has developer productivity improved in the last ten years? We have much better tools now than we did ten years ago. We understand more about development processes, methodologies, and even developer psyche. But do we get more done?
In 2007, Joe Developer can drag a widget onto a canvas in his whiz bang IDE and in the blink of an eye one thousand lines of code are generated. He must be more productive than he was in 1997, right? I don’t know. I’m not so sure that Joe actually delivers more functionality.
Tools may have increased in power, but expectations have increased as well. Users expect more from their applications. A web application with rudimentary forms to submit data just doesn’t pass muster anymore. As user interfaces become more fancified (that’s the technical term), user expectations change and I wonder if potential productivity improvements are lost. I wonder if development tools are making gains in the wrong places. And when I say “the wrong places,” I really mean “not in the area of productivity”. In other words, rather than giving us tools to more quickly get things done, we get more layers, more options, more features, more…stuff. I don’t actually think that better interfaces are a bad thing. But sometimes it seems that tool vendors are focused on delivering more eye candy and are not helping us deliver better, more solid code in a shorter time.
In 2007, we are doing a lot of great stuff. I’m just not sure we’re any better at dealing with the fundamental complexity involved in building software.
Programming, Easier and Harder
Monday, September 10th, 2007It seems to me that programming is getting easier … and harder. Programming is easier because of google (and other search engines.) Just last week, I was trying to figure out a problem trying to run a java application. I was getting an error because I had declared jar files in both the “-classpath” and in the “-jar” command line options. So I googled the error and within minutes had fixed the problem. Often, as I write code, I use google to find examples of what I need to do. The internet provides the ultimate medium for programming by example. Being able to quickly find sample code for whatever I might need at the moment is a huge time saver. By comparison, I think back to ten years ago—if I was stuck on something, it might take days to figure out. I would first look through printed documentation. Which would often fail to help at all. It might give me a getter understanding in a general sense, but would rarely solve the particular problem before me. Often the solution would come with lots of tinkering, discussions with coworkers, calls to tech support, etc.
Programming is also getting harder. Ten years ago I was working in one environment at a time, with one programming language. Sure, there was database connectivity and things like that. But all in all, I was doing less things at the same time. But tools are proliferating and becoming more specialized. Today, in addition to the two primary IDEs that I use (Eclipse and Visual Studio) I also use tools for UML, database access, XML editing, and a bazillion other utilities. Of course, there are ways to do all those things in one IDE, but that’s not the point. Do I have a point and am I going to get to it today? Yes. The point is that programming is becoming more complex. We have to do more things with more languages and tools. It’s not enough to know C# for example. I also need to know HTML, XML, CSS, XSD, ASPX, T-SQL, UML, … the list just goes on and on.
Easier…and harder.
By The Year 2000
Monday, September 10th, 2007In his 1982 book, Controlling Software Projects, Tom DeMarco predicts that “By the year 2000, empirical projection will be de rigeur for software.” In 2007, I think it would be safe to say that most software development is NOT projected empirically. If anything, I think we have learned that to make accurate projections is much more expensive than most software shops can afford. I predict that humans will never learn that it is dangerous to make predictions. 