Enterprise systems for geniuses
The systems that I manage the builds of are business critical systems. They're not generally all that interesting—they handle invoicing, purchase orders, stock control, debt recovery and other such tedious, but important, business processes.
This is definitely not the glamorous end of the software industry.¹ [1I used to have a digital production house which was a lot more glamorous. Being able to say things like “Well, have you seen that TV advert where … I wrote the software that did that” is going to get you looks of admiration. Whereas,“You know those telephone bills you get? I build the systems that make those,” is going to get you a long tirade on the injustice of long-distance telephone charges and international roaming fees.Such is life.]
These systems do have one very important and interesting feature though—if they don't work then your client is in big trouble.
And if they're in big trouble so are you.
FOST.3™
Who hasn't heard that such and such a system, or framework, or management procedure will sort out all of your problems and bring your project in on time—guaranteed? It means you can work smarter and not harder and other such excellent marketing phrases. I'm sure we all have. Be agile, be extreme, become at one with the objects, re-use your code and mind the smell—these are all on the path to easier software development.
The scary thing though is that as much as we all know it isn't true, we still want to buy into the dream just one more time, because, maybe, this time, it'll work.
Well, FOST.3™ isn't about reducing complexity. No matter how much you learn to use it, no matter how much you study the work practices and no matter how smart you code and talk to your customers you'll still have more complexity to deal with than you want.
But actually that's fine, because frameworks; management techniques; object orientation; functional programming; closures; extreme, agile, non-odorous programming; and all the rest of it aren't about reducing complexity, they're about managing complexity.
When you architect something you can't make the task less complex² [2Although you can certainly make it more complex.], but you can, and you do, have the power to decide where to put that complexity so you know where it is and can manage it effectively.
The rest of this book, at heart, is about how to manage that complexity. I'm not offering any silver bullets as I don't think they exist. If the business is complex then you will have a complex system to support it. Even simple businesses are surprisingly complex when you look at them. Is this a problem? Only if you don't give yourself the tools to manage that complexity.
Agile and Extreme and whatever
A lot of the concepts that I talk about will sound like agile programming or extreme programming. I must admit that I haven't really read up too much about either as a doctrine (although I have read Extreme Programming). The techniques that I push here are mostly things that I'd been teaching in object oriented training courses since the early 1990s, several years before any of these books had been written. The trick is to understand that these techniques aren't part of a dogma, they're part of the evolution of our craft as software engineers and architects.
The major attack I make is against the waterfall model of development and monolithic projects. Neither work in the real world, but now everybody knows that. Is the battle won? Yes, it's been won, but the victors haven't always understood why they won.
I don't know if agile or extreme works for you or not. To be honest I don't really care. What I do care about is delivering to customers what they need and what they'll pay for. I never won a contract by extolling extreme or agile development, but I won many by calmly telling customers how the systems I would build for them would fit in to their business and the new opportunities the system would grant them.
So, if I sound like I'm being agile or extreme then think less about the doctrine and more about how to satisfy your customers. They pay your bills.
A final note: You don't really need to be a genius to build enterprise systems. The most important thing is that you care. Caring about the outcome is worth at least fifty points on any IQ scale you care to mention. The second most important thing is that you take your time to think everything through properly and do your background research. That's worth at least another twenty five points.
Pages
