Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Interesting insights from Software Estimation: Demystifying the Black Art

by talexb (Chancellor)
on Jun 11, 2007 at 17:38 UTC ( [id://620542]=note: print w/replies, xml ) Need Help??


in reply to Interesting insights from Software Estimation: Demystifying the Black Art

Interesting -- I'll have to see if I can pick up a copy of this book.

However, it does make me wonder, what literature there is for smaller teams, say 1-3? When I started work at my current employer, I was joining a one-mean team, but about 18 months later, my team-mate left. So I've been working as a one-man team for the last three years or so.

That has its advantages and disadvantages, depending, I suppose, on the personality involved. For example, with two people on the team, we often used extreme programming (XP) to write reams of code. Now that I'm on my own, there's a SysAdmin who sometimes sits with me as I wrote code now. While he's a smart guy, he's probably not be getting 100% of what I'm writing in Perl or SQL. It's still nice to have someone in the co-pilot's seat while I write code and explain my thought processes.

I do know one thing about a small team -- you have to get on well with each other, otherwise productivity goes way down. The good news about a one-man team is that I can have a team meeting in my head. And .. that can be a bad thing too. :)

Actually, I've found that the best time for a team meeting is The Next Day, if I'm really stuck. Another approach is to explain the problem to someone like my wife; she doesn't know much about software development, but she's a really good listener. This usually results in my explanation tailing off as I race off to look for a pen, so that I can write down the solution that's just occurred to me.

My other outs are dropping in on Perlmonks or visiting #perl on freenode .. asking and answering questions on-line always gets my creative juices flowing.

And, of course, without coffee I'd be lost. Anyone else have comments about a Development Team of One?

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

  • Comment on Re: Interesting insights from Software Estimation: Demystifying the Black Art

Replies are listed 'Best First'.
Re^2: Interesting insights from Software Estimation: Demystifying the Black Art
by tilly (Archbishop) on Jun 11, 2007 at 18:00 UTC
    If there is extensive research on the performance of very small teams, he did not present it. All that he presented was one graph from Lawrence Putnam for schedule and effort to complete a medium sized project for various team sizes. Medium was defined as 35,000-95,000 lines of code, and averaged 57,000 lines. (The averages were close to this for all team sizes.)

    Eyeballing the graph, it looks like teams of 1.5-3 people completed their projects in about 14 months, 3-5 in about a year or so, and 5-7 in just under a year. No data is presented about the relative quality of those projects, or the distribution of languages used.

    If you wish more detail than that, the reference that he gives is Putnam and Myers, 2003. Which would be Five Core Metrics. I have not read that book.

Re^2: Interesting insights from Software Estimation: Demystifying the Black Art
by itub (Priest) on Jun 12, 2007 at 08:46 UTC
    Poor wife... why bug her when you can use a teddy bear? ;-)
    Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind, I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor. --Brian Kernighan and Rob Pike

    See also: Teddy Bear code reviews

      ;) I ask my wife because although she knows little about software development, or even computers, she has a very good grasp of logic and is quite able to ask intelligent questions. And asking questions comes in handy when the 'Aha!' moment doesn't occur.

      And sometimes, there isn't a 'great' solution -- you just have to pick one of the available 'less great' options and go with it.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re^2: Interesting insights from Software Estimation: Demystifying the Black Art
by samizdat (Vicar) on Jun 12, 2007 at 16:32 UTC
    One of the advantages of big teams is that you ask for a few books and you get back "Investing in our people is always in ____'s best interests." Ordered.

    In regard to the productivity of small teams, I spent most of my career as "it". I think it surely has both advantages and disadvantages. One disadvantage is that you don't get valid design and code reviews, but one of its advantages is that you need fewer of them.

    I'll second the personality and politics caution. My very first programming-only job was 8051 assembly coding for a handbuilt wire processing assembly line. The guy who hired me started out being quite egotistical about his skills, but ended up getting quieter and quieter as my skills surpassed his. I won't say that I _was_ better than he was, but since I was learning this from scratch, it was obvious that I was going to be pretty good quickly. It never turned into a problem, but it could have. He was having difficulty not being the only star. I don't think that's an issue only for small teams (!!!!), but it's definitely more of a showstopper potential for them.

    I heartily second tilly's point that small teams can do a lot with Perl or other dynamic interpreted languages. There are times when teams (because of management or programmer stupidity) choose Java, say, because it's the 'next wave for Enterprise development', and end up killing the project and the company because of the design and CPU overhead. I'll need to read McConnell's book to get to the source of the thread, but I'll agree that an awful lot of projects that are coded in C or C++ or Java had no need to be done that way and would have been better done in Perl. A lot of this 'embedded Linux' stuff has no need to be compiled C, and we'd be better served to get it out the door more quickly than to save a few cycles of CPU. We're definitely seeing every one of tilly's concerns about big teams here, from personality conflicts to API problems to inefficiencies to crappy programmers hiding in the weeds. I've slipped in a few scripts that have ben well received, mostly for generating C header files and array declarations early in the build, but the truth is that there's very little code here that couldn't be all Perl.

    Food for thought. Thanks, tilly, for the link and the commentary.

    Don Wilde
    "There's more than one level to any answer."

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://620542]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2024-04-19 01:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found