Whistle blower for best practices
It was this discussion with Sudheendra that prompted this post. He said, "Prasanna, tell me how many companies have you seen who can say, 'I implemented all the best practices that is defined in my company across all my projects'?". "Or", He continued, "who can say 'I have clarity that these are the ones that we are not able to implement'.
He made a lot of sense. It is true that as software companies all of us put together a set of best practices once we come out of the "start-up" phase and get into the scale mode. We spend a lot of time in defining what is best for us architecturally, design-wise, program paradigm wise, and we believe that will help us clean-up the system to yield benefits of better productivity, better maintainability etc.
But the challenge is how? How do you mould these best practices to suit the project and teams needs? How do you engage teams to focus on this while not losing functional focus? How do you do this while not losing productivity? How do you make sure non-compliance are coming up on managements radar and the right attention is given to this? How do you prove ROI for such a program?
The key is to not have Best Practices as documents which finally never gets read, or used as time progresses and all the time you may have spent to arrive at one will just go down the drain. Focus on spending a similar time to make the best practices as those jsons, or xmls which you can validate as code comes along in an automated fashion. Make Best practice document a living whistle blower which whistles for every non compliance.
This can provide live insight into management, to developer, to managers for them to take decision on which one is helping which one is not helping to fine tune the living document to best suit the teams and the context.
Thoughts?
He made a lot of sense. It is true that as software companies all of us put together a set of best practices once we come out of the "start-up" phase and get into the scale mode. We spend a lot of time in defining what is best for us architecturally, design-wise, program paradigm wise, and we believe that will help us clean-up the system to yield benefits of better productivity, better maintainability etc.
But the challenge is how? How do you mould these best practices to suit the project and teams needs? How do you engage teams to focus on this while not losing functional focus? How do you do this while not losing productivity? How do you make sure non-compliance are coming up on managements radar and the right attention is given to this? How do you prove ROI for such a program?
The key is to not have Best Practices as documents which finally never gets read, or used as time progresses and all the time you may have spent to arrive at one will just go down the drain. Focus on spending a similar time to make the best practices as those jsons, or xmls which you can validate as code comes along in an automated fashion. Make Best practice document a living whistle blower which whistles for every non compliance.
This can provide live insight into management, to developer, to managers for them to take decision on which one is helping which one is not helping to fine tune the living document to best suit the teams and the context.
Thoughts?
Comments