I don’t like using the a word. I never want to catch myself saying anything that could be construed as: ‘methodology X says we should do it this way’. Especially when it comes to engineering practices. These kinds of things should stand on their own really. In fact, I’m going to try and steer clear of any specifics in this post and speak to a larger trend.
When working through an issue or a new feature, regardless of what environment you’re coding in or what language you’re using, there is probably a ‘hard way’ to work through the issue/feature. I don’t mean this in terms of level of effort. I mean it takes longer for whatever reason. It may even be an uglier solution. I’ll give an example. Let’s say you’re adding a new feature to a web application. It’s not a big feature, maybe just adding the ability to search off of a new set of values. The easier way is to find some kind of quick feedback. A way to implement the new search and find out quickly if there’s an issue. I’ll stop short of saying ‘write a test’ for the reasons mentioned above. However, instead you make the change and fire up the application server. You try the simple feature and it doesn’t work. You forgot something simple. You fix it, bounce the server, and try it again. Still doesn’t work. Rinse and repeat ad infinitum.
To the outside observer, this certainly is ‘the hard way’ to do it. Because of the amount of time it takes to restart the web server and click through to test the feature. It takes more effort than some other means with a shorter feedback cycle. But to the person using this approach is it really ‘the hard way’? The way they are doing it requires less thinking, and while they’re waiting on the server to bounce back up they can check reddit, failblog, or have an impromptu sword fight. To put it another way, it takes longer but requires less effort.
Of course, at this point someone could start throwing out the word ‘lazy’. But let’s take a more sympathetic approach. Why are they doing it this way? Why do they want to think less? Maybe they’re burnt out? Maybe they feel the project is out of their control and there is no reason to put in a lot of effort. That its better to save their brain power for the new programming language or framework they’re learning in their spare time. Maybe they aren’t getting enough sleep. They probably know deep down that its not really the most efficient way to do it, but they’re tired. Emotionally, physically, or even subconsciously. I’ve certainly felt that way before.
Maybe the approach isn’t convincing your developers to do things the more efficient way. Maybe its better to be more sympathetic and find out why they’re doing it the easy way.
When working through an issue or a new feature, regardless of what environment you’re coding in or what language you’re using, there is probably a ‘hard way’ to work through the issue/feature. I don’t mean this in terms of level of effort. I mean it takes longer for whatever reason. It may even be an uglier solution. I’ll give an example. Let’s say you’re adding a new feature to a web application. It’s not a big feature, maybe just adding the ability to search off of a new set of values. The easier way is to find some kind of quick feedback. A way to implement the new search and find out quickly if there’s an issue. I’ll stop short of saying ‘write a test’ for the reasons mentioned above. However, instead you make the change and fire up the application server. You try the simple feature and it doesn’t work. You forgot something simple. You fix it, bounce the server, and try it again. Still doesn’t work. Rinse and repeat ad infinitum.
To the outside observer, this certainly is ‘the hard way’ to do it. Because of the amount of time it takes to restart the web server and click through to test the feature. It takes more effort than some other means with a shorter feedback cycle. But to the person using this approach is it really ‘the hard way’? The way they are doing it requires less thinking, and while they’re waiting on the server to bounce back up they can check reddit, failblog, or have an impromptu sword fight. To put it another way, it takes longer but requires less effort.
Of course, at this point someone could start throwing out the word ‘lazy’. But let’s take a more sympathetic approach. Why are they doing it this way? Why do they want to think less? Maybe they’re burnt out? Maybe they feel the project is out of their control and there is no reason to put in a lot of effort. That its better to save their brain power for the new programming language or framework they’re learning in their spare time. Maybe they aren’t getting enough sleep. They probably know deep down that its not really the most efficient way to do it, but they’re tired. Emotionally, physically, or even subconsciously. I’ve certainly felt that way before.
Maybe the approach isn’t convincing your developers to do things the more efficient way. Maybe its better to be more sympathetic and find out why they’re doing it the easy way.