Saving fish by writing code! Applications developer in fisheries, specializing in webapps and moving 'enterprise-y' legacy systems to modern agile systems - Email or tweet me if you want to talk!
It works really well, and someone wants to adopt it as a convention
We have a group discussion, and if the group is amenable, we say we'll all do it.
We write down our convention
We watch whether or not we comply with the convention
If compliance is low, and automation is possible, we write a code gen tool, or scripts, build something so people no longer have to refer to the wiki
In my book, steps 4, 5 and 7 are the big deals. Getting group buy in is the #1 critical priority. It doesn't have to be consensus; you can Amazon it up and disagree/commit, but the group must be willing.
Writing down the convention, or making a library, or maven archetype or whatever form the convention takes is also pretty critical. It's hard to follow a convention that can't be described or codified, and someday you'll need a place to point new folks on the team.
Step 7, for us, is an interesting one. I think we don't do it enough. Here's an example from my recent work:
We were converting a bunch (~40) of BlazeDS monolithic services to message bus micro-services. It's easy, but tedious work, lots of mappers, lots of stubbing out the existing api. The tedious work tends to be the most error prone, because people go on autopilot. Everyone did their best to follow the pattern, but little differences cropped up here and there.
About 80% of the way through it, one dev was blocked, so they wrote a code gen tool that creates a message bus service package layout, with stubbed out methods, so devs only have to create the mappers. We didn't do that earlier because we were afraid the code gen tool would take a week or two we didn't have. Turns out, it took an afternoon and would have saved us a month...
I'm not sure where to draw the line, but when adopting a convention, I think you should look long and hard at making tooling to support the convention. It depends on how many people are working on a project, though. The more people, the more the team should create tools to support themselves. Fewer people can get away with frequent communication and strong norms.
Saving fish by writing code! Applications developer in fisheries, specializing in webapps and moving 'enterprise-y' legacy systems to modern agile systems - Email or tweet me if you want to talk!
Somewhere around steps 6 and 7 we also have the option to bail out. If compliance is low because the convention is bad, we just get rid of it. Probably obvious, but it bears mentioning, especially for people working in big, ponderous company/gov't cultures
In my shop it usually goes like this
In my book, steps 4, 5 and 7 are the big deals. Getting group buy in is the #1 critical priority. It doesn't have to be consensus; you can Amazon it up and disagree/commit, but the group must be willing.
Writing down the convention, or making a library, or maven archetype or whatever form the convention takes is also pretty critical. It's hard to follow a convention that can't be described or codified, and someday you'll need a place to point new folks on the team.
Step 7, for us, is an interesting one. I think we don't do it enough. Here's an example from my recent work:
We were converting a bunch (~40) of BlazeDS monolithic services to message bus micro-services. It's easy, but tedious work, lots of mappers, lots of stubbing out the existing api. The tedious work tends to be the most error prone, because people go on autopilot. Everyone did their best to follow the pattern, but little differences cropped up here and there.
About 80% of the way through it, one dev was blocked, so they wrote a code gen tool that creates a message bus service package layout, with stubbed out methods, so devs only have to create the mappers. We didn't do that earlier because we were afraid the code gen tool would take a week or two we didn't have. Turns out, it took an afternoon and would have saved us a month...
I'm not sure where to draw the line, but when adopting a convention, I think you should look long and hard at making tooling to support the convention. It depends on how many people are working on a project, though. The more people, the more the team should create tools to support themselves. Fewer people can get away with frequent communication and strong norms.
Somewhere around steps 6 and 7 we also have the option to bail out. If compliance is low because the convention is bad, we just get rid of it. Probably obvious, but it bears mentioning, especially for people working in big, ponderous company/gov't cultures
Thanks, this is an excellent guideline!