Comment Re:Buzzwords aplenty (Score 1) 236
I see what you're saying, and I understand where you're coming from. I wrote air traffic management software for a while, and if you want to talk 'zero bug tolerance', that's their highest priority. I now work in an agile shop, and while it is more chaotic than traditional practices, there are ways to direct agile methods so that you get clean, solid, and documented software. We're a small (35 person) company that writes an on-demand enterprise system. We've got a couple thousand customers and our app has had 4-5 nines uptime over the last three years.
The key is to have one or two guys in charge who look at the big picture and decide how the program will be designed. We've got an architect managing interaction of all the hardware and software pieces. We've also got a project manager that goes more specifically into what is going to be done and which functionality will go into which components. At the start of a project, we get together, divide up user stories, and discuss generally how things are going to be implemented. This keeps your cowboy developers from throwing code into places it shouldn't be.
After the initial planning, it's on the developers to keep the quality and documentation going. Pair programming helps make sure that people aren't deviating from the plan. Two practices that make keep code clean and reduce bugs are unit tests and code documenting. If you design unit tests before you start coding, it's easy to see if your code is breaking some other piece of the app. One other key is that you actually have to use those tests. There are tons of places that write tons of unit tests, but don't make it easy to test the whole system at once. Get a daily or, better yet, hourly build and unit test run going so problems show up while you're working on the code. If you document the code as it's written and in the code, you not only help other people know what's going on, you make sure YOU know what's going on. Our rule of thumb is that if you can't understand what's going on from the comments, you either wrote lousy code or commented it poorly. At the same time, the architect is documenting the big picture, so both the general view and the specific code are maintainable.
We've got a small team and an app that we're adding to incrementally, but I think the same practices can be applied to larger projects. If you divide your group into teams and use agile practices on a small scale, having architects and management coordinate between them, a lot of these practices will still be valid.
That's my spin on it, I'm curious to hear from people who have used agile on large scale apps.
The key is to have one or two guys in charge who look at the big picture and decide how the program will be designed. We've got an architect managing interaction of all the hardware and software pieces. We've also got a project manager that goes more specifically into what is going to be done and which functionality will go into which components. At the start of a project, we get together, divide up user stories, and discuss generally how things are going to be implemented. This keeps your cowboy developers from throwing code into places it shouldn't be.
After the initial planning, it's on the developers to keep the quality and documentation going. Pair programming helps make sure that people aren't deviating from the plan. Two practices that make keep code clean and reduce bugs are unit tests and code documenting. If you design unit tests before you start coding, it's easy to see if your code is breaking some other piece of the app. One other key is that you actually have to use those tests. There are tons of places that write tons of unit tests, but don't make it easy to test the whole system at once. Get a daily or, better yet, hourly build and unit test run going so problems show up while you're working on the code. If you document the code as it's written and in the code, you not only help other people know what's going on, you make sure YOU know what's going on. Our rule of thumb is that if you can't understand what's going on from the comments, you either wrote lousy code or commented it poorly. At the same time, the architect is documenting the big picture, so both the general view and the specific code are maintainable.
We've got a small team and an app that we're adding to incrementally, but I think the same practices can be applied to larger projects. If you divide your group into teams and use agile practices on a small scale, having architects and management coordinate between them, a lot of these practices will still be valid.
That's my spin on it, I'm curious to hear from people who have used agile on large scale apps.
