I work for the State of California. Our programming team in my opinion is not really a 'team' in that we usually work solo on projects throughout the application/systems complete life-cycle.

The end result is a lot of developers are 'reinventing the wheel'... writing their own data layers, even though the vast majority of us work on the same Oracle DB... writing their own security stuff... the list goes on.

I can't change the mentality of my employees, and don't have any realistic ambitions in regards to changing our team process... but my goal is to get our team to work together a little more, at least to build common building block pieces that we can all use for boilerplate functionality.

The obvious benefits are, testing and support are much more maintainable when all our users are familiar with a common piece, time to production is less when you aren't writing the same repository someone else already did, and we can focus on providing better solutions to the unique problems our apps must solve... etc.

I'm preaching to the choir, I'm sure.

The trick is, the State does not like change, neither do its employees. Managers often disregard new ideas simply because they like to avoid friction and would rather continue on as is.

There are similar questions out there, but what I am looking for is advice on how any of you may have faced a similar situation, and any direction toward getting a 'grass roots' kind of effort going to have an easier time approaching management.

EDIT:
Just to clarify a few things:

the scope I'm looking for is within the IT shop of my State Agency. I'm not trying to coordinate across several departments. Got get people off the training wheels before asking them to ride motorcycles.

Security is not much of a concern, most of our applications are internal and written in Windows Forms distributed on Citrix (ugh.) and nearly all use the same enterprise tables in Oracle... very few if any apps are "classified" so to speak. it shouldn't hinder collaboration.

I have gone so far as to setup a NuGet feed, with a couple of boilerplate pieces of code packaged, and written a few repos for Oracle, sent out some emails, but received little feedback. I've got about 1/3 of our team using ReSharper, and send emails from time to time with tips... again, not a whole lot of feedback.

4 Answers
4

may not be so obvious to the people around you, especially if they are not devs. I've worked for both State governments and the Federal government so I can empathize with your situation. In my experience you need to show them the money. Start equating changes to numbers (e.g. metrics) and then equate metrics to money. I realize this is no fun and I realize you shouldn't have too, but this is often the way of things. All the states are in a budget crunch and showing them how they can meet greater demands without needed more money, the more attractive your ideas may become.

Along the way you may find that something you want to do sounds (or feels) better but the numbers don't support you. If that happens, you may be embarking on a technology religious debate which can really upset; or completely derail; other progress you’re making. In that case, give it up and move on to the next idea. Come back to those once everyone is more open to changes.

For metrics... start with the classics, they work well in most cases.

Time / Schedules (Could include performance of the system)

Money (Spent and Saved)

Material

Defects (Rates, Severity, Visibility to end-users)

Reliability (in government terms this is Ao [Operational Availability] and MTBF Mean Time Between Failures)

Thank you Joe. I think this is the approach I'm going to take. I've tried it before informally, but I think you hit the nail on the head in that formal conversions/calculations need to be made to really sell the idea. Thanks for the advice on not pushing too hard either. Question then is, how does an IT guy sell management a cost-benefit when it costs a lot of man-hours up front? ROI promises are hard to go fishing with alone especially when broke.
–
one.beat.consumerDec 20 '11 at 17:49

Could you consider teaming up with one or two of your co-workers to help start building a common framework? That would be my suggestion for a starting point as you will need allies and some of the benefits may reveal themselves after some time working together so that things aren't so isolated. You may have to have a few discussions with co-workers to see how receptive some are to these ideas and which are the early adopters that you could use to get this off the ground.

My main theme would be to consider baby steps here. Little changes periodically may work just fine.

Good advice. I'll edit my comment to provide a little more detail though... this is happening within one IT department within one State Agency... I'm not trying to coordinate cross-agency... California has a devoted agency just for that reason and look how many of their projects succeed. ;P
–
one.beat.consumerDec 20 '11 at 17:39

I'll start by saying that I'm a huge supporter and crusader for reusable code and defining cool, nifty and powerful building blocks that multiple developers have to use. However, I would also point out that rolling your own reusable code/libraries/frameworks sometimes can be a very sharp double-edged sword. And something that you'd think should save time, sometimes might do just the opposite.

This has been the pattern I observed in the past: As a developer keeps working on a product/features/releases, some of them (maybe 10-25%) will identify some reusable components or some classes that would be plain silly to keep writing over and over. The rest of the people, continue copy/pasting and reinventing the wheel. Let's forget those, you are not one of them.

So when you identify reusable code, you begin to create your own personal library of cool things that over time make your life easier and easier. You might have utility classes to help you work with XMLs, threads, registry... you name it. I've done this and showed it to anyone who would be willing to listen and some people gladly accepted the fact that they can parse out what they need from an XML document with 6 lines of code. Other people are set in their ways and they love coding 100's of lines of straight MSXML.

My findings:

over time as your library improves, others will gradually start using it.

as others start using it, now you became the support person for any time they have a problem and they suspect its your code. Sometimes they find a bug in your code because they use the API slightly differently than how you used it, sometimes the bug is in their code because they didn't understand how to use the API and sometimes the bug is unrelated but the burden is on you because they are convinced that before they added your library everything worked.

(this was actually from a different post/blog but can't find the link): if you wrote some "reusable code" and it took you 3 week to do it. You need generally need to spend another 3 weeks cleaning it up so other people can consume it and providing clear documentation and another 3 weeks on writing extensive unit tests and also covering general use scenarios, not just your use scenarios. Other people found the same thing, frameworks/libraries take 3 times the amount of effort than original development alone.

Hopefully you won't have to face this. Some of my code became so reusable that people actually started using it in a more wide setting. Then about 9 months ago, management decided to split our product into 2 different ones, each one having its own release cycle. What do you think happened to that framework/utility library? Both products depend on it but now you have to be careful how the library is modified if you are actively developing product A while product B is about to be launched. Our solution was to make the framework itself product C that would have its own independent release cycle. So here I am 9 months later and I'm still feeling the aftershocks from all the build/continuous integration/packaging issues that this has caused.

You might be extremely careful how you wrote your utility classes and you understand all implications of making this change and that. But once other people start using your code, at some point they will want to modify it. If there are 20 other components that depend on your library, when somebody modifies the library, they can potentially break 19 other components (I'm assuming they made the change to get their code working). As code becomes more widely used, it becomes much more expensive to modify it.

Although I'm all for reusability, there are days when by lunch-time I start wishing to myself that my personal utility library remained my personal utility library.

So based on my experience, some advice that I can think off:

Look for external 3rd party libraries that do what you need and build your applications on top of those as much as possible. Every one of those libraries already has a team of people supporting it. Introduce them to a global place in your environment where anyone can get to them.

Instead of asking everyone to use your stuff, approach your teammates and other engineers one-on-one and see who has same mindset as you. I'm sure you will find few others who share your values and you might start an unofficial core team that would work towards a common good.

Don't know if this one will work and/or is a good idea, but I want to try this in my own company: Instead of creating frameworks/libraries which are global and owned/used by multiple people/teams. Treat all of your code as "internal open-source". Setup a repository similar to github where different people/teams can submit library/utility/helper code. Make repository visible to everyone so that if you write something good, anyone would be free to take your code and use it. If they decide to make a change in your code, just like open-source, then can create their own branch, which they will maintain, or give you back the change to roll back into the main trunk. If you don't trust their work or don't agree with the change, since the project is still yours, you have the final say if you want to accept it. If some team starts a project and then abandons it but a different team finds it useful, they can branch into their own team repository and continue the work. I've been looking into using Redmine to do something like this, but haven't had a chance to set it up yet.

Excellent observations and advice. I appreciate it, and yes, I think the way we would approach it is like your #3 item, like open source chunks, maybe distributed via a NuGet package in a local feed, but with the sort of "you use it as is and I'll help; you tweak it, its now your trunk to maintain" policy in mind. We'll see. Thank you again.
–
one.beat.consumerDec 21 '11 at 19:28