The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

large retail software design/dev process

I've never worked at a software house, my development work has always been in banks, brokerages, etc.  So I am curious to know how large computer companies develop their software.

For example, Apple just came out with aperture.  It is designed not other developers (it is a photography related software).  It looks beautiful.  It has to be extremely fast due to the nature of digital photography.  At least from the screen shots, it looks like it allows a great deal of image manipulation without jumping from one menu to another.

Any way, are there any books which talk about design and development process for something like aperture?  Once it has been decided that a software needs to be created, how does the process continue from the technical side.
-How are 'requirements' gathered
-How is the look and feel decided
-How is the feature-set decided and how is it limited
-How many people work on these projects, how long does it usually take, who has what roles, how is the project divided up.  How is communication maintained between developers.

Once again, I just use 'Aperture' because it looks like a product designed from scratch, looks nice, is a large project, etc.

There are plenty of books about programming, project management, documentation, requirement gathering, etc.  But I want to get a real feel for the process, beyond just bits and bytes.  Beyond development methodologies.

Any ideas?  Thanks!


Wednesday, October 19, 2005
I can't speak to Apple's process specifically but I can give you a few tidbits from a major, well-known company that I worked for that was at the same level.

Usually, it is a humongous team.  You might think that it is a couple of amazing guys who sit down and just do the entire thing themselves.  That's not it.  It's a huge bunch of people who do tiny pieces that they incrementally improve over a long time (2-3 years).  They also pull in code from the rest of the company; for example, the image manipulation in Aperture is probably some ancient Apple proprietary library that was started in 1987 and just has been slowly refined over the years.  Often, a lot of outside code is licensed and incorporated to do a lot of different things.

The codebase is usually sort of yucky and difficult to look at.  Each developer pretty much does his own thing and there's usually very little effort to make code consistent.  It's also usually hard to build.  But, after a developer has been there a few months, he starts to find his way around.

Now, there are usually a few amazing guys.  They might not be able to write Aperture all by themselves but they can do a lot.  They often are leads of different areas (although there are always a few dumb-dumbs who are leads, too).

Many times, the look and feel is a combination of the developers, the artists and actual usability lab experiments.  Good artists can make the worst code look like a million bucks: it's just bitmap manipulation in the code, after all.

It's a tumultous process: developers just write code to do something cool and seemingly useful, then managers say, "How about this instead?  Or can you make this look better?"  Some teams do specs, some just start writing code and some do a little bit of both.

Often, there are a few hidden failed projects along the way.  Maybe the Aperture team created something called Photolab first but it sucked so bad that management decided not to release it.  Then, somebody said, "Why don't we pull those image libraries out and cut out all these printing features and just leave image manipulation?  We can call it Aperture."

When you join as a developer, it might take you even up to a year to become useful to the team (since the codebase is so chaotic and messy).  This is natural and expected at a lot of companies.  There is usually a core team of people who have worked there for a super-long time and then a bunch of new people who just do fiddling little tasks.

Probably, in the end, you'd be unimpressed.  I expected to see magic when I joined the well-known company, only to realize that it is really just a lot of hard work, a lot of time spent on details and a massive amount of people thrown at the problem.  I expected to learn from some real amazing Win32 developers when I arrived but later I realized that I was the one that had Win32 down cold and those guys just fiddled with it, using books or just brute force.  (But with artists who can make great art even if the underlying code is sorta junky.)

It's worth seeing once.  It's even worth doing for your whole career.  But, if you expect it to be a developer Shangri-la, you'd probably be disappointed.  (Sorta like video game development, I hear.)
Daniel Howard Send private email
Wednesday, October 19, 2005
excellent post!
Sassy Send private email
Wednesday, October 19, 2005
Thanks for the response.  I'm not really looking to join a software company, I was just curious how these projects are run.  How such huge code bases are managed, how its tested, etc.  Partly I became curious because there are many companies that produce pretty large-scale software with just a few thousand people (google for example), yet so many large banks with almost infinite IT budget have oceans full of people but always seem to run behind.
Falcon Send private email
Wednesday, October 19, 2005
Great reply, Daniel. Mirrors my experience at a 20,000 person defense contractor. Except they skip the artists and testers and put a CMMI straitjacket over everything so the government auditors are appeased.
Geronimous Send private email
Wednesday, October 19, 2005
The dispartity behind "google" and banks is because brilliance isn't distributive.

If your choice is between hiring one REALLY smart person or ten average people, google will pick the smarty and the bank will hire the ten average people. (Because they're cheaper individually, and this way the manager gets a bigger team and hence is more important within the organisation.)

But 10 average people don't equal one smart person; certainly not for things like architecture. Sure, if you want to do delegation code in Java, you just need someone who can type reliably.

Inventing new search algorithms (or anything else really new) isn't something average developers do, no matter how many of them you have.

Most actual software is developed like this;

A customer arrives, tells the salespeople what they need. The salespeople pick a number. It's got to be less than the "WHAT??" number of the customer, but enough that they don't have to work hard to make this months sales target.

After the customer and the salespeople have agreed on a price, the customer meets the developers to tell them the specifications.

After the developers have punched the sales team for once again selling something they can't make for that price, they cobble together the best approximation they can given the price limitations, hide any excess costs in some other project and deliver partially working software months late. They then delete the source code because hard disk space is so expensive they can't keep old projects around, avoiding any archive management issues.

The salesteam hits their targets and get given slap-up meals and expensive company cars. The developers just get a slap in the face and their cards for being the underperforming dogs that they are.
Katie Lucas
Friday, October 21, 2005
"If your choice is between hiring one REALLY smart person or ten average people, google will pick the smarty and the bank will hire the ten average people."

I hate to disagree (and I don't have any direct knowledge of Google specifically) but this is mostly a myth.  At most shrinkwrap or famous Internet companies, I'd characterize the employees as "B" programmers compared to the "C" programmers in the rest of the industry.  The average guy is a cut above but he still pales in comparison to the "A" programmers at "C" companies.

Companies that hire thousands of employees really can't hire all "A" players, even though they might fool themselves and everybody else into believing so.  From my (limited) experience, I'd estimate that a company like Google maybe employs 10 "B" programmers for every "A" programmer.  And, usually, there's another 5 "C" programmers and 1-2 "D"-"F" programmers.

That's a better average than a bank.  But the best programmers at a bank are likely better than the average programmer at Google. 

It's hard to hire lots of people, no matter who you are.
Daniel Howard Send private email
Friday, October 21, 2005

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

Other recent topics Other recent topics
Powered by FogBugz