Aug
22
Written by:
StevenFeuersteinTW
Saturday, August 22, 2009 5:18 PM
[ It is very likely that if you are reading this you are a developer, but this is really geared towards software managers. So feel free to copy and paste into a Word doc and pass it along to your manager or team lead! ]
I very often give trainings and presentations on the topic of PL/SQL best practices. I offer lots of ideas for writing code that is easier to read and maintain, runs more efficiently, can be tested with less difficulty, and utilize more fully the best features of PL/SQL.
And all too often, the response I get to these ideas are: "They all sound great, but I know that when I go back to work, I'll just fall back into the same way I've been doing things. And even if I change, the rest of the group will still be stuck in the old ruts."
Well, that's depressing, isn't it?
When I was in Singapore last week, I gave one of those "Here's the right way to do everything" talks to a group of developers at a major financial services firm. Then I met with the Deputy Director of IT and he presented me that same challenge:
"How can I get my people to change the way they do things?"
So I decided to try to come up with an answer. Here's what I suggested to him:
Champions
Research Time
Team-building Reviews
Incentives
Selective Enforcement
Perhaps I should go into a bit more detail....
First of all, it is important to recognize that the biggest challenge to bringing about change is not making sure that developers know about the new features and the right way to do things. The technology is actually the easy part. The hard part is to change behavior. We are all creatures of habit, and we like our comfort zones. They're so comfortable.
Champions
For any new product (we were talking about Quest Code Tester, but it applies to anything) or major new feature, you should assign a person on your team to be the "champion" of that technology. They should become expert in the technology, be enthusiastic about what it can do for the team, and they should be ready, willing and able to mentor others.
Without a strong proponent of a new direction, you won't be able to build the momentum to ensure a solid, consistent, team-wide implementation. With a champion in place, everyone on the team knows who to go to when they get stuck. And since the role is well-defined and "public knowledge," there is no reluctance to approach the champion for help.
Research Time
I continue to be shocked at how many developers still do not seem to know about and use many important features added to PL/SQL in Oracle8i. Yes, Oracle8i. Things like: invoker rights, autonomous transactions, FORALL and BULK COLLECT. And then of course, there are the many new features of 9i and 10g, such as string-indexed collections, MULTISET operators, DBMS_UTILITY.FORMAT_ERROR_BACKTRACE, and more.
It's easy to understand why so many developers remain ignorant about such things and consequently under-utilize the language: they don't have the time (or feel like they have the freedom) to explore PL/SQL.
Managers usually ask just one or two questions of their developers: "When you will be done?" and "Why is your code so buggy?" Neither of those questions are conducive to expanding one's knowledge of a programming language.
I strongly urge managers and team leads to ask each developer to come up with a research plan: spend 4 hours every two weeks (5% of your time - more is better, but I don't want to sound crazy) exploring technologies that could be helpful to the project.
Insist that the developer not work directly on application code, but also that they put together a proposal for precisely what they want to study and why. They will feel great about the opportunity, and both the team and application will benefit in short order.
Team-building Reviews
Everyone knows that code review is a good idea. I would even go so far as to say that no critical code should go into production until at least one other human being (besides the one who wrote it) looks it over and makes sure it isn't totally crazy (that is, unreadable spaghetti code). Often the form of such a review is "one on one" - the team lead looks over the good and gives private feedback to the developer.
That's not what I'm talking about here (though it's a fine thing to do!). Rather (or in addition), I propose that once a month, the entire team gets together to critique, as group, a piece of code. The aim of the review is not so much to find flaws in code, but to share knowledge about the application and elevate the whole team's awareness of how best to use PL/SQL.
Whoever is the senior developer on the team should take the lead; you can't expect junior programmers to be willing to subject themselves to potential humiliation (at least not until they see there is nothing to be afraid of). The best developer should set an example: everyone's code can be improved; it's OK to make mistakes; we can all learn from one another.
Incentives
What's the best way to motivate a developer: carrot (incentive) or stick (punishment)? We all know the answer, and not just for developers: we aren't motivated to change for the better with a threat of punishment (though we may still change because we have no choice). I think the world would be a far better place if without coercion.
And certainly when it comes to getting developers to create higher quality software, well, it's really important to make that they want to do. So....let's use incentives!
Managers should identify ways to measure objectively progress in important areas, and then give out rewards (both recognition/status and goodies, like gift certificates to restaurants, Amazon.com, etc.) to those who are high achievers in those areas.
Here are some ideas for possible metrics:
- Reusable code: we don't want to reinvent the wheel, but sometimes it's hard to find and reuse code. Perhaps prizes will help. You can run searches through the code base to find all external (not in the same package) program calls, for one example. And I suggest you give a reward for (a) the person writes the most reusable code - usually a senior developer, and (b) the person who uses the most reusable code. That way even a junior developer has a chance to win and is very much incented to learn from the use the work of others.
- Naming standards: we usually have some set of naming standards, but how do you check to see if people are following them? Consider installing Oracle Database 11g on a workstation, load up your application code, and use PL/Scope to analyzer variable declarations. For an example of a query that demonstrates this powerful feature, check out the AMIS blog, and search for "PL/Scope".
- Unit tests (especially automated tests): I would give out a really substantial reward for a developer who does the most automated testing of their code, building and putting in place regression tests. This will have the biggest impact on the quality and success of your applications, so get people motivated to do it! It will greatly help to provide a tool to make it easy(ier) to automate the process. Check out Quest Code Tester for Oracle, utPLSQL, dbFit, PLUTO or PL/Unit.
Selective Enforcement
No doubt about it: carrots are the way to go. But that doesn't mean that you (a manager or team lead) shouldn't be ready to bring out the stick now and then.
Well, that's probably a bad way to put it. I am not making an argument for punishing developers if they don't do things a certain way. I do believe, however, that a manager should in at least some cases, insist and enforce certain critical changes in behavior. Some things are just too important to leave up to developer preference and hopes for good behavior.
The following areas come to mind:
- Testing (yes, that again): let's face it. Our applications have too many bugs in them. That's not only a big drag for our users, but it makes our live miserable, too. Rather than focus on building new applications or adding interesting functionality, we spend way too much of our time putting out fires. We are stuck in a vicious cycle: no time to write better code, because we have too many bugs to fix. The only way out is better and more automated testing. Managers should find tools to help make this a reality (see list in previous section) and they should insist that developers write repeatable, automated tests.
- Version control: it seems obvious, but I still run into development shops that do not have VC systems in place. Sometimes I even encounter developers who do not maintain their source code in files, but simply edit and compile right out of the database. Totally insane! That's a sure recipe for losing work and creating terrible frustration on your team.
I could list other ideas, but I don't want to end this note with too much of heavy hand. And managers should definitely not go overboard with putting lots of new requirements in place at once. Phase them in, and make sure that you provide support (tools, champions, training time) to ensure success.
No Guarantees But It Won't Hurt to Try!
Maybe none of these ideas will make a difference in your team, but surely it's worth trying some new directions to see what if anything will stick.
I have no doubt that developers will be excited to see their manager trying new approaches, especially ones that don't simply mean more work and longer hours.