views:

436

answers:

4

Last year we were focused on improve our technical capacities and leveraging our knowledge of various architectures and frameworks and methodologies.

This year (August mark the start of a new accounting year) we need to improve our productivity. By this I don't means we need to get more KLOCs per month per programmer. What we need is to get more artifacts finished, stables, and returning in the promised market value.

For artifacts I refer to every deliverable product that we produce as part of a given project:

  • Software programs
  • Automatized Test Cases
  • User's Manuals
  • etc

Can you tell what things are improved your performance as solo programmer or as a member of a heterogeneous team?

+1  A: 

I think you should be asking your team. If your team is serious and really committed, they'll know better than anyone what they need to be more productive. Everytime I've asked members of my team what they think they need to be more productive, they've given me a straight and honest answer no matter what the implications may be. It's usually always come out to be something to help their physical working environment moreso than some software tool for development. A more comfortable chair, a second (or third) monitor, books, etc. In my experience, it has always been things like that over actual software tools. Developers are smart people. In practice, they can usually find their own tools to help themselves. If they know of a software tool you can buy that will help, they'll mention that too.

Jeremy Privett
A: 

Atrophius I already do so and I'm working on that. (Except for the private offices, sorry guys!)

But sometimes, you know, sometimes you can't see the forest for being looking at the trees so, I though, it would be good to get suggestions.

For example, nobody asked a second monitor and, at least for some of us, that's an improvement that can be workable.

Another thing to consider is that I can't control everything. For example, I can't give them private offices. So, I want to come back with a couple of suggestions to compensate for that things I can't change or adjust.

ggasp
+1  A: 

@ggasp:

Absolutely. Your milage may vary, but the simple act of asking what would help has often helped productivity, even just slightly, for me. Even if they won't openly admit it to their managers, developers absolutely want someone who cares about their well-being as their manager.

As long as you can't do things like private offices, try to focus on the things that are under your control. The ones that love what they do are always looking to learn more. Keep a company library of a ton of programming and technology books that your developers can "check out" and read. If they take the books home, chances are they're reading them and trying out the new things that they learn. That's technically self-improvement that you inspired but you're not paying them for. The books will pay for themselves a million times over, if even just the slightest majority of your developers do this.

If you can't afford the best chairs, be willing to actually go out somewhere with your developers and have them test chairs. Let them decide what's the most comfortable for them and bring it back to the office. Ask them what their preferred monitor configuration is and do what you can within your budget.

I can try to suggest some software tools, but that would be easier if you could define what technologies you're working in. .NET/C#? A Corporate Resharper license would be beautiful. Everyone has the latest and greatest version of their respective IDEs, right? You've got a build process with a build manager who has it automated to the point where builds can occur with a single click from a developer, right? These are all huge benefits, productivity-wise.

Jeremy Privett
+2  A: 

Productivity can be a very tricky thing to gauge so it is always a good idea to pick a standard measurement that you can compare against to track your productivity. With that out of the way, there are many different things that can affect productivity as @Atrophius mentions but I'd like to focus on a few different aspects that can help your teams productivity.

Good Source Control - All projects are built on top of the bedrock of the source control being used. Make sure your developers know how to use your source control properly and make sure that you are using a system that allows your developers to work how they need to. Its also important that your developers "check in early, check in often" to help solve integration issues as soon as possible and when they are smaller problems.

Automation - One of the best things you can do for your developers is work out a powerful and flexible automation system. The most important things to automate are your builds, tests, and releases. If your developers have to remember to integrate some code and run a bunch of tests manually, its never going to get done. With solid project automation, your developers know when a build breaks sooner than later, they have the most current documentation, and they know their projects tests are helping maintain the quality standards.

Testing Testing Testing - If your developers aren't writing tests regularly and often, they should. By writing a comprehensive set of tests as you write code, your developers help keep the system design in mind and also ensure a good level of quality to their code. These tests should be automated and should be run with every code commit.

Time-Boxed Development - Its always a drain on a developer if a feature or project just drag on and on and on. The best way to combat this is to pick very small, specific goals that can be achieved within about a 2-4 week time period. Once your team has decided on these goals, do everything you can to avoid interruptions and have these features done, done, done at the end of that 2-4 week iteration. By done, done, done, I mean it is unit tested, automated, documented, and in a releasable state.

Better teamwork and communication - I find that the teams I have been on are much more productive if we are effectively communicating with each other as a team. It is important to build the communication channels and trust between developers so that they can come to rely on each other and work through problems faster and with better results. I've found that using daily Scrums we can communicate with each other quickly and effectively.

These are only a few suggestiong, but I find that without these main areas covered, your productivity gains by adding monitors or chairs isn't nearly as useful.

Sam Merrell