It has been a few years beyond the 25th Anniversary of Fred Brooks wonderful book the Mythical Man-Month, which I hope hasn't gotten lost in time. I consider it, and Tracy Kidder's Soul of a New Machine, to be two of the most important development management "experience papers" ever published. These guys weren't talking about academic principles or disconnected hypothesis, no, they were recounting real lessons from real software projects.
Even more surprisingly, I still find the lessons from each nearly as relevant today as they were when they were written, which can be depressing if you consider how little we've learned from our mistakes. Oh well, back to the MMM (Mythical Man-Month).
One of the fundamental principles that Brooks identified within software projects was Brooks' Law, simply stated as—"Adding manpower to a late software project makes it later". I think we've all experienced this in action. Your project starts falling behind schedule. Your internal reaction is to apply more pressure to your team to "make up" the time and recover the project. External stakeholder and executive pressure can often take a different direction, looking to add people wherever possible to recover the schedule.
I can't count the number of times I've been offered "help" of this kind from well and not so well intentioned exec's, project managers, and others. Later on, when I began leading testing teams, the offers surprisingly even increased. Partly because schedule pressure moves downstream, so testing is always compressed. Partly because many think that almost anyone can test – school children, boy scouts, customers, etc. But that is fodder for another post...
Help Defense
Often if you simply say no to these offers, you'll come off appearing stubborn, inflexible or generally resistant, none of which are perceptions you want to create. Additionally, there will be times when these offers can actually help you resolve schedule pressure and apply corrective action, although rarely exactly as envisioned within the offer, but it can help nonetheless.
The key is to be able to understand the nuance of your teams' performance and truly understand the dynamics of adding and removing developers and testers before you actually get asked these questions. That way you can reply with an informed perspective on truly what can be done to improve the situation by adding people. And conversely, what will actually worsen the situation (as defined by Brooks' Law) by adding people.
Study Your Teams' Capabilities
Your first position of defense comes from truly understanding the performance capabilities of your team, often at a detailed individual and sub-group level. For example, if you have a small 3-4 person database development group, you should understand:
- What sorts of artifacts they typically create (scripts, stored procedures, DB architecture & configurations, etc.)
- Typical delivery times for different "sizes" of deliverables
- Who is the highest performer in Active Time and in contributed LOC and other meaningful artifacts?
- Conversely who is the lowest? And what is the average across the entire group?
- What the exact performance impact would be if you lost a person?
This data gathering is not for performance commentary or rewards. Rather, you're looking to understand the detailed tempo for contributions within the team in case you fall behind schedule or lose a person. Then you'll much more fully understand the impact and be able to plan and react accordingly.
One of the valuable aspects of velocity based planning, as mentioned in a previous post, is that it naturally compensates for these sorts of things. Often though, you can't simply wait for velocity to unfold and illustrate the impacts, rather, you must have a strong sense in advance.
This post is continued here...
I had the opportunity to attend OSCON in beautiful Portland, OR this week and thoroughly enjoyed it. It certainly lived up to its billing as having the veritable who's who of the Open-Source community.
No other conference will you find so many representatives of the 'P' languages -- PHP, Python, and Perl. I've sadly ignored the 'P' languages for the most part. Sure, I've periodically used PHP to customize our web infrastructure (blog, forge, etc). I used Perl a long time ago when I work on large UNIX-based software systems, but I wouldn't consider myself a Perl hacker -- although the camel book from O'Reilly is one of my all-time favorites.
These languages are unique in that they inspire a passion for language that is very cool. When I'm at JavaONE, developers don't corner me and say, "I love Java," or "You've got to use Java for your application development -- you'll improve your productivity" or "It's impossible to write ugly Java code."
Java doesn't inspire passion. I've been using it since 1996, version 1.0. Every major application since 1996 that I developed, sold, and lived on was written in Java. Yet, I'm not passionate about it. I was in 1996, but I'm definitely not passionate about it now. Python's been around for almost the same time as Java, Perl's been around for much longer and developers are "giddy" about it.
This is not just a new thing. C# is very new and is quite nice. It was developed by a very cool guy, Anders Hjelsberg (also the creator of Delphi which has a very passionate following), and it is my language of choice for writing .NET applications. However, C# doesn't seem to inspire passion -- even among the .NET community.
Java, C#, and others (C, C++) don't inspire passion because they are the status-quo -- the languages used in the development of most business applications. They achieved this status through the support of major vendors. Sun and IBM hitched their wagon to Java, developed middleware and tools in Java to make it easy for big corporations to adopt. Same for C# and Microsoft. While there are pockets of Perl and Python in big companies, they are not the predominant force.
Look at PHP...it was extremely cool a few years ago. All the tracks at conferences were about PHP and the community grew. A year ago, IBM pledged significant support for PHP in conjunction with Zend, and now the excitement is starting to quell. No one cornered me at OSCON this week to tell me why I should use PHP.
Here's a graph illustrating the adoption vs. cool factor of languages. The challenge for the cool languages is how they increase their adoption without losing the "coolness". The typical pattern is illustrated on the chart.
Prove it
I'm going to propose an alternative way for these languages to grow in adoption: prove it with data. Focus the passion on discovering ways to quantitatively prove that your language is better. I'll let the creative folks in the community determine which metrics are the appropriate ones to use. Proving that a language is superior can be all that's needed to make the business case to increase adoption and usage. Management at big companies (people that pay for things) need proof to jump to technologies because there is risk with it. IBM, Microsoft, and Sun mitigate that risk for them. However, your data can help make the case with or without the big vendors. And because the business case is made by the community -- it maintains the mystique, hype, and excitement around the technology.
I'll end on a challenge for you passionate Python, Ruby, and other hackers (sure Erlang, Haskell, and Lisp aren't excluded): Prove with our data that your language is superior. We'll gladly try out the first proven language on the next project we undertake and will publicly report on our progress. If there's a metric that we don't have that's essential for your proof, send us an email, and we'll see what we can do to add it.
In case you missed it, Friday was SysAdmin Day. What do you mean you've never heard of SysAdmin Day and don't know who your sysadmin is? Sysadmins are the talented souls inside every organization that silently, invisibly and diligently keep the networks, servers and PCs blinking, humming and processing. Some say sysadmins are like a good surgeon. They're not: a good sysadmin is more important than any surgeon. So Sysadmins get an official day of recognition.
What about application developers? They, after all, are the wheels that keep mighty application development and maintenance rolling. Just like Sysadmins, developers also go pretty unrecognized inside most organizations - unless, of course, the organization in question is like Microsoft and revolves around software. Often, the only time you know application developers even exist, is when the new software is late or has bugs. Boy, you sure know the developers' names then.
Of course, it takes more than a special day each year to recognize your teams' progress and achievements to the extent that it makes a tangible difference. What it really takes is great software and really good metrics, the kind that can record progress, identify weaknesses, and assess the impact of changes in management tactics and the provision of resources. Software and metrics help you to not only reward team members and recognize their achievements on a daily basis, but to do so in a way that directly benefits your organization.
Developers who get the material resources they require, the right training, or who simply get to keep management out of their hair are more likely to build the software that management asked for, and deliver it on time and on budget. Everyone likes to feel appreciated. Sometimes, you just don't need a special day each year to do it.
Our Desktop solves a complex problem. It integrates with multiple versions of 6 development tools, running on 5 operating systems (Windows, RedHat Linux, Suse Linux, CentOS, and Mac OS X), and is accessible via 4 web browsers ( IE 5.5+, Firefox 1.5+, Safari, and Opera 9 ). Combine this with the fact that it operates through firewalls/proxy servers makes the problem even more challenging.
Sounds fun, doesn't it?
This release is a significant milestone for our young company and is the culmination of a large re-design based on our collective customer experiences. When we sat down to plan our development of the new Desktop, our data was a huge factor in our decision-making. Despite the 6 calendar months invested in the development of the first version of the Desktop (including minor bug-fixes, etc), we had only 120 cumulative active development hours. Our team averages about 100 active hours each week. Given the depth and significance of our desired changes and the relatively small investment in the Desktop, the decision to start from scratch and rewrite the Desktop was pretty easy (as easy as these decisions can be).
5 weeks and 450 active hours later (yeah we added some stuff), 6th Desktop 2.0 is ready.
Key Highlights
- Brand new UI for managing sensors
- All new sensor infrastructure for simplifying sensor behaviour (updated each sensor)
- Support for multiple installations of 1 sensor ( great for your 3 versions of Eclipse )
- Support for multiple users on 1 install ( great for shared machines )
- Migrated to ports 80 and 443 for all communication
- Numerous enhancements to sensors
- VIM sensor reimplemented and now supports installation in Cygwin.
- 20+ bug fixes
If you have any feedback or suggestions don't hesitate to write to support@6thsenseanalytics.com
By all accounts, BarCampRDU was a huge success, and we couldn't agree more.
First, thanks to the organizers (Fred Stutzman and company) for the outstanding job. Second, thanks to all the sponsors (including Red Hat for the space). We are proud to be part of the group that helped make the event possible.
We gave several presentations including product demonstrations, "Ajaxifying web development with Dojo"; and "The shape of things to come in Scalable Vector Graphics". All sessions were well-attended and were a lot of fun to lead.
Read More
I want to continue sharing the patterns from Fearless Change in this post. The following are just a sample of the patterns that I've cherry picked a bit to give you more of the flavor.
Enjoy!
| Theme – Early |
| Pattern Name |
Summary |
| Ask for Help |
Since introducing change requires lots of effort, look for people and resources that can help you. Then ask! |
| Do Food |
Entice participation and food always works. |
| Early Adopter |
Win the support of the people with an inclination to trying and accepting new ideas. |
| Next Steps |
Take the time at the end of an event about the new idea to identify what participants can do next. |
| Piggyback |
When faced with several obstacles in your strategy to introduce something new, look for ways to piggyback on a practice in your organization. |
| The Right Time |
Always consider the timing when asking for help or scheduling events. |
Read More
Microsoft recently announced Glidepath, a program encouraging ISVs to build "software factories" - re-usable software components to automate development. It's hoped these will cut the costs of building software and speed-up delivery. 6th Sense Analytics co-founder and CEO Greg Burnell, whose industry experience includes running TogetherSoft (bought by Borland), here assesses Microsoft's attempt to solve what is an industry problem while explaining the 6th Sense solution.
Q: Microsoft sounds like it's on to something with software factories. What's your take?
A: Microsoft's intentions are good, but the entire concept of software factories is flawed. Software factories fail to tackle the software industry's biggest problem.
Read More
One of the great challenges facing software leaders is introducing change within their organizations. Not change for its own sake, but change that drives their organizations and teams towards new levels of performance and capabilities. The first thing every leader should understand is their internal inclination towards change and the overall change adoption curve. Geoffrey Moore introduced change adoption levels in his breakthrough book Crossing the Chasm. The below table captures the change phases he identified –
|
Change Inclination |
Percent of Groups |
|
Innovators |
2.5% |
|
Early adopters |
13.5% |
|
Chasm |
|
Early majority |
34% |
|
Late Majority |
34% |
|
Laggards |
16.5% |
The key point in the book is that it takes momentum from the innovator and early adopter community to adapt to any new approach, technology or product. And, in order for the change initiative to be successful, these groups need to drive it across the chasm into the early majority for broader adoption.
Read More
One of the new ideas coming from the Agile Methodologies are two different ways to look at planning software projects. These are the notions of ideal day planning and capturing the team's velocity for planning future iterative releases.
Ideal Days
In ideal day planning, you examine the capabilities of the team to deliver work within an "ideal" day—usually defined as an uninterrupted, 8 hour span of time. Then all of your estimates are made using ideal days. This focuses the team towards full days of focused activity when thinking of and estimating the project work that needs to be done. Some of the agile methods subscribe to pair-programming, so these ideal day estimates would represent the effort associated with two developers.
Of course, ideal days then need to be translated into the real world that includes interruptions and work not associated with the project(s) at hand. That mapping usually falls to either the coach or project manager to make as part of the planning process applied to translate the team's efforts—forward—into predictable functional delivery dates.
What's nice about ideal days is that it's simple and it abstracts the team from worrying about and trying to factor in for interruption and even padding for different member skill, capabilities or overall uncertainty.
Velocity-Based
Another option is to measure your individual, or far more important, team's velocity—then use this as a gauge in predicting future schedule performance. One unit for velocity can be ideal days of effort. That is, for each schedule deliverable (or iteration) how many ideal days of effort were actually expended towards the project? From a planning predictions perspective, you would then use this to predict future capabilities and adjust the schedule as required.
Another unit of measure within agile teams is story points. Story points are units that try and capture the size and complexity of XP-like feature stories (think of them as small use cases for lack of a better definition). You would then measure velocity in the number of stories the team can implement within each development cycle or iteration. Usually one story point is equivalent to an individual (or programming pair) working on a story for a single day (ideal day). However, in this case, it's not just a measure of time, it's also a measure of size.
Using Active Time
Bringing the discussion back to 6th Sense Analytics a bit, we measure Active Time as it relates to project teams focused towards delivering low level artifacts (code, tests, etc.) for the project. Since it's so finely grained, activity focused and highly accurate, Active Time becomes a good candidate for velocity-based planning units.
In order to "close the loop", you would need to have the team start making their task estimates in Active Time as well. But again, the data is available for team members to analyze their work activity and performance patterns and make Active Time estimates based on their historical data. Also, if you use a PROBE type technique, you can bring the Active Time historical data down to very specific types of work.
Of the two methods, I'm convinced that velocity-based planning is becoming a leading approach for planning software projects—clearly in the agile camp, but also within more traditional teams at the development level. Traditional project managers seem to be a bit stuck in their methods and slow to adopt it.
Fundamentally the approach disrupts the traditional planning model of:
Estimate –> Plan –> Track –> Make it Happen
To one that more realistically reflects the dynamics of software projects:
Estimate –> Plan –> Monitor Velocity –> Adjust to Reality
Instead of trying to draw up a plan and hammer the team into submission, velocity planning guides you towards a goal based on the true capabilities of the team as they face the challenges and discoveries along the path. The realities across the two methods are the same, it's just a decision of whether to pay me now or pay me later?
If you're interested in more information on the topic, Mike Cohn has written a great book Agile Estimation and Planning that nicely covers the topic. I may also explore it further in future posts.
When Sun Microsystems' co-founder Bill Joy said at JavaOne 2003 "innovation happens elsewhere" he summed up the innovators' dilemma in one handy sound bite. That dilemma: how to harness the power of smart people, not necessarily on your team.
That question returned with the publication of a book by two Sun engineers the title of which borrows Bill's words. "Innovation happens elsewhere" is an attempt by the duo to explain what steps companies can take to harness the creative works of others.
While the book tackles how to engage with the community on open source, the question of how to harness creativity is a burning one for everyone with a stake in software development.
People - in our particular case, developers - are an organizations' biggest asset in building software, and often you will find the people most important to this process are those furthest down the management chain, and closest to the shop floor.
These people demand the kind of culture that enables their talent to flourish. One of the book's authors, Ron Goldman, this month highlighted on Sun's developer network (here) some steps employers can take to establish such a culture. These range from opening up the development process so that decisions are taken openly and publicly, to establishing an atmosphere of trust and collaboration, and fostering a set of passionately shared goals.
Fundamental to all of this, though, is the need for organizations to recognize that for software projects to grow and flourish (and hit deadlines) they require different types of skills. People contribute in different ways - in design, testing, coding and writing.
That may seem obvious, but the reality of the workplace is different. Pressures of deadlines or a lack of suitably qualified individuals means projects often suffer from under staffing or a lack of people with the right type of skills. This means developers' workloads increase, often in areas where they many not be specialized, leading to loss of productivity, de-motivation, bugs and delays. This is especially true when companies outsource parts of their application development process, and those members of their application team who remain must either hold the hands of the outsourcing supplier or correct their mistakes.
Good software gets built by staff who have the resources that let them flourish and who are surrounded by a healthy support system. That means employers must build a software-based infrastructure with companies like 6th Sense, which helps identify potential bottlenecks, provide adequate training and tools, and spread workloads across the team so individuals don't become overworked.
The right infrastructure will help build the culture of trust and collaboration, and help ensure goals are shared passionately and that innovation is harnessed.
You will never resolve the fact there's always going to be more smart people outside your team, but you can take big steps towards bringing them onboard and ramping up the creativity of your team using the right infrastructure.
