Teams, teams, project, more projects, ideas, goals, and all that stuff. I work a regular job like most guys, but for some reason I feel that I have to step beyond that and do more. Maybe it is my desire to shoot for the riches that success can bring, maybe it is the accomplishment of doing work well. Either way I often step beyond just what I do at my regular job to work on side projects, lead teams, consult, and even just code myself. I’m not sure how I find all the time to do it.
Recently on one of my consulting side gigs I’ve been discussing team size, architecture plans and ideas, team structure, software licensing, and the other regular items that go along with running a software team. I’m going to break down some of those points now into more specific topics and look at some of the current plusses and minuses of those subjects.
Team size
I’ve dealt with numerous scenarios in which someone has asked me the age old question that comes with division of labor. The question usually goes something like this, “If you have 4 guys now and we add another 4 to your team will you be able to do it twice as fast?” That question is usually then followed up with, could we bounce that number up to 12 or 20 or 30?
That is when I always have to say “stop!” Often times projects are measured in a very simple way. X number of hours are allocated, so if we multiply the number of persons working the hours, X is divided by the number of workers. This is horribly wrong; basic economics 101, Adam Smith division of labor, simple division of work requires a fundamental issue in clean division like that. That is communication.
Communication is needed among a team which causes a decrease in individual productivity so that the team can be productive. Often teams are broken into small groups of no more than 4 to 6 people. These teams are the most logical break down to achieve the most reasonable division of labor and productivity.
One aspect that adds even more confusion to this division of labor is the reversal of productivity. Written about in multiple books and on blogs the world over. The reversal of productivity is often referred to as a “death march” per the book that made the term famous for software projects. When teams get to a certain size, diminishing returns turn into no returns and then into an actual reversal of productivity. Basically what happens is you have people at 100% utilization, then at 90%, then at 78%, then it goes down and down. At some point you actually get into negative utilization, when it costs so much to communicate no one is actually doing work. This is the most critical mistake, especially after this mistake has been made so many times, for any software project, lead, or director to make. It must be avoided at all costs!
Team size is good at 4 to 6 people. If it gets bigger another level break down needs to occur and delineation of the product functionality between the teams. If that cannot be done, the project is being built as fast as it will be built. Acceptance is an important thing for a company and its leaders to understand at this point. Like the saying goes, “Rome wasn’t built in a day.”
Architecture and the Architect
Vertical technology stacks always intrigue me. I’m of course most familiar with Microsoft’s stack of SQL Server, .NET Framework, and that whole set. Beyond that though, the concepts are very similar with Microsoft’s, Oracle, Java, or whatever tools one decides to use. The architecture is the key point of an application that really brings home the functionality and use of an application. If the architecture is bad, no Microsoft or Oracle or Java is going to save the project. The Architecture needs to be solid and well designed from the beginning.
The architect is often though to be the arbiter of the design and the end point of all discussions on design. I am one, as will any truly experienced architect will tell you, that no single point of failure should be built into a project. Sure, have a lead or single “lead architect”, but keep discussion open. Keep the design flexible enough that when part of the design is recognized to be bad it can be replaced with something that will work.
I was talking to a friend of mine, who was a carpenter, who I laid some parallels out with. He of course builds what an architect designs. I have built what an architect designs. He elaborated on a project he was on, in which the architect had placed a toilet literally below a weight bearing structural beam of a house. First off, a weight bearing structural beam is supposed to do exactly what the adjectives state, bear weight. With a toilet below it all it will bear is the roof into the toilet. He described to me how the architect was given a ring on the phone and came down to the job site ranting about how some “construction worker” had screwed up the design. He arrived, looked over the blue prints, and realized that the “construction workers” where building exactly what was on the blue prints. Needless to say, a change was made. This is the exact same thing that can happen, and often does, on a software project. Don’t have a “single point of failure architect”, keep discussion open.
Software Licensing
Oh dear, this is the most complicated and annoying part of the whole process. Mainly because it functionally and technically adds nothing to your software project. It however, especially if you want control or to sale the software, is of utmost importance.
There is closed source, open source, common license, and other license models out there. When choosing a software licensing scheme, one must remember and know how the licensing affects the way software can be sold, who can or has rights to the software after it is built, and so many more things.
If someone wants proprietary control of their software base they can’t use open source. If someone wants to use open source and provide a community input like Face Book and others have created, they have to use open source. Fortunately there so far has been a way to make money off of almost every model. But when setting up a project, or even a startup company, make sure you know the differences! You don’t want to lose the farm before you even have it!
To all those I have consulted lately, hopefully this adds some clarity to the multi-faceted knowledge base one needs for successful project completion and ongoing maintenance or operation of a product!
