Should a software company have a dedicated team for research and/or utility libraries?

Question

I work in a company that does web applications for various banks and some smaller e-shops We employ about 20 developers and have 4-5 projects in development at any one time. Our development teams don't interact much and a lot of the same problems are done in varied ways(good to bad).

I was wondering if it would be a good idea for a company to have a team of programmers that do research on current frameworks and continually improve a common library of functions and a common framework to build current and future projects much faster and more efficiently.

How large should a team like this be?

Also should it have permanent members that train others or should it rotate people?

Update: I was thinking about a common project that people can work on for fun that might spark some interest. It seems that when people have job pressures the solutions they come up with are not the best.

Answer 1

One important point is that it's impossible to develop a good framework in total isolation. Good frameworks are organically grown: when a programmer notices that he needs some specific functionality, he adds it to the framework, and so the framework grows little by little - as opposed to architecting a "perfect framework" up front, which never works, because the architect can't be aware of all eventually turning up use cases.

Of course, organically growing the framework has the downside that its internal integrity might not be too good, and it turns into spaghetti. If your team keeps up good internal communication, then you might be able to combine the best of both worlds: a separate architect team keeping up the integrity of the framework, but building for real needs of the end users (developers).

Answer 2

My feeling is no.

What I suspect you'd find if you did this is that instead of having individual teams producing libraries that no-one outside that team used, you'd have a specialised team producing libraries that no-one outside the team used (and doing so at considerable additional cost).

There are assorted problems with the sort of team you describe, but for me the main on is that it doesn't address the issue you actually have.

The problem you have is not who produces the libraries (by the sounds of things you already have many solutions to these problems so how is one more going to help?), it's that the teams aren't talking and interacting.

There are good reasons why teams don't reuse each others code (for instance that the problems while superficially similar are subtly different, or that the project timing just doesn't allow for the additional dependency of developing something together), but you need to look at how you can get them to interact when it is possible.

I'd suggest:

• rotate teams between projects
• hold inter team lunches and discussion groups
• post project reviews going over how problems were solved (attended by the other teams)
• set up an area of the wiki outlining code which might be reusable (and who to talk to about it)
• think about incentivising good re-use - seriously actually pay people extra for doing it. If re-using a component saves 5 days and $2000 in costs, why not give $200 of what is now extra profit to the team for a night out at the end of the project (when you've validated the saving was genuine)

A libraries team would be, I suspect, overhead with no benefit.

In terms of it being a common project that developers work on for fun - no company should rely on programmers working on things in their own time. That's just unpaid overtime and is, in any case, not dependable as there will likely be large periods where no-one wants to work on things.

If you're saying it would be people working in company time between projects then maybe it can work but I still don't think it's the real problem. You still need to work out how you're going to get people to use the libraries. As I said, you already have solutions to these problems which are being developed on each project, your issue is why aren't they being shared.

Answer 3

That is the job of an architect.

The main responsibilities of a software architect include:

• Limiting the choices available during development by choosing a standard way of pursuing application development
• creating, defining, or choosing an application framework for the application
• Recognizing potential reuse in the organization or in the application by Observing and understanding the broader system environment
• Creating the component design Having knowledge of other applications in the organization

Read more about: - Software architect - Solutions Architect - Enterprise architect.

Answer 4

The saying "Eating your own dog food" address this issue. If your top-cool-rockstar-coder gives birth to a library he never used in practice, how can he say that it is a good one?

The main reasons to develop functionalities into framework are

1.It is useful to the developper
2.There are a few cases where it has been useful
3.It might be useful to others

When you've hit 2, the functionality is already there, how can you pass it to someone else?

Answer 5

I think that's NOT A GOOD IDEA, because for libraries to be useful they have to help you solve real project problems, and you only get to know them by, well... working in real projects.

Otherwise you can end with a "theoretically" very good library!

Answer 6

I'm a little late to the game but I felt like no one was addressing this:

Your individual teams that are solving different problems in different ways would definitely benefit from shared functionality, and there are a variety of ways to get that in a way that doesn't devote a single team to developing it, but I've seen a lot of places that do.

In most cases I see this referred to as a "core" of your product line, and sometimes there is a team in charge of maintaining it, led by (as Amir suggested) an architect. This is typically how you'd be able to find ways to leverage or create a framework that follows the tightest standards you set in your organization but provide only the most bare functionalities that may or may not need to be extended into the full-fledged applications that your individual product teams offer. This allows you to have the benefit of "dogfooding" your core code by implementing it in every individual place that you use it, and then also branch out to different products that may have completely different implementations. This allows all your teams to contribute to the core libraries but not bog it down with functionality that only they need.

Answer 7

How much time are you going to spend on debating whether or not using the framework is going to be a benefit in all cases? Does a project get delayed by waiting for the framework to be upgraded? At some point the usage of the framework has to be required in order to justify its existence.

Answer 8

At the one company I worked at that really had a similar thing, it didn't seem to work well. The people in the inner team would come up with a neat idea and come up with a prototype that mostly worked, then it went over the wall and we were expected to turn it into a product.

What I'd expect to have happen is that the tool group would wind up going on its own little program, producing functions that weren't really all that useful, but which cluttered the API and got used enough so they couldn't easily be removed. They wouldn't document adequately.

If the tool group was sufficiently under a system architect who was in continuous contact with the people actually using the tools, it might work. If the tool group rotated frequently (which would hinder doing a lot of exterior research) it might work. However, I'd be afraid of losing contact with the people doing the paying work.