The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

The most efficient software are written by a single person

Charles Simonyi said in the mid 80's :

"The most efficient programs are written by a single person. The only problem is, it might take forever to write, and that is unacceptable. So you have two or three, five or ten, or hundreds of people working on a project."

Source : http://www.shamit.org/charles_simonyi.htm

Do you also believe that the most efficient (best?)
sofware are written by a single person (assuming that
it's a hot shot developer behind the keyboard)
Hybris
Tuesday, May 09, 2006
 
 
Absolutely. No question about it.
L. Lort
Tuesday, May 09, 2006
 
 
Yes, absolutely, I second that!
~Eric
Tuesday, May 09, 2006
 
 
I see nothing that prevents a good team that shares a single vision producing excellent software. They really have to be a team, though, and they need to be committed to their goals with a kind of selflessness not often seen anywhere in business, much less in software development.

An individual can do some pretty amazing things, and the best shareware programs are usually the efforts of one person. Nick Bradbury comes to mind as creator of TopStyle, although that product now appears to be a team effort. But to get a really high-end, robust piece of complicated software off the ground, one man or woman probably isn't going to be enough. Fortunately, there are teams that have produced amazing software. Mark of the Unicorn (Digital Performer) and Apple (Final Cut Pro, iTunes) are just a couple of examples, but there are more.
Paranoid Android Send private email
Tuesday, May 09, 2006
 
 
i have heard of several stories in financial apps how 1 (or maybe 2) people would write a piece of software. A bank or 2 would like it as customers. The problem occured is when they started expanding and trying to keep up with the customer demands and all of the nuinces. I believe Joel calls this consultingware. Before you know it, there is a team and there is spaghetti code and you have upset customers.

Am i saying that you should stick to 1 person teams? Not necessarily. If anything you should try not to be consultingware.
Patrick From an IBank Send private email
Tuesday, May 09, 2006
 
 
"Design by committee is a wry, derogatory term referring to the style of design that sometimes results when a group of entities comes together to produce something, particularly in the absence of good leadership - roughly equivalent to the age-old expression, "too many cooks spoil the broth". Its defining characteristics are needless complexity, internal inconsistency, banality, and the lack of a unifying vision."
http://en.wikipedia.org/wiki/Design_by_committee

The problem with a team (be it programmer+clients :-) is that the design tends to suffer. On the other hand, the money must come as soon as possible, which means that we have a double-edged sword. Thus, when you have a team + managers + clients + shareholders + ..., you become inefficient. If large companies were efficient, they would build, not buy, like when they buy other companies together with their softwares. :-)

I know that the first version of Visual Basic had a team of 5 people on Microsoft, but it had been bought from a developer I think.

If Microsoft were efficient, they would have created the best development tools in the world, but no, their tools are only good enough.

Part of the efficiency of single developers is that they have fewer expenses which means that they can keep working on their projects for as long as they care. When you have a team to feed, the pressure can make you take shortcuts and your software will suffer in design and maintenance.
Lostacular
Tuesday, May 09, 2006
 
 
What do we mean by "efficient" here? Is it efficient for the user, efficient for the developer, efficient for the developer's company (if any), or efficient in terms of CPU cycles and ememory used?

If the second or the last, I agree wholeheartedly.
Raj Chaudhuri Send private email
Tuesday, May 09, 2006
 
 
I appreciate your points, Lostacular, and for the most part I agree. "No one," the old joke goes, "ever designed a monument to a committee."

Still, I find it ironic that you cite evidence from a Wiki in support of an argument against design by committee. Wiki has to be the absolute best example ever of successful design by committee. :)
Paranoid Android Send private email
Tuesday, May 09, 2006
 
 
Consultingware - I have seen several good mISVs destroyed by having too many clients and trying to customize for each one.

The code was not modularized enough for there to be mostly shared code.

Result: 50 separate piles of spaghetti. And very spoiled customers who expected major changes for almost free.

Both companies were eventually run into the ground because there never seemed to be enough time or resources to do a second version of the product, so eventually it slipped into obsolescence and the customer base started to shrink. Eventually, lights out.
dot for this one
Tuesday, May 09, 2006
 
 
It depends on the purpose.

If you are writing some shareware that is your own, then yes. You know the code, and don't need to communicate that with someone.

Inside a company. No. I've seen companies with islands of expertise, and it's disastrous. One guy looks after the stock control, another the ordering system, another the billing system. Someone goes on holiday and the billing goes down, and the stock control guy has to work out how the billing works, and do it very quickly.

I've heard that Toyota deliberately rotates people to ensure that knowledge gets spread around.

There's also the question of design reviews. In companies I know where I've had the option to bounce my designs off people, I've ended up with something better.
Tim Almond Send private email
Tuesday, May 09, 2006
 
 
"Wiki software originated in the design pattern society as a way of writing and discussing pattern languages. The WikiWikiWeb was the first wiki, established by Ward Cunningham on March 25, 1995, as a complement to the Portland Pattern Repository. [2] He invented the wiki name and concept, and implemented the first wiki engine."
http://en.wikipedia.org/wiki/Wiki

Sometime ago, I read some of the history of the Wiki. Ward Cunningham had a lot of personal insight that he put to create the Wiki. He first tried some of his ideas using a technology from Apple called HyperCard.

That is, the maintenance of the Wikipedia can be a work of a committee, but it was a single developer that created the software.
Lostacular
Tuesday, May 09, 2006
 
 
I agree that a single developer can many times outperform the "programming committee". But you really need to have a seasoned developer and not just some rookie who hasn't had to live through the pain of a poorly written system.

I've worked for a couple of companies that could never get a new product out the door because the committee spent too much time discussing programming conventions or ended up arguing over every little thing. Many times it is just better to have a single person just make a decision and move on (even if it isn't the most optimal way to do something) than to spend countless hours arguing over the best way to accomplish the task.

But since a lot of us out here are very keen on the idea of the uISV, you would expect the responses here to be weighted slightly toward the belief that the "lone gun" really can write a successful product.
anon
Tuesday, May 09, 2006
 
 
I have to agree with this concept. Personal projects of mine that are 80,000+ lines of code or more written *solely* by me tend to be projects would take at least 3 or more developers to reproduce in the same amount of time. They also tend to be the most amazing projects of mine. Note that while LOC does not mean much, it does give a ball park idea as to how large the project is, and I think around 80,000-100,000 loc is about the limit for a single developer to crank out a product in a reasonable amount of time. Note that any good developer likely can write a project with 80,000+ LOC, but the problem then becomes the amount of time…..

The coherency, and beauty of design cannot be beat when you have one good designer and coder doing all the work.

After all, the whole issue of software development revolves around communication of what the design is. And, with one person, often that design is in ones brain. The speed at which the brain can work is amazing. The instant you must offload data and design from a single human brain is the instant issues of scalability and communication come into play. The brain is VERY good with communicating with itself!! Too bad we can’t network our brains together!!

The problem of course becomes commercial size and scaling.

For example, could you build a house all by yourself if you are a good carpenter? The answer is yes, but who is going to wait 15, or 20 years for that house?

So, you put 20+ people to work on the house, and it is done in less than a year. Software does not scale like building a house, but it is the only choice we have to deliver products in a *reasonable* amount of time when MORE then one developer is needed. So, that carpenter can build shelves, or perhaps cabinets for your kitchen. However, a whole house by one person can’t deliver in a reasonable amount of time. The same goes for software……

So, one developer is the best..but not when you have an amount of work greater then what the market (or customer) is willing to wait in terms of time….

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Tuesday, May 09, 2006
 
 
I've also seen several enterprise products that you could really see the impact on quality of bringing on more developers.

One product in particular was started by two guys and had a very consistent base framework. Unfortunately, the product saw huge success early on and the company brought in a bunch of other developers to handle the load. The product quickly went down the dumper. You could always tell what code was original and what had been tacked on by the "committee". Overall the product sold really well so the impact really wasn't that bad. But the product quickly developed a reputation for having quality issues which limited its long term sales potential.

Incidentally, the company that wrote that product ended up being bought out by a bigger player for about $60 Million. :) I guess that shows that SOMETHING is better than NOTHING (even if the quality is not the best).
anon
Tuesday, May 09, 2006
 
 
Raj :

By efficient charles meant, beautiful & eglegant internally (use of the most
appropriate algorithms & data structures) but also for
the user featurewise, speedwise and also in terms of UI, ease of use of the application

Below are a sample of efficient programs from the 80's era
(do you guys still remember those days!)


SIMONYI: I have great regard for the competition. I've had the pleasure of meeting Bob Frankston and Dan Bricklin [the founders of Software Arts and writers of VisiCalc] at a couple of trade shows. I once met Jonathan Sachs [a founder of Lotus Development Corporation]. But unfortunately we don't move around much and not many of these programmers have a reason to come to Seattle. Bruce Artwick [who wrote and designed Flight Simulator] sometimes visits, and the guys at Apple, like Bill Atkinson [one of the Lisa programmers who later developed the MacPaint program for the Apple Macintosh computer] -- I think Atkinson is the greatest--and Bill Budge [who programmed Pinball Construction Set for Electronic Arts]. These guys are all great.
Hybris
Tuesday, May 09, 2006
 
 
No by me. I don't think I've ever written the most efficient software.
son of parnas
Tuesday, May 09, 2006
 
 
Yes and no. One can break a large system into its smaller parts. One developer can develop single handedly one subsystem.
Dino Send private email
Tuesday, May 09, 2006
 
 
"A camel is a horse designed by a committee"

- Sir Alec Issigonis, designer of the Mini car
Bluebeard
Tuesday, May 09, 2006
 
 
I think this warrents the question as to what is the scope.  I doubt I could write the Linux kernel from scratch in the same amount of time it has been developed and just look at it today.  We have some of the largest corporations talking about it, using it, and competeing with it.
~Eric
Tuesday, May 09, 2006
 
 
I agree with those who have suggested that the SCALE of a project should be the basis by which the number of developers are applied...

For small-scale database applications, for example, certainly a SINGLE developer is more than appropriate....but if you are developing an enterprise-based project, deploying a single developer would be utter nonsense.....

.....one dynamic that has NOT been discussed here is the extent to which functionality within an application applies. I would proffer that software development in the future must re-evaluate what it means to develop a "whole" application.

By "whole" I mean that functionality must be re-evaluated. The question here is to what extent should the boundaries of software applications in terms of functionality be applied? To continue to develop, for example, an application that continuously becomes updated and upgraded will eventually create bloated, slow-performing software that defeats the purpose for which it was initially intended.

How much functionality within a single software application makes sense to implement? Does it make sense to develop software so complex that it becomes counterproductive to use? How about software so imbued with functionality that its performance becomes compromised resulting in substandard software?

I believe what defines powerful software is that which is robust, performs and processes data quickly, and is highly functional and INTUITIVE in its utility.

With limitations today on CPU processing cycles, I believe re-defining incorporated functionality within an application will become a very important topic for discussion in the future of software design and development.
Brice Richard Send private email
Tuesday, May 09, 2006
 
 
"The coherency, and beauty of design cannot be beat when you have one good designer and coder doing all the work."

It can be beat by a team of two good designers and coders :-)

I am a sceptic in  regard of pair programming, but from my personal experience, pair design is very efficient way to achieve coherency and beauty.

As for scalability, I do not believe (do not ask me where I got that magic number) that effective development cannot be done by a team whith more than 50 developers.
Euegene Send private email
Tuesday, May 09, 2006
 
 
A horse is a camel designed by committee.

Arab proverb [by me].
Karel Thönissen Send private email
Tuesday, May 09, 2006
 
 
Lostacular
Tuesday, May 09, 2006
 
 
"The most efficient programs are written by a single person."

Of course, he neglects to mention the collary to that observation.  Some of the worst designs ever were conceived by a single person as well.

I think it's safe to say that the most efficient programs are written by the best programmers.  In a group of size n, when n = 1, you have no idea what you're gonna get.  You could have a 1st percentile coder.  You could have a 99th percentile coder.  Obviously if you get the latter, you're likely to get a very good program.

But when n is large, the law of large numbers take over, and even though in some companies there is some adverse selection against poor performers, it usually isn't enough to move the average skill of the group much off of the 50th percentile.

So there's good news and bad news.  The good news is, that in a large group, the output you receive will be fairly predictable.  The bad news is, it will be predictably mediocre.  It won't compare to the output of a single, highly skilled developer, but on the other hand it will be better than about 50% of lone-wolf coders.

Pick your poison.
Alyosha` Send private email
Tuesday, May 09, 2006
 
 
If the single person on the project is a very good programmer then it's definitely much more efficient having just that person doing the coding (...also assumes that the software can be completed by a single person in the given time!).

Conversely, if the person is a crappy or average programmer then No, it's highly doubtful the software will be efficient (memory/CPU wise or productivity-wise). 

And of course, if the software is a huge project, like writing Vista, then it's definitely not efficient to have a single person coding it.
Moobar
Wednesday, May 10, 2006
 
 
For a fascinating theory on why the upper limit of an effective development group might be 50, read this:
http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html

Personally, I'm in favor of small teams, as long as you have the right people.  I've seen too many examples of two heads being better than one, ideas bouncing off one another in a chain reaction.  At the same time, I think there needs to be a single individual in charge, to provide an overall direction and consistent style.

The 5 to 8 ideal team size from the article seems about right.
Mark Ransom Send private email
Wednesday, May 10, 2006
 
 
Personally, I would go with the notion that a single programmer, or small team, is more efficient in producing usable, elegant code than a larger team.  How much larger, I am not sure. 

This logic doesn't hold up though if you can make your problem into a set of parallel tasks.  Assuming you could do that, you could easily find 5-10 programmers that don't need to know what the others are doing (no communication costs), that are in the top 99th percentile and set them to work on each their own slice of the code.  I am presuming, also, that the amount of time you spend parallelizing the problem is smaller than the amount of time it would take a team of monkeys to bang out the code randomly.
Joshua Volz Send private email
Thursday, May 11, 2006
 
 
In my own exprience I'm always much more effective working alone. If I'm in team then I have to spend 1/3 of my time for pair programming with junior developers. It's very boring. Ah, also fixing conflicts before commiting in version constrol system...
ij
Tuesday, May 16, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz