I’m working with a great team of developers right now, each of them has varying levels of experience and all have done some pretty cool stuff, but on the project we are working on at the moment they struggle. A big part of the reason is that the software they are enhancing was engineered from the ground up to be a complex system.
In order to design a complex system, you need complex requirements, and complex requirements abound in the industry in question. The challenge is finding the simplest solution for that complex problem. Unfortunately that seldom happens in our industry.
Because of that, the code that we are maintaining and enhancing resists us because the patterns are so thick that they form a rigid lattice. One change requires modifications all over the place.
Today I stumbed across two great posts, the first is a short and humorous one by Nick Wienholt. My wife is a bit of a TISM fan (don’t mind them myself either), but this one made me squirt water out my nose:
You’re only one dependency-injection pattern away from being a Java architect.
Priceless. Now, I can’t throw stones, I’ve used and blogged about dependency-injection patterns in the past, but was this always the best solution? I hope so, but I’m not 100% sure.
The other post that I read was by Peter Rosser. Peter posted up about his thoughts on software complexity. He certainly gave me lots to think about, especially considering our current situation.
Maybe there is a middle ground. Patterns can be useful for reducing complexity in some instances, but it doesn’t mean that your application needs to be composed of them – in fact some of the best code I’ve written has been simple procedural code.