Do you have or need a Software Development Enthusiast?
Posted by robkraft on February 3, 2011
The question I keep asking myself throughout the day every day as I develop software is, “What task is most valuable for me to work on next?”.
- Should I begin coding the next feature in the software?
- Should I implement an automated build process?
- Should I write some unit tests?
- Should I spend an hour learning how a new technology like cloud computing may impact the way I should be designing code?
- Should I upgrade the RAM or CPU on my computer so I can work faster?
- Should I document this complex bit of code for the sanity of the developers that follow me?
- Should I spend time evaluating all the things I could be spending time on?
Of course the answer is rarely clear and the possibilities are daunting. Not only that, but most programmers already know the basic processes, tools, and patterns they need to solve the next problem, so they are disinclined to solve the problem in a better way. So week after week, month after month, year after year we solve problems as we always have unaware of the advancements in hardware, tools, processes, and techniques that could help us develop twice as fast with higher quality. But what can our software developement industry do about this problem?
As a software development enthusiast, I have a few suggestions.
1) Every software development shop needs a software development enthusiast. This is the guy or gal that enjoys writing software and learning outside of their normal business hours. This person writes code and learns how to be a better developer even when he or she isn’t getting paid to do so. If you don’t have one of these in your shop, you should have one come in at least twice a year to give you a list of suggestions about how you can improve your development.
2) Become the software development enthusiast. Even if you only do so during work hours, convince your boss that you need to spend an hour every day reading blogs, computer industry email blasts, researching new tools, listening to podcasts, and watching training videos to learn and incorporate what you learn into software improvements at your shop.
3) Arrange a Structured Information Exchange (SIX) meeting with someone from a development shop that is similar to yours. Share information about your tools and processes for resolving the problem spots in your software development process. Check this blog again in a few weeks for more information about SIX meetings.
4) Get into a program or on an email list that will help you migrate through stages or levels of software development maturity and that helps keep you informed about the latest developments that specifically could improve your software. Where can you go for such a list? I don’t know yet, but I think if someone creates a service like this, they will have a lot of people that want to sign up.
5) If you want to do it yourself then I suggest you adopt the Continuous Process Improvement mindset. There will never be an end, you will always be looking for ways to get better. You will need to create a list of problems, and areas of possible improvement. Then try to assess the amount for improvement in each, perhaps a list of possible projects you can implement and the cost to implement each along with the return on investment. Prioritize based on the greatest improvements for the least cost and begin implementing the projects on the list. Every journey begins with a single step. Of course implementing a Project Management Office to manage all these projects, or spending time assessing, estimating, and evaluating all these projects may take more time than you want to devote. Sometimes it is better to just jump in and implement some process improvements before you know if it is the best possible process improvement you can implement.