I’ve been responsible for projects of widely different sizes and complexity. From small production jobs – with no real software development (just visual design and integration) – through to large scale application developments, which we’ve then need to live with, to maintain and develop. And big projects, especially products (that need to be reused), aren’t scaled up small projects. They need to be managed differently not just because the projects are more complex but also because you will need to be able to live with the code for years to come.

Developing a large application isn’t the same as developing a small application. For starters large projects are significantly more complex than small projects – they have more interdependencies, there are more unknowns, indeed more unk unks. A project that is three times as big isn’t three times as complex – its 12 times more complex, at least. As Steve McConnell puts it, just because you can build a doghouse doesn’t mean you can build a skyscraper.

People who have written a few small programs in college sometimes think that writing large, professional programs is the same kind of work-only on a larger scale. It is not the same kind of work. I can build a beautiful doghouse in my backyard in a few hours. It might even take first prize at the county fair’s doghouse competition. But that does not imply that I have the expertise to build a skyscraper. The skyscraper project requires an entirely more sophisticated kind of expertise. The difference in complexity between student programs and professional programs can be just as great, and non-professional programmers -underestimate the difference in required expertise at their own peril.”

And to make matters worse, if you’ve not attempted to build a doghouse, skyscraper or fort before it’s likely that your estimates will be rubbish – since its likely that when planning your work – you’ll miss off important tasks, underestimate unfamiliar tasks, that so of thing. Clearly having team members that have worked on similar applications before helps, as does adopting an agile project management approach.

Agile software development isn’t necessary with small projects – because its reasonable to assume the requirements are stable, there shouldn’t be any unk unks and you’ve probably built a dog house before. But as applications get bigger, as projects become more complex, those assumptions don’t hold true. And you need to able able to manage the new information as it arises. But that’s not the whole story.

The code also needs to be easily maintained by your development team – they need code they can live with – and that doesn’t mean the team that build the application, because if you are building a product that will be used, maintained and developed over a number of years the software engineers that end up looking after the code won’t be the people that wrote it. With small projects – the code can usually be treated as throw away code – there’s no desperate need to supported it.

Clearly some technologies make writing supportable code easier than others. For example, while there is nothing inherently wrong with PHP – indeed it has many advantages, its easy to learn and quick to develop with – its all too easy to end up with spaghetti code, because PHP promotes conflating the business logic and presentation – this can make it painful to maintain, extend or debug. As Tim Bray points out:

…based on my limited experience with PHP (deploying a couple of free apps to do this and that, and debugging a site for a non-technical friend here and there): all the PHP code I have seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.”

Don’t get me wrong, I’ve nothing against PHP you can write maintainable PHP code. The trouble is its also easy not to – so depending on the experience of the team it might be prudent to chose a technology that promotes good practice. You will want to extend the application – to deal with new requirements – so architect your application to make it easier to extend.