Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

lachoy (1663)

lachoy
  chris.winters@gmail.com
http://www.cwinters.com/

I am actually Chris Winters; I am actually living in Pittsburgh, Pennsylvania, USA; I am actually married and have three cats. (Guess what one of them is named?) I am the "OpenInteract" guy, which could be good or bad.

Journal of lachoy (1663)

Sunday November 25, 2007
09:31 PM

Small teams and big jobs

[ #34971 ]

Reg Braithwaite has a typically interesting post, What if powerful languages and idioms only work for small teams?. As usual I think things are more complex than most of the posters.

First, most of them completely disregard timeframe. Sure, as Carmack said, "a team of 3 focused and creative people can accomplish almost anything" -- given sufficient time. But time is the knob that many (most?) projects have little control over. Everybody has competitors, and everything needs to get out yesterday.

Second, most of the comments regard developers only. Does "small team" include QA? People to gather requirements? People to write documentation for users, or even other developers? Or do the developers do those too? (And if they do, see the first item.)

Third, I think there's a huge distinction between creating something and maintaining/improving it. I agree with Bob that it's possible to create complex software. But what happens when it gets in front of customers? And then when you can no longer count the number of customers on your fingers and toes? And assuming only half of them have potential ideas as to bugs and improvements, who's going to do all that and develop new features to keep up with the Jonses, or those left out from the last version due to time constraints?

Fourth, the examples brought up during the comments are all tools -- Linux, Delphi, even Quattro Pro. They're generic tools built without regard for any specific business logic. But I'd venture a guess that most developers don't work on such systems. They have to deal with automating processes that have been accreted for years on paper and informally in the brains of the workers. And even then they have to communicate with systems and coordinate not only protocols (which is what tools do) but content, even in the face of stupid implementations.

And doing all that for non-trivial businesses, with a small team, no matter what language, is a tough job. (Not even mentioning figuring out what it is you're supposed to build.) In a short amount of time? Approaching impossible.

Posted from cwinters.com; read original

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.