Tuesday, January 29, 2008

Engineering Problems on Large Software Projects

Size matters.

If you are on a large software project, you are going to face a bunch of problems that you just won't see on small developments.

And by large projects I mean multi-programmer developments based on a library of modules written over a number of years.

I said, "based on a library of modules". If you don't make your code strictly modular, you've already failed. That isn't always easy, especially when it's the day before a deadline and it's far quicker to bodge in a fix.

Given that you have a bunch of modules, with different versions of them used over several products or versions of the product; maintaining a formal build process is essential. Builds should be numbered or labelled and it should be trivial to reproduce any previous build from you version control system (you do have a version control system, don't you?)

Some formal structure to record who has what build is also needed.

Code re-use generates code as structural patterns are needed to ensure your new module can communicate with the existing functionality.

And with all this extra interfacing code, finding the guts of a particular function or class becomes a real issue. Although Google intranet search tools can certainly help here.

If you've only ever hacked together 2-day projects in your bedroom, these issues will be alien to you. Anyone who's worked in a real software house should be familiar with most if not all of them.

Friday, January 25, 2008

The new SI units

"Have you heard? The smiths won the lottery last week and the house they're looking to buy has a garden the size of 2 football pitches!"

But a football pitch can vary in size from 4,050m2 to 10,800m2.

And new mp3 players are often quoted as being able to store a certain number of songs, for example the 1Gb iPod shuffle can store 240.

But is this 240 average 3½ minute radio edits?

Or 240 20-minute drum and bass epics?

Or does it even matter?

Using a commonly known "thing" means far more to the average user than an exact figure. Approximating information is a good thing.

If you're only presenting information with 1 or maybe 2 significant figures, do you really care how accurate the unit is?

Monday, January 07, 2008

Company Culture

We hear about company culture all the time, but until you've worked in a few companies it's hard to understand how two software development houses can feel so different to work at.

The Team


A team based company will normally separate groups off into their own little rooms or sections of the open plan office. There is likely to be a hierarchical structure to each team with a one or two Chiefs and then many Indians.

Games companies typically tend to have this structure as game building is very much a large team activity, especially with the modern consoles and large budgets that accompany them.

The Consultancy


Consulting companies tend to treat staff as experts in their field. The company understands that if their staff can't solve a problem, they'll find someone who can.

In this type of company you'll be given freedom to work and you'll be treated like an adult. But you may be left to just get on with it.

This type of company would tend to employ someone with experience rather than a fresh graduate and the office is likely to be fully open plan.

The Start-up


Small, agile, and with time to market a priority, start-ups can be fun, energetic and hectic. If you're lucky enough to have an office you'll be sharing it with just a handful of others, some of whom may have experience but all of whom will be passionate about what they do.

Expect to roll out core software on Monday.
Explain it to your client on Tuesday.
Fix a bug in it on Wednesday.
Deploy a fixed version late Thursday evening.
And spend Friday afternoon in the pub with the directors celebrating a great week.

Don't be surprised if you get asked to help build the company website or install a company-wide version control system as the company will be too small to have a dedicated expert in that field.