Late last year here at work, we managed to push through a restructure of our software development staff so that they all come under me and work as one team. When I say, "all", technically there are four coders including me, so it's not a huge team.
The reasoning behind the formation of the team is pretty simple: We don't know each other's code. When a program failed for whatever reason, it usually fell on one person to fix it, and that person had to be the guy who wrote the code. Nobody else would even know where to start looking to get the program up and running again. The situation was untenable, and this became painfully obvious when, over the course of last year, three of our developers decided to move on, leaving a lot of legacy systems behind.
So as a team, we have to collaborate. More than one person knows about any given system, so there's some redundancy built into the support of the system once it has shipped. As much as possible I'm trying to run the team as if we were a third-party contracting team - taking on a few projects at a time and seeing them through to completion, using TDD and agile methodologies (which we're learning as we go).
A lot of people have written about the differences between internal software development and commercial development. In some ways it's easier, because you can introduce dependencies on software that you know exists in the target environment. For example, you can point to a known server and don't need to allow users to configure their connection strings, or provide functionality that depends on Excel being installed. That sort of thing. However, in a lot of ways it's a lot more frustrating to be part of an internal development team, because the pressure is always on shipping quick-and-dirty code rather than polished, maintainable code. Users want things done yesterday.
I've found that with a bit of politicking it's possible to convince users that "quick and dirty" isn't the answer. Most people are quite reasonable and understand that writing maintainable ("healthful" as Scott Bellware would say) software takes time and effort, and it's well worth it. There is, however, still one big difference between commercial and internal development: The ability to turn work down.
It's a good problem to have if you're a commercial software house: Too much work. If all your guys are swamped to the point where any new projects will just have them thrashing and never completing anything, you have little choice but to turn back new clients. You knuckle down and clear out the jobs at hand and then go back to them to see if the work is still there. Perhaps you tell them when they first approach you that you're happy to take their business but won't get to it for a few months.
In an internal software development team, though, turning back work is just not an option. None of the seemingly-endless stream of middle-managers will accept that you're too busy to work on their problem. Worse still, even the most trivial of applications are number one priority to the person who asked for them, and they often have no idea what goes on beyond their desk, so the truly important projects are meaningless to them.
Over the past few weeks I've seen this attitude come to a fore, and it's getting quite stressful. We have quite a bit of work to do, but every time we feel like we're making any headway on a project, two more projects appear out of nowhere. It's like fighting a hydra.
Of course, the up side to this is that I get paid every week whether it's busy or not, along with all the benefits of full-time employment. Perhaps the stress of not being allowed to say "no" is a small price to pay.
