How to utilize programmers effectively when they don’t have Enough Work?
There is always room for improvement in the code. Just be sure not to break anything.
Get them to pay back some Technical Debt.
You could have them look to first get any legacy code covered by a decent set of unit tests. Then you can get into the game of refactoring.
In addition to that, once you've got that safety blanket of the unit tests, you should then be able to look at performance tuning too. Recommend you look at either using the profiler that's build into Visual Studio if you have the right version or getting your hands on something like dotTrace or ANTS Profiler.
Have them educate themselves. Allow them to work on experimental projects that will allow them to learn and evaluate new technologies and new methods. Unless there is actual work to be done on improving the existing code base.
They always can improve performance. Somewhere in that app, there is a slow, fat rat waiting to get whacked with a good piece of opti-mice-ation.
Refactoring, learning new technologies, testing (even performance testing).
Research completely different technology stacks. Learn from them.
I've worked in Window shops where I installed Cygwin (a Linux emulator) on my laptop. Introduced my colleagues to the notion of what you can do on a commmand-line.
I currently work in a (mostly) Linux shop, where on my Windows laptop I have installed SQL Server and Visual Studio.
Education in several areas, over time I have been reading up on developmentmethods, new technologies, new products and so on. It's expected by my company that I keep getting wiser to help make everything run more efficiently and on the ball at all time.
(Disclaimer: I'm speaking as a developer turned QA, so this may be from a slightly different point of view)
That really depends on your company situation and management mentality. Speaking from my own experience:
Don't tell your bosses otherwise you'll be facing an immediate head-count reduction!
Don't extend your unit testing phase to ridiculous proprtions. You're probably under pressure to get that bug count down or share of the bugs found by you up. but you're stealing work from the QA team if you do it that way, and they'll forever hate you for it. Just remember that a good QA team can watch your back... or stab you in it.
Do plan for and spend more time on documentation. Programmers do not exist in a vacuum, and other people rely on their design and functional specs to do their job properly. We all hate doing documentation, but this is often criminally overlooked and makes QA a nightmare.
Do spend more time on training! It'll pay back in quality of code and reduced stress for the team leads.
People mentioned refactoring which I completely agree with, in a different way I would say: Have them delete some code.
I always say, the best part of being a programmer is deleting crappy old code. :)
I think that there is never a break for programmers, there alway remains a consequent need to update the skill sets and dive into more programming challenges to make out some results. its more like heuristics, in that when a person comes by a problem, maybe in the "spare time", he would have done something similar so he can go about programming without a second thought. So i think studying more code, practising code, improving software programming concepts and all the same enjoying it, because if a person doesnt enjoy, he cant learn much. so learn at ur own pace but not completely stop. because as vibrant as water can be if it remain stagnant, it will smell and loose its beauty. similarly is a programmer, there can be extra time if we think of our jobs as just jobs, but if we think of them as a job and a hobby, well all the better.
write internal tools. there's always some process that should be automated only no one has had the time.
Spend some time on build/deployment tools. You should be aiming to have a One Step Build, or in the case of web-apps, One Step Deployment.
Send them to StackOverflow. There's always something they can pick up here that applies to what they have been working on, and to what they will be working on in the future.
All types of internal education is good for both the individual and for the company.
Just tell them!
tell them that there is no enough work for them
and listen to their answers for this question instead of inventing tasks to keep them busy
I can think of a number of things (some already mentioned but included for completeness)
Work on V. Next Try and get a headstart on the next release by working on some features from that version.
Adding unit tests You can always have better tests or additional coverage.
Improve the existing code Look at ways you can make the existing code simpler, fixing bugs, making the code more robust through refactoring, better patterns, comments, reducing the cyclomatic complexity
Improve the supportability work on installers, support docs, help files, knowledge bases anything that can save time and money later.
R&D Are you on the latest version of your frameworks and supporting platform? If not now might be the time to investigate and upgrade.
Having your coders work on your code would suggest there still is work, it's just work that was initially skipped. If the code, documentation etc. are in good enough shape for you, extra work just tends to be tedious for the programmers so I wouldn't tell them to keep on improving it. And besides, if they do, you also need to utilize your testers, and if they do have work, well, suddenly your programmers are costing money possibly for very little return.
A better thing would be to have them work on something else, there's bound to be projects that never got started or finished due to lack of resources or have them learn something new. Ask what (work-related) they would be interested in, and see if you can come up with some useful project and if these interests could benefit the company. If not, you could suggest something that do. For instance, there could be new technologies that need evaluation. What better than have a few of your programmers try it out and write a report? Then you'd know the pros and cons and the company could decide if the new technology is worth pursuing.
Educating your personnel is always a good idea if done correctly. Scripting languages, for instance, are usually not very well known but some skill in them can make your programmers a lot more productive.
Do it right and the company is in a much better shape when work is available again and your programmers will be a lot more motivated.
Library code: I've always maintained a list things I wanted coding in a generic way and added to a set of library classes.
If you are a service based company working in a specific area, e.g. database with browser front end or C# desktop applications for management reporting in banks (or whatever), then you are building up useful collateral by doing this.
If you are product based company then only bad planning and bad management would out you in this position. In this circumstance it seem only fair to ask the developer what would benefit them most at this point: learning python or writing a 5000 word paper on good planning practices in product development.
1) Ask them to take leave if their paid leave is pending. This way you can save your operation cost without affecting your production.
2) Ask them to write the certification exams (like MCP , Sun Certification etc..).
3) This is the right time to add Extra features to your existing application.
4) This is the right time to start some new project (new ideas implementation) from scratch.
5) Ask them to write blog or wiki pages. This would help to juniors.
Cheers Kannan.
Make them pass certification or ask them to learn about some technologies
Ask them "If you could work on whatever you would like---it doesn't need to be relevant to what $COMPANY does---what would you work on?", and nudge them into brainstorm mode.
If you don't get any ideas, see one of the other answers ;)
If you do get ideas, consider which of them might be useful to the company's mission.
Example: I heard on the SO podcast 50 that Steve Yeggi is going to work on integration between compilers and editors so you can have better syntax highlighting and more intelligent auto-completion. Google's people spend a lot of time in editors. Improving them is probably beneficial to Google (yet it's not related to their core business of advertisement and searching).
If the programmers dogfood the company software, they may have ideas for how to improve it (I've had that for a company I worked for). They may have broad ideas for how to improve your company's products that make sense.
In short: when you run of things for them to do, make them come up with their own thing to do. Let them do it if it makes sense.
If your product/project is based on 'old' technology (SQL 2000, VB-cough-6, Windows XP), look at upgrading to the latest version.
Get them researching VNext of your environment/framework/technology stack (i.e. .Net 4, Visual Studio 2010, Windows 7 etc.).
Get them to dig into other 'not-so-new' stuff that they still only have sketchy understanding of (Linq, lambda expressions).
Get them to have a look at new-but-potentially-useful languages - a functional language, for example, to try and understand what all the fuss is about.
Technical debt - get them to eliminate all the TODOs and HACKs in your codebase.
If your programmers don't have enough code to write for you, then you've got too many programmers. Take the executioner's axe to them. Never mind if they have mortgages, cars, children and wives, you do what's best for the company, and what's best for the company is to walk through that development floor with a purpose, leaving only death in destruction in your wake. You need to make sure you work on your evil genius laugh. When you're handing that developer his pink slip, and he looks at you and asks, tears welling in his eyes, "what am I supposed to do now?" You cross your arms, look down upon him and spit out, "that's not my problem!" Here is where that evil laugh comes in play as you walk away knowing that he is now a shell of himself, his heart filled with soul-crushing disappointment.
Code cleanup, refactoring, R&D and Education. Make them busy by making both your existing code bases and your employees better at what they do.
Give your programmers time to self-educate, make courses, cross-training. Perfect time for employees to become better.
Other than that, refactor and optimize.
Oh also YouTube! :p
Do you have any of those pieces of software that "someone should really do something about"? Start making a prototype for what should actually be done with it or even better, fix it if possible.
If you happen to be a developer with too little work, by all means you should improve your existing code quality by refactoring, adding unit tests, improving usability, increasing performance and so on. And you should learn new tools and technologies. But also be sure to ask yourself the hard questions, such as "Is this just temporary?" and "How is my company doing financially?": maybe you need to update your resume and work on your professional network too.
Excellent answers have been given here. But I may add what most of them implied :
Why don't you ask your developer what they think they could do to improve your existing softwares ?
Often, developers have great ideas but they don't have the time to implement and test them.
Examples of things I would love to do if only I had the time :
- Build a cache for some kind of data (it would speed up things by a 50% factor, I think)
- Create an autocompletion feature for most of the textbox of our product. I know how to do it and 3 days should be enough.
- Keep last data typed in every textbox and allow the users to use them with 1 click (they currently have to type a lot of long IDs) ;
- Make our main Visual Studio solution thinner. It currently holds more then 45 big projects and loading it take 2 minutes. VStudio crashes every hour or so (yes, a solution this big is a shame, you're right).
- Add comments ! Most of our code do not have comment. I try to comment as much as I can, but if only I had a week for this ! Refac
- Refactor incorrect classes, methods and variables names (would do it while commenting).
- Compress our inheritance tree. A lot of classes inherit of other classes without adding anything meaningful. A lot of interfaces are implemented by only 1 class. This is a real pain when you debug since Intellisens will always bring you to the interface, not the real class.
- Add traces and assert. Seems that some people who develop never had to maintain software. When an application crashes, you most often have nothing more then a method name, a vague error message, and, sometimes, a line number. We could have a lot more (parameters values, for examples) with a little more effort. We could have a summary of what the user have done before. We could have some indication about what was the data he was creating, modifying of viewing. We could also have a copy of the context (if it is crashing, performances are irrelevants :o)
Etc, etc, etc.
All the best. Sylvain.
- Refactor
- Consult on other projects (send them out to help other people)
- Profile, Improve Performance of application ( procs, memory usage, e.t.c. )
- Build in-house tools, libraries
- Automate something (build, CI, testing)
- Improve an Open Source project that you love and use already (re-invest in the comm.)
- Dev days, help improve dev skills, communication, meet somewhere relaxed and talk about process/feedback/collaboration/outside pet projects e.t.c.
- Abstract re-usable portions/components( reduce repetitious code e.t.c. )
- Create Scaffolding for future projects
- Test
- Complete Enhancements
- Upgrade frameworks, tools, 3rd party controls
- Team build excercises ( i.e. on in-house tools/frameworks)
- Estimate future work
- Give people new tasks/tools/frameworks/patterns to learn and train-up juniors (now is the time!)
- Investigate the "hot" control suites/open source projects/practices coming out, as a team are you looking into adopting something, assign someone to do a prototype and report back.
- Documentation, Comments (lol, yes this is the absolute last )
There is always something that can be improved, refined, refactored,
The good ones would come up with suggestion themselves, would write more code, and would definitely not wait for someone to give them stuff to do.
(e.g. fix broken stuff, research new features, implement tools to help development process, implement tools other people need and so on, look at new programming languages, automate more steps in build process, improve testing, test coverage ...)
And from my past experience, developers without work to do are looking for better job that is not so boring - I don't want to imply that your company is boring but from my experience developers want to be busy, they are not interested in doing 'in the mean time' tasks, as soon as they go to work where nobody is sure what to do they will start looking for other jobs.
Telling them to make their code less buggy and shitty becasue we all make shitty software with a lot of bugs: http://www.codinghorror.com/blog/archives/000099.html
Answer questions on SO. Clearly Jon Skeet doesn't have enough work to do :-)
Fix bugs. There's always a list of defects that normally wait until there's some relief from deadline pressure, especially if you were short-staffed (who isn't?). Well, now's the big chance. The code base will be better, and the crew won't worry that they're all about to get fired.
This does presume, of course, that you want to keep the crew you've got.
You should definitely send them to work at my company, there's a LOT to do.
Let them prepare speeches about technical topics they are interested in and ask them to present the results for all others --> some other kind of education
This only happens once in a blue moon so when it does the developers need to GO TO THE PUB!!!
- Have them mentor less experienced programmers in your group
- Research new technologies and productivity tools
- Have them pursue new/radical ideas relevant to your business
- Send them to training
- Have them implement a recycling program for all those cans of soda they drink. =)
Google gives their programmers "20% time", 1 day a week to work on anything they see fit. The majority of Google's highly successful products have spawned from this 1 day. If your programmers are idle, why not offer them something similar?