Corporate frameworks and corporate standards
Most IT departments manage multiple projects and applications. As you go from project to project, you inevitably will find better ways to do things. Then at some point, someone might decide to get the smartest people together and come up with the one corporate framework to rule them all. All future projects will use the new framework, which makes sense because we’ve taken all of our good ideas and combined them so that other developers don’t have to go down the wrong path. I’ve had this idea before, it’s a great idea, right? We’ll have less risk of failure and we won’t constantly reinvent the wheel.
Companies think that by doing this, they will reduce the risk of failed projects. But they are buying into two things that are fundamentally incorrect — that they won’t be able to ever come up with a better way of doing things and that all projects are the same.
Ultimately what is lost when corporate standards are mandated is innovation. Developers are smart people, and many of them are trying to find new and better ways of doing things. If you don’t encourage them to find a better way, either they’ll quit trying, feel defeated because they can’t change things for the better, or get upset that the process is hindering them from getting things done better or faster.
Also, all projects are different. I’ve been on many “agile” projects, and every one did things differently. This is good because working on a two-person team at a startup is much different than working in an enterprise IT shop. I heard of one company who was trying to do an “agile transformation” so that they could find a methodology that they could standardize across the enterprise. It’s great to see people adopt agile practices (which are generally good), but trying to “standardize” so that everyone has to do things to same is directly opposed to the agile idea of continuous improvement. (Often times, the standardization of methodologies is mainly done so that common metrics can be established by which to judge teams, which encourages teams to game the system to make their metrics look better instead of solely trying to provide business value in the best way possible.)
The Alternative
What if instead of mandating that everyone used the same corporate framework, we encouraged teams to come up with the best way of doing things and then share them with other teams so that they can adopt each others’ best ideas if they so desire?
What if instead of mandating a framework, we created a repository of random pieces of code that people could pick from to do common tasks (e.g. an authentication library that authenticate to some corporate server)?
What if we stopped being obsessed with metrics and measuring teams and just went out and got the best developers that we could find, and then gave them everything they needed to do an awesome job?
Amen! It’s funny, I’ve come full circle to your exact alternative way of thinking here. In fact, I have been the one championing the “frameworks” and “standards” in the past… but now that I’m a little older, wiser, more experienced and have had the opportunity to innovate I see the flaw in that mentality.
Unfortunately, most corporate IT shops are so enamored with the standardization concept that continual improvement scares the bejesus out of them.
So maybe the trick is finding a “standard” way to ease peoples worries in the big scary, uncharted world of continual improvement. ;)
Hi Jon,
While I agree with your vision of things, I wonder how would you factor these things in:
1. While like you said, developers are usually innovative and smart people, not all of them will get things right when they try to re-invent something (a specific feature or functionality) they feel they can do better than a proven framework (either company made or third party). Even if they end up getting it right, the time it will have taken them to figure out every possible quirk or scenario will add-up to client cost, no?
2. Once again, they probably can figure out a different (probably better) way to do something. But will it scale? Most of the times, if a company dedicated time, effort and money to develop a framework, they will have considered a lot of scenarios from different projects that they want the framework to handle. Probably the way the developer coded a specific feature will require a lot of rework when using a proven framework would mean way less work/coding.
Then again, I’m a developer, I’m all for the way you suggest of doing things. The approach you suggest if all developers (if at least most of them) were passionate and committed. However, that’s not the case, and I guess that’s the reason sometimes companies force projects to use frameworks.
What do you think?
Two points:
1) You missed what I think is the biggest argument against the corporate framework; architects and managers who abdicate their role/responsibility to the framework and stop working with developers or taking interest in the code that’s being written in their shop. I’ve seen this several times. The thought seems to be “If I put these shackles on tight enough, there’s no way they can do anything I don’t want them to do.” The problem is that the shackles are usually so tight the developers can’t do anything at all.
2) Having said that, I have seen these types of frameworks work. The keys appear to be having the architects/technical leads remain involved with day to day development, keeping the framework flexible to enable the developers to “opt-out” of the framework if they have a task that is better accomplished doing something else and finally having a means to review and update the framework. This review process needs to be transparent and accept input from all interested parties; not just be the architect hiding in his office unilaterally deciding what everyone should be doing.
Just my $0.02
@James,
I don’t think I could’ve said it any better!
You’d have anarchy. Sweet, glorious anarchy!
+1