The company that I work for is rapidly expanding, so much so that we're actually knocking down walls to fit us all in! This is all happening because Product A is about to be re-branded and released to a global audience. These are good times!
One aspect of my role is to continually improve our software development practices, as such I'm always looking out for potential risks and mitigation strategies.
Our on-going expansion is presenting us with a moderate risk of lowering our productivity. We are in the midst of a big recruitment drive, and the fruits of this mean new team members are arriving almost weekly, whilst the existing team is busy delivering and maintaining a new product.
In terms of exposure to risk, we're not so exposed structurally, we should have little issue scaling up the number of features or the supporting infrastructure. The risks we face are likely to be issues surrounding integration and training; activities that will absorb a lot of the teams energy resulting most likely in a lowering of our momentum.
The process maturity work that we have been conducting over the past year has provided us with structural alterations required to handle higher workloads. In this sense, we're now in a much better position to absorb any influx of new team members with little risk of bottlenecks emerging.
The investment in our build processes has yielded a productive gain of about 3,700%. We've reorganised our branching strategy, introduced deployment automation and switched to Kanban.
.png)
On the release side we've introduced a platform for providing an unlimited number of disposable virtual environments. Coupled with automated deployment scripts we have achieved a modest 10,000% improvement.
.png)
Whereas before it would cost us £130 for a bean-to-cup deployment, it now costs £1.23. Given that we're soon to have more people, publishing more code more frequently, this is good news.
.png)
Still I think where we are lacking is our ability to support these new developers. We're in the middle of a major release, with an expectation that post-release we'll be able to pop-out features on an industrial scale.
All of which raises some interesting questions:
One aspect of my role is to continually improve our software development practices, as such I'm always looking out for potential risks and mitigation strategies.
Our on-going expansion is presenting us with a moderate risk of lowering our productivity. We are in the midst of a big recruitment drive, and the fruits of this mean new team members are arriving almost weekly, whilst the existing team is busy delivering and maintaining a new product.
In terms of exposure to risk, we're not so exposed structurally, we should have little issue scaling up the number of features or the supporting infrastructure. The risks we face are likely to be issues surrounding integration and training; activities that will absorb a lot of the teams energy resulting most likely in a lowering of our momentum.
The process maturity work that we have been conducting over the past year has provided us with structural alterations required to handle higher workloads. In this sense, we're now in a much better position to absorb any influx of new team members with little risk of bottlenecks emerging.
The investment in our build processes has yielded a productive gain of about 3,700%. We've reorganised our branching strategy, introduced deployment automation and switched to Kanban.
.png)
.png)
Whereas before it would cost us £130 for a bean-to-cup deployment, it now costs £1.23. Given that we're soon to have more people, publishing more code more frequently, this is good news.
.png)
All of which raises some interesting questions:
- Where is the time to support our new colleagues going to come from?
- How will we integrate them into our team?
- What impact will this have on the team productivity?
- How can we protect our code base against accidental damage?
- How can we mitigate these risks?
Moving to defcon 4
Our code base already has reasonably good levels of protection against accidental damage with the existing stack of analysis tools:- We have unit testing
- Code coverage analysis with minimum coverage failing
- Toxicity checking with minimum acceptable thresholds
- StyleCop checking with violation failing
The above measures are however largely "reactive" measures; A negative "red-flag" event after something has already gone wrong. Trial and error is a good way to learn, but wouldn't it be better if we could provide proactive assistance to our new colleagues rather than just waiting for them to fall through a trap-door.
The best approach would be to pair-up, but this would lead to one of two possible outcomes:
Pairing will happen; Our platform is huge and our new team members are going to be quite disorientated in the early weeks. No amount of documentation is ever going to help orientate people. You can't beat the human touch in this respect.
However we should try to reserve the pairing-time for when it's most valuable, and not on mundane activities. If we can improve our self-help and guidance offerings then this should be achievable.
Therefore what we'd like to achieve is:
The best approach would be to pair-up, but this would lead to one of two possible outcomes:
- We've got new developers doing absolutely nothing -bad.
- We've got existing team members impeded -bad.
Pairing will happen; Our platform is huge and our new team members are going to be quite disorientated in the early weeks. No amount of documentation is ever going to help orientate people. You can't beat the human touch in this respect.
However we should try to reserve the pairing-time for when it's most valuable, and not on mundane activities. If we can improve our self-help and guidance offerings then this should be achievable.
Therefore what we'd like to achieve is:
- Reduce the time spent supporting new colleagues
- Reduce barriers to entry
- Shorten the integration period
Moving to defcon 3
There are two specific tools provided by Microsoft that seem to be feared and loathed in equal measure; The mere mention of FxCop or StyleCop normally elicits a reaction of shock, pain and disgust, normally all three at once.
I believe however that the reputation of these two tools is largely due to legendary tales of misuse. If you're going to activate every rule, you can expect productivity and morale to suffer as a result. Not every rule is appropriate to your situation, and the cost of implementing some rules just can't be justified. We have been very careful to choose a pragmatic set of rules, considering practicality and affordability.
FxCop and StyleCop can be used to lay traps for developers to fall into, but more positively, they also provide the very guidance we're seeking to give our new colleagues. Both integrate into the IDE, both are entirely customisable, and both provide new developers with assistance they need from day #1 without any impediment on the existing team members.
Code reviews are an obvious alternative, but such meetings are often lengthy, unstructured, quickly loose focus, inconsistent and patchy. The outcomes of any such review often go undocumented and only partially implemented. Code reviews are the solution that everyone agree's would sort things out, if only they had the time do them. But they so rarely live up to the expectation.
Coding standards documentation is another obvious alternative, but let's face it, who actually reads a company coding standards document after day #1? And why would you?
Experience has taught me that Coding Standards docs are little more than a well intentioned statement of intent, "this is who we'd like to be".
I believe however that the reputation of these two tools is largely due to legendary tales of misuse. If you're going to activate every rule, you can expect productivity and morale to suffer as a result. Not every rule is appropriate to your situation, and the cost of implementing some rules just can't be justified. We have been very careful to choose a pragmatic set of rules, considering practicality and affordability.
FxCop and StyleCop can be used to lay traps for developers to fall into, but more positively, they also provide the very guidance we're seeking to give our new colleagues. Both integrate into the IDE, both are entirely customisable, and both provide new developers with assistance they need from day #1 without any impediment on the existing team members.
Code reviews are an obvious alternative, but such meetings are often lengthy, unstructured, quickly loose focus, inconsistent and patchy. The outcomes of any such review often go undocumented and only partially implemented. Code reviews are the solution that everyone agree's would sort things out, if only they had the time do them. But they so rarely live up to the expectation.
Coding standards documentation is another obvious alternative, but let's face it, who actually reads a company coding standards document after day #1? And why would you?
- Typically written by one person, and don't reflect the views of the team
- Often ignored by the rest of the team (see point 1)
- Typically written by the one person in the team that everyone else dislikes (see point 2)
- They take a long time to produce
- They very quickly become obsolete
- Difficult to use, badly organised, badly indexed, inconsistent.
Every single time I've been handed a standards document, I've quickly scan read it and thought, this is impressive, but does anyone actually implement it. The answer is always "a bit".
Experience has taught me that Coding Standards docs are little more than a well intentioned statement of intent, "this is who we'd like to be".
Moving to defcon 2
We're about to jump fully on board the Style and FX cop bandwagon. Our team leaders, architects and developers are working on a set of rules for both FX and Style cop. These rules will be integrated into all of our IDE's.
When our new colleagues join us, their IDE will be able to guide them on issues of styling and coding standards without any help required from the rest of the team. It might not be able to help with the architecture of our platform, but it will at least ensure a smoother transitional period for everyone involved.
Tailor made
We've configured both Cops to work on a per project basis, so that rules can be tailored to every individual project. A one-size-fits-all approach rarely works, and trying to find a set of rules that could apply to an entire platform is either going to lead to an in-effectively diluted set of rules, or rules that cause pressure and friction in unintended ways.
Focussed code-reviews
We're implementing FxCop to stimulate a conversation about coding standards, when necessary. Rather than having routine code-reviews which quickly become seen as a burden, we're using FxCop to bring specific issues to our attention.
Thanks to IDE integration, this should happen before check-in where a team leader can validate and approve an exception. However as a fail-safe, FxCop will also be able to fail builds if violations are found. In this event a quick and focussed code-review will be triggered in order to fix the build.
Thanks to IDE integration, this should happen before check-in where a team leader can validate and approve an exception. However as a fail-safe, FxCop will also be able to fail builds if violations are found. In this event a quick and focussed code-review will be triggered in order to fix the build.
This approach ensures that team leaders only need to perform code-reviews as and when they are genuinely needed, and focussed on a specific issue.
Barriers to entry
A FxCop and StyleCop are easily integrated into our IDE, which effectively embeds our "coding standards" into our development environment. Line by line, the IDE nudges our progression in accordance with our standards.
As our product evolves, as we improve, as Microsoft update, our StyleCop and FxCop based rules will adapt, assisting us with every line of code we'll ever write. It might not be able to explain the platform, but it can at least promote our standards.
FxCop therefore lowers barriers to entry, and eases the burden that new developers make upon the team.
As our product evolves, as we improve, as Microsoft update, our StyleCop and FxCop based rules will adapt, assisting us with every line of code we'll ever write. It might not be able to explain the platform, but it can at least promote our standards.
FxCop therefore lowers barriers to entry, and eases the burden that new developers make upon the team.
Evolving documentation
One of the biggest issues with coding standards documentation is how quickly they become obsolete. The energy and enthusiasm that went into the documents creation doesn't last. As such, these documents become worthless in a very short period of time, unless future resources are allocated to keeping the documents relevant.
With Fx/StyleCop after you've update the rulesets, you've effectively updated your coding standards, and they become instantly available to every developer. Microsoft provide new rules as their framework evolves, and we can choose which rules we would like to implement as we move forward, it is even possible to create our own.
The flip-side of knowing the rules is knowing when to break them. There will always be the exception. FxCop handles exceptions very well, and we've embedded our FxCop projects in our source repository to take full advantage of it's exception handling.
A team leader is asked to perform a code review (triggered perhaps by a failed build), examine the code and the circumstances that raised the exception, then make a decision. If the team leader decides that an exception can be made in this particular case, this can be recorded within the FxCop project. This exempts this rule violation from future checks, and we now have a journalled exception.
With Fx/StyleCop after you've update the rulesets, you've effectively updated your coding standards, and they become instantly available to every developer. Microsoft provide new rules as their framework evolves, and we can choose which rules we would like to implement as we move forward, it is even possible to create our own.
The flip-side of knowing the rules is knowing when to break them. There will always be the exception. FxCop handles exceptions very well, and we've embedded our FxCop projects in our source repository to take full advantage of it's exception handling.
A team leader is asked to perform a code review (triggered perhaps by a failed build), examine the code and the circumstances that raised the exception, then make a decision. If the team leader decides that an exception can be made in this particular case, this can be recorded within the FxCop project. This exempts this rule violation from future checks, and we now have a journalled exception.
Moving to defcon 1: Bring it!
With FxCop integrated into our pipeline and IDEs we'll be in a much better position to integrate our new colleagues. The tools provided by Microsoft should ensure that the disruptions faced by the existing team members are fewer, and our new colleagues will spend less time either waiting for help or having to look thins up.
Our coding standards are becoming embedded within the IDE and we are able to offer succinct code reviews, and keep a record of any exceptions made.
Our coding standards are becoming embedded within the IDE and we are able to offer succinct code reviews, and keep a record of any exceptions made.
With the help of FxCop, we can be much more confident that our code follows our standards and that this will be maintained over time.
Came here looking for actual code?
I think I can help...
Invoking FXCop from PowerShell and consuming the results
Comments
Post a Comment