Going Holistic

The question among developers, technicians and business people always seems to be: What is more important - functionality, security, performance, clean code, project processes, et cetera, et cetera...? As a consultant - and therefore usually an outsider to any principal discussion with any customer - I try to go holistic. That is, to touch down on as many of these things as possible. The key is to do without being overwhelmed by the sheer amount of work and/or information.

Going holistic is the act of stepping back for a second to study the solution as a whole - end to end - (insert your own buzzword here). It is an golden attempt to check "if we're missing anything". Usually, it seems, we're missing quite a bit. Whenever I talk to technicians they focus on maintanence and hardware, if the discussion is with developers the talk is on clean code, code reuse, new stuff to try out, old problems to solve and business, of course, wants to discuss functionality, ease-of-use and time-to-market. Some quite interesting things happen when you go holistic in these kinds of discussions.

Let's delve in to the example of developers talking. It's a common mistake to "forget" performance and deployment. Developers tend to gloss over the fact that code has major impact on performance. Usually the response goes something like: "We have enough problems meeting our deadlines coding the needed functionality. Let's worry about performance when we get this stuff deployed. I'm sure we can just tune the app server or whatever." Wanna go holistic on this one? I always want to do that whenever I hear something like this. I try to direct the conversion towards NFR (non functional requirements), platform dependencies (do we HAVE to use MS Access?) and caching. The discussion usually then goes on to involve stuff like performance testing, unit testing, automatic builds and whatnot.

Performance is not some kind of magic liquid you pour over the finished code base prior to launch. It's an important strategy consideration that involves choice of platform, deployment architecture, software architecture, external components and coding styles. Setting the customers expectations to performance is the key to any successfully performing application - whatever the expectations: If they are higher than what you can deliver, the application will disappoint the users! Discussing performance with the hosting department is crucial - but why don't we do it every time then?

This is what I mean about going holistic. And I try to do it as often as I can. But there are some caveats here. You can't change the world - some times you can't even change your own project dependencies. If you start talking about end-to-end, performance, or whatever high-level stuff at the wrong time, people will get frustrated. Of course, they are on a budget, they have stuff to do, code to write. They have no use for all these extra tasks and considerations. Therefore it's a tightrope walk to go holistic. You always have to have your ears and eyes open - when people start losing interest in your ramblings about the perfect application, you must stand down. Wait for another day - or maybe you are talking to the wrong people. Maybe you should mention this problem you discovered to the project manager, the boss, the lead techie, someone else.

Everyone needs to get their heads out of the soup from time to time. The need for holistic thinking is stronger the more complex your solution is. And not just in the beginning of a project. Every meeting could spur a need for stepping back and thinking: "What the... This has a funny smell!" That's when you must go holistic!