Mar 16 2008
It’s not my problem
I was MC at my sisters’ wedding recently and whilst I didn’t have a great deal to do with the planning of the wedding, I was around when my I overheard my sister talking about a particular aspect of the wedding plan. The problem was that the venue for the wedding reception was around a 30 minute drive out of town which meant that people either had to drive to the venue and not drink, arrange a designated driver or get a cab which would end up being at least $50 back into town. My sister couldn’t decide if she should hire a bus or not so people wouldn’t have to worry about organising transport home. This then snowballed into questions about if they did hire a bus, should they have it run a couple of times during the night, should it drop people off at their houses or just at central locations, which routes should it take, when should it start running, what happens if people miss the bus and on and on the questions went. The solution to the problem was fairly simple in the end. I explained to my sister that it simply wasn’t her problem. It wasn’t her problem how they arrived at the wedding, it wasn’t her problem how they got home from her wedding. All she needed to concern herself with was ensuring that there was a wedding for them to enjoy between the time they arrived and the time they left.
So what does all this have to do with software development? Well my sister thought that because this problem was somehow related to her wedding, she was responsible for solving it. Similarly, developers often think that because problems have something to do with their application, they are required to write code to solve it.
This isn’t always the case.
As a software developer, you need to constantly be aware of the problem you’re working on and be constantly asking yourself is this my problem to solve?
One example is a company I worked for insisted on getting their applications working in Firefox. This in itself isn’t a crime, except that the standard operating environment within the organisation stipulated that Internet Explorer was the only supported browser. So the developers within the company were spending hours working on getting an application to work that they didn’t even support. The solution to the problem had nothing to do with the developers and everything to do with the managers explaining that we don’t support Firefox.
Another situation is a client of mine wanted to make sure that a payroll application I was building allowed staff to go back and adjust the pay figures from previous pay runs. This was not desirable because it meant that the numbers for the outgoing pay wouldn’t match the actual outgoing pay. To ensure that the payrun data matched the outgoing pay data, it would require some extremely time consuming checks and rules to ensure that people got payed the correct amounts. After a quick discussion with the project manager he went off and implemented a new set of business rules that clearly stated that pay run data was not to be modified once a pay run had been complete and that any pay modifications had to be entered in as manual adjustments in future pay runs. It was a 15 minute decision that saved 2-3 days of development time.
Both these situations highlight the importance of realising that as developers, yes our job is to solve problems, but we should only be using our code so solve our problems and that it isn’t necessarily a bad thing to say “I’m not coding a solution to this because it’s not my problem”









