Software development isn’t easy. And the bigger the software gets, the harder it is to build right from the ground up. A string of high-profile failures has given us a timely reminder of this. But it’s not hopeless — here are five things to consider to bump the odds in your favor:
1. Great software is never built on a poor architecture
The only way to build a large project is to divide and conquer. But ten teams working in ten different ways will just produce ten times the mess. The bigger a project gets, the more important it is to build on the best architecture and tools, modularizing where it makes sense without simply introducing more discrepancies and more complexity. And the more people working on top of an architecture, the more important that it doesn’t introduce obstacles that every developer may find different ways to avoid.
2. Generated code is terrible
Many situations land programmers with large amounts of tedious boilerplate code. The gut reaction is to code-generate your way past it. But if you think a junior programmer writes bad code, you should see a programmer try to program a computer to program. It’s just as convoluted as it sounds. Worse, it has to be done over and over again, and it’s one way to guarantee that some large chunk of code is rarely up to date. Whether it’s persistence or XML or other boilerplate code, there’s a different set of tools that will eliminate the tedium with better code instead of worse code.
3. Best practices aren’t always best
If you want to be really cruel, you can write terrible code that adheres to multiple best practices, and just watch an architect splutter. The problem is that many individual best practices don’t make sense when used outside of their associated tools and frameworks, or when used in combination, or when otherwise taken out of context. Part of what makes experienced programmers better is that they can review all the tools and practices at their disposal, and use their judgement to select the right combination.
4. Software without automated tests is just a pile of code
A large project is built, never adequately tested, and rushed into production. It doesn’t work well. Why is this a surprise? But testing is also tedious, and requires a whole additional staff. That is, if you don’t automate it from the beginning. Your computer is perfectly capable of driving an application with simulated load, an actual Web browser, or real-world integration requests. There’s no reason not to build a comprehensive automated test suite to ensure the software operates as intended. And the more people who have their hands in the code, the more important it gets.
5. Integration begins with testing
Projects with many integration points tend to have a large number of interested parties, many of whom may be developing their parts of the system in parallel. Then everybody finishes, and guess what? It doesn’t all work together. But there’s an easy way to avoid that. If everybody starts by providing simulated requests and replies then testing can begin immediately, and each group can phase in real implementations over time. Each system gets immediate feedback as to whether anything’s breaking, and there’s much less debugging required to fix a small change from a working state.