When Developers Have Fun
The idea of creating APIs and templates to guide a team in developing an application can be nerve wracking to control freaks. The truth is, you can never stop a developer from bending the rules and doing something beyond the expected, and still get great results. There are developers who stick with the template provided to them, and there are those who brave themselves to explore. And this is where the fun begins.
Developing an MVC application can easily be a template-driven ceremony. Here's the model template, here's the view template and here's the controller template. Fill in the blanks and you're done. You can copy-paste an existing module, replace the right parts and you're done. You can do this over and over to all your current or future modules and pages, and you're done. The development team is like a factory, quickly delivering requirements after requirements, all looking pretty much the same under the hood.
Suddenly, developer X does it differently for some reason. Instead of the suggested classical post-back MVC codes, developer X flooded the UI with AJAX, JQuery and lots of JavaScript codes -- which she later justified as "needed" for the requirement assigned to her. Soon, developer X gets assigned to new modules. A few months later, classical post-back MVC efficient developer A takes over developer X's old modules. As soon as developer A loads the codes, his jaw drops to the floor and the world around him stood still.
For a module that passed QA and UAT, and working quite well in production, developer A can't complain. It's working alright. Even if in his eyes, the module was done "wrong". To the testers and users eyes, the module is working perfectly. To developer A, it's a nightmare. The code is different. It didn't use the "template". It didn't make sense to convert it to the template he is used to. Developer A needs to learn the "new" code. Developer A slows down. All the learning curve and figuring outs affected his productivity. The entire team's sprint got affected, with deliveries barely making it to the end of the sprint. Developer A got lucky this time -- the enhancement and fixes he needed to do had well documented solutions in a developers forum... although it took him two times his original estimate to finally iron things out.
It's not all that bad, of course. It affected developer A in that sprint, yes, but it also meant he learned something new. Developers B and C had to learn them as well. Meanwhile, developer X was unstoppable -- she used her "new template" in all of the new modules assigned to her, all passing QA and UAT, working as expected in production. Needless to say, the application's code got "infected". Suddenly, the team has two templates! With modules based on either template passing QA and UAT, there's no reason to be a stiff about restricting the team to one template. The two set of templates have to co-exist.
The author of the original APIs and templates ended the week partying at a bar. He needed to unwind. He needed to control the control freak in him. Or perhaps he was celebrating. He did the code review after all. A new era has begun.
Come Monday, new developers Y and Z joined the team.
The evolution continues.
In the real world, this happens. Every developer "innovation" can be justified. In a world where users don't care about how the code looks like, and where project budgets and deadlines are real, getting products delivered on time and as planned can welcome new approaches, new ideas and new strategies. Those in the leadership role should be ready to support developer creativity. The team is not a machine. It's filled with living people. Each individual skills and talents should be appreciated. Nothing new gets invented if we don't allow them. Let the team have fun, and have fun along the way.
Developing an MVC application can easily be a template-driven ceremony. Here's the model template, here's the view template and here's the controller template. Fill in the blanks and you're done. You can copy-paste an existing module, replace the right parts and you're done. You can do this over and over to all your current or future modules and pages, and you're done. The development team is like a factory, quickly delivering requirements after requirements, all looking pretty much the same under the hood.
Suddenly, developer X does it differently for some reason. Instead of the suggested classical post-back MVC codes, developer X flooded the UI with AJAX, JQuery and lots of JavaScript codes -- which she later justified as "needed" for the requirement assigned to her. Soon, developer X gets assigned to new modules. A few months later, classical post-back MVC efficient developer A takes over developer X's old modules. As soon as developer A loads the codes, his jaw drops to the floor and the world around him stood still.
For a module that passed QA and UAT, and working quite well in production, developer A can't complain. It's working alright. Even if in his eyes, the module was done "wrong". To the testers and users eyes, the module is working perfectly. To developer A, it's a nightmare. The code is different. It didn't use the "template". It didn't make sense to convert it to the template he is used to. Developer A needs to learn the "new" code. Developer A slows down. All the learning curve and figuring outs affected his productivity. The entire team's sprint got affected, with deliveries barely making it to the end of the sprint. Developer A got lucky this time -- the enhancement and fixes he needed to do had well documented solutions in a developers forum... although it took him two times his original estimate to finally iron things out.
It's not all that bad, of course. It affected developer A in that sprint, yes, but it also meant he learned something new. Developers B and C had to learn them as well. Meanwhile, developer X was unstoppable -- she used her "new template" in all of the new modules assigned to her, all passing QA and UAT, working as expected in production. Needless to say, the application's code got "infected". Suddenly, the team has two templates! With modules based on either template passing QA and UAT, there's no reason to be a stiff about restricting the team to one template. The two set of templates have to co-exist.
The author of the original APIs and templates ended the week partying at a bar. He needed to unwind. He needed to control the control freak in him. Or perhaps he was celebrating. He did the code review after all. A new era has begun.
Come Monday, new developers Y and Z joined the team.
The evolution continues.
In the real world, this happens. Every developer "innovation" can be justified. In a world where users don't care about how the code looks like, and where project budgets and deadlines are real, getting products delivered on time and as planned can welcome new approaches, new ideas and new strategies. Those in the leadership role should be ready to support developer creativity. The team is not a machine. It's filled with living people. Each individual skills and talents should be appreciated. Nothing new gets invented if we don't allow them. Let the team have fun, and have fun along the way.
Comments
Post a Comment