Advice/Approach for distilling homogenous code and building common code for a team

Question

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.

Answer 1

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.

Answer 2

The trouble is...

the obvious benefits

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)

Good Luck!

Answer 3

The first step will be to advertise (among anyone interested and working for the same employer) what you have.

Like the faculty offices of colleges, have posters illustrating the architecture, functionality and designs of the parts you have. This is the "inventory" or "asset" of the State.

---

A second question is whether employers are allowed to see other's source code. If this is not allowed, collaboration will be very difficult (unless you can get support at the State level).

---

When it comes to security, it is likely that the State already has some information security mandates that has to be met by all projects. It may be a good starting point for standardization.

---

Some kind of work, esp. "customization projects", will always be solo work, because this is where they belong.

Answer 4

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:

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

2. 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.

3. (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.

4. 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.

5. 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.

6. 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:

1. 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.

2. 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.

3. 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.