More Complicated Than It Has To Be
True to my word – here’s more posts after losing out to Matt’s awesome post on Been There, Done That. Cheers and best of luck, Matt!
A Dirty Phrase
“More Complicated Than It Has To Be” is about as dirty a thing I can imagine saying to another developer in relation to their code or solution to a given problem. Sometimes that’s a result of ignorance of a simple helper method which does the thing they’ve coded, or maybe they’ve decided on an over-engineered solution when a simple file storage could have solved the same problem as easily. Either way, the result is some wasted effort and time duplicating work or decreasing the amount of value our customer gets out of the software we’ve provided.
I’ve spent a large portion of my career working on a Time and Materials project, providing software, process guidance and general support for the same client, which has certainly colored my opinion on the topic. The less time I spend writing software, the cheaper and better off your system will be – since I’ve taken all the small swipes at problems you might be encountering. As an engineer, it’s my job to work with you to figure out what problems you’re having and what I can do to fix them. Many times, this amounts not to reworking your entire process, but to making minor tweaks to alleviate some stresses contributing to that migraine.
You don’t start with brain surgery for a migraine; you start with some aspirin and rest, and if the pain continues you seek other help. If the simplest thing doesn’t work, you move on to the next simplest that might solve the problem, looking for improvement along the way and iterating. Having a wife with glasses, a visit to the eye doctor and a new prescription tends to take care of migraines and is so much more palatable than brain surgery.
The Little Things
If you didn’t catch it, I half referenced one of the battle cries from agile design – “Do the simplest thing that could possibly work.” But how do you know what that simplest thing is? Take some time looking. Start at the beginning and identify the steps that take the most time or the most work and see if you can improve them. Sometimes it’s as simple as changing/adding a new format to your system output to prevent the users a large, painful bit of work churning through an Excel document. Sometimes it’s as simple as inverting a boolean to make the page more readable. Sometimes it’s as simple as adding another column to that grid so they have all the data they need in one place. No matter the case, making these small changes will often make users happier with what they’re being asked to do, increasing their efficiency and happiness when performing that task.
The Big Things
What if the little things won’t solve the problem? Then start looking at the bigger chunks. We start looking at how we can automate various portions of the process to something more manageable. Once you’ve looked through all the small things that might help, you have a better idea of what success looks like on the big thing. If the users need to see column X next to column Y to make a decision – it better be in your output. If the users are making format changes and forwarding your data to another system, you should make your output match the input of that other system, or (better yet) remove the user from that step. Create a job which forward that data on request, weekly, monthly or whatever works with their current process – effectively removing the step from the client’s mind.
Making it Happen
The key is involvement and feedback. Time and time again, I’ve found our success hinges, not on our technical chops, but on our ability to find the problem in the haystack, and get to the small changes which makes the process tolerable. Iterative improvement gives users hope and increases their involvement. They’re more willing to point out the small things when they know you’re listening, and they’re happier knowing that you’re looking to make things better without charging an arm and a leg. Telling a client that you think 5 minutes time could solve a problem, as opposed to a month long project will earn you respect and possibly some future work. If you keep the customer’s needs in mind, look for the small things and incorporate feedback, your project will succeed and be all the better for it.
There are my fellow blog battlers posts on this topic – search for the title of this blog and you’ll find them as well as my sources: