A problem shared is a virus?
CLOC is a simple open source tool for counting the number of lines of code in a set of files (minus comments and blank lines).
Recently I needed to run a LOC count on a Symbian based code base to try to make a point about maintenance cost. I came up with a configuration which records the files I would consider code (including rss, rh, hrh etc) but ommits XML and things like SVG.
Read the rest of this entry »
Due to popular demand, I’m publishing my iTunes remote source code here
Read the rest of this entry »
I’ve read about effective team size in several books previously, but a lot of the teams I have worked in were “virtual” which made it hard to draw conclusions from. As an example, a product manager often doesn’t talk much to his surrounding team but more of a vertical slice of his and his customer’s organisation.
For me, running an engineering team has been a great experience to see from practitioner’s view, some of the dis-economies of scale which come into play as a team starts to grow.
The A-Team would not have been the same if they needed two vans. I’m sure the rate at which Hannibal says “I love it when a plan come together” would decrease proportionally to the growth in time size. (I think they cut that scene where George Peppard said “I love it when a plan comes together to pass MS3 with only two exceptions”).
I’m sure that every team working on a mid sized project feels that they have too much work to do and need more people to complete the task in good time. But then give them a bunch of new starters and they complain that all their time is being drained looking after the yung uns.
It should take some time to get a new starter involved and up to speed. You don’t want them sitting in the corner poking their friends on FaceBook, but in teams where things are not written down or out of date, a lot of needless time is wasted.
I’ve always tried to keep a project manual which nay be a word document, notes database or wiki explaining the team structure, tools and directly layout of documents and builds on network drives. I made it a new starter’s job on the first day to read the document and at the same update any broken links or out of date info as they worked through it. When they check their changes back in, they have also learned how to use the DMS (Document management system).
I believe there is no net overhead with keeping an up to date manual. Consider The Mythical Man month where Brooks details the project manual as a printed binded document which everyone had on their desk and which was updated by issuing new wads of paper and a list of changes. My dad said that the civil service was pretty much like that a few decades ago where you needed one or two full time staff just to integrate the delta guideline updates into existing policy documents. It has never been more convenient time to keep things up to date.
One of the problems is email. When someone has a problem, or a procedure is updated, the lowest inertia response to communicate the change as an email. How often have you talked to a person who is struggling with something and said “ah, let me forward you an email which explains that a bit better”.
That sort of way of working is not good for a small team, but really detrimental to a larger organisation.
Project Gossip
I’ll keep the implementation vague, but a suitable project repository encourages what I call Project Gossip. This is fundamental to team effectiveness and team gelling. Especially if team is large and/or geographically distributed.
Some of the advantages of such a system:
Sometimes project gossip just happens, but on other occasions it needs a kick start.
To make this work, you have to lead by example by always posting documents, attachments and things that you want everyone to read on your repository. By all means send a email to declare something new, but post a link to the database. (make sure the system you are using can generate links or URLs easily for passing around the team).
Publish meeting minutes, brain storming, everything on there in neat sections – but make sure your system is able to highlight new updates. Lotus notes is good at this because it keeps track of what you have read, marking top level topics which have unread entries with stars. RSS may also be a good solution to this.
The reason I call it project gossip is that everyone will be looking at stuff which is not strictly nececarry for them to do their job. They might be a baseporting expert looking at a discussion about multimedia, or tester reading a discussion about crash tools. That baseporting guy could come up with a novel algorithm to the multimedia problem and that tester might realise that the developers have a tool that can make his test defects more useful.
Oh and make sure that whatever system you choose that your IT department buys into it or at least back up the data nightly.
Team size refresher
The number of potential connections between team members is:
(p*(p-1))/2
Where ‘p’ is the number of people in a network.
The graph illustrates that the number of people grows proportional to the square number of people. There has been a lot written about optimum team size in various industries, with figures ranging from 5-9. In the software industry a team size of 7 seems to be the preferred figure to quote.
I saw it again today after a few years out of sight, out of mind. It has grown at least another 60 inches. I’m taking about a C++ constructor in some production code which is 1876 lines of code long. Yes, an object so complex that it takes close to a minute to scroll through it using MSDEV.
I felt nauseous on seeing it. It’s a bit like one of those Channel 5 documentaries “Woman who weight less than her tumour” or some other attention deficit grabbing title. You just can’t imagine how it can grow so big without someone noticing.
I can imagine the development team seeing a new requirement which involves finding the right point in the constructor to instantiate their new object. “Let’s give it to the new guy”.
Surely at around line 999 you must realise that your architecture or you supplier’s is FUBAR’d.
Please let me know if you are aware of bigger one.
Yesterday I attended the FogBugz seminar by Joel Spolsky at the British Library. FogCreek has a new release and naturally they want the world to know about it.
I like Joel, he adds value to the industry and has an incredible amount of energy. But I often thought that his larger than life character seemed a bit out of proportion to his product. I tried earlier versions out a few times and though there are some really nice touches, I couldn’t help but feel that this was a product ideally suited for people who create defect tracking software for a living.
(I particularly like Jira’s tag line “Jira : Because you’ve got issues”)
There is always a danger in assuming that all software development is the same. Yes there will be similarities – but why is it that every project feels that they are different and that a shrink wrapped methodology won’t work.
What I like about FogBugz is that it’s all about saving time, for both engineers and project managers. Even if the system doesn’t quite fit the bill – your engineers will not spend stupid amounts of time searching, duplicating info and filling in time sheets.
FogBugz 6 goes one step further than a defect tracking system by introducing the evidence based scheduling. Now a lot of people already do some sort of EBS (without the fancy name) in that they keep estimates and actual for a project and then use that to calibrate up and coming tasks or the data is mined in bulk when planning the next project, but in general tools don’t help.
In my experience, part of the problem is ‘billing time’ against a task is not a comfortable experience. There is a certain amount of guilt involved when an engineer is interrupts a task to make a phone call to the bank, or arrange an evening meal on toptable.com. There is also the other external interruptions by the boss or a colleague who feels the need to discuss in great detail how ‘crap lotus notes is”.
The resultant data is usually a database of lies, rounded figures and compensations. No one feels comfortable in entering time. Automating the process by having the user stop/start each time he or she is actually working on a task is never going to work either. If you forget to stop the clock while you visit the dentist, it’s just going to stress you out.
There is an old project management saying which goes “no matter what method you use – you put shit in, you get shit out.”
So, getting back to the point. I thought that Joel had something with his EBS. The tool deals sensibly with time recording.
This doesn’t help for one tasks, but with enough data – the EBS algorithm picks random estimated/actual calibrations and applies them to your new estimates to determine the overall schedule. In Joel’s example- if you have a David Brent like boss who interrupts you all the time, then the your estimates will be calibrated accordingly since the EBS algorithm is more likely to pick a estimate/actual which contains Brent interruption.
I’ve yet to see how this actually works in practice but the thing I like the most is that even if it doesn’t work well, the amount of time wasted is minimal which is better than a beurochratic technique which manages to both not predict project ship date and add a hefty administration overhead to all invoved. The key to making it work is that it’s about providing a feedback loop to get the engineers to understand and improve their estimation skills – not because “the man” dictates.
A few issues I had:
And glossed over was how useful all of this would be in “the crunch” phase. When your engineers are spending a few months just fixing defects:
To be fair, Joel said that this tool was useful for the development part of your project. But it seems like a cop out. I would like to see more information about how it deals with the above questions.
Summary
So all in all, very interesting stuff. I really hope it helps raise the bar in well though out issue tracking and management software, and in summary, for small-medium sized projects you could do a lot worse than FogBugz. I can’t wait for the results of the EBS in the real world.
