lightweight, sustainable processes for good code/design quality?

Question

Ok, gang, next question: what do y'all think are the best processes to improve the quality of the code the (corporate) team produces?

(The cult of quality question was good, but I'm looking for specific suggestions of things we can do.)

Background: the team is diverse, in the usual way:

There's the brilliant coder whose code is impenetrable and undocumented and whose ability to communicate isn't as good, which manifests itself as impatience or excuses of busy-ness.

There's the middle-of-the-road developer who just wants to get his/her work done and go home. New methodologies would be ok, but he/she won't initiate.

There's the person who really doesn't want to change (i.e., is hostile to change, for whatever reason), satisfied with their current level (the old way).

There's the person who really doesn't know what the possibilities are, they're just copying everybody else's code (and that works, too).

There's me, of course, the handsome, charming, brilliant developer who takes the time to write good, clear documentation and unit tests and just wants the best for the group and isn't satisfied with the status quo (technologically) and couldn't possibly be the problem.

There are all these beautiful principles out there: OOP (highly coherent, loosely coupled), functional programming (what I mostly see here is /no side effects or in-out parameters/), strong static typing (no runtime type errors, method not found, etc.), separation of concerns (business logic separate from UI and database).

And there's the old school of huge blobs of code that do multiple things all sort of intertwingled together, and global variables and their cousins the singletons and the huge classes with lots of data members.

So, how do we get from point A to point B? Grass roots suggestions get ignored. [edit: well, to be more accurate, a single developer running around telling people what they're doing wrong is not the best way, from both managers' and peers' points of view. I don't do that because I don't want to be Cassandra.]

Can we do abbreviated code reviews? Like... just call out what your new classes and methods are (ignoring implementations). Or call out (in English) where you added new functionality (i.e., which method did you update to do what)?

What if the person(s) who need to review that stuff are constantly in meetings (you know how that goes: new features, partnering, crazy deep bugs that have important customers screaming[2])? Would a wiki or some sort of social thing work, to get more eyes on the new designs? How do we get those who don't want to be involved involved?

So... lightweight, sustainable, effective processes? Any ideas? What works for y'all? (I know people are going to say pair programming. Ok, granted, but that ain't gonna fly here.)

Thanks.

[2] Ok, overblown language. s/screaming/focused on particular bugs/

Answer 1

Involve the Team

people resist change

people resist change that they initiate, even when beneficial

but people really resist change that is thurst upon them

and people vehemently resist change that is thurst upon them with the implication that they are wrong/slacking/not-good-enough/etc

If you want the 'best practices' process to fail - and fail hard - keep painting yourself as the handsome hero, everyone else as dullards and dolts, and call every suggestion you make "best". People love the implication that they are inferior, it really motivates them to listen to your ideas objectively. NOT

On the other hand, if you want it to succeed, take a lesson from the Agile Manifesto, and let the team self-organize and self-select the processes that are appropriate, with avenues for incremental improvement

In other words, you cannot choose best-practices for the team, and neither can we, because the best practices are the ones that fit the team, and that the team will accept

Answer 2

You cannot initiate processes if nobody else will listen. This is the sad and harsh reality. YOU may know what makes good code and quality design that sets a proper foundation for the future, but if you're the only one then it's doomed, and no amount of trying to change things will fix it. If people wanted to fix it, you wouldn't have to ask how to implement a process because everyone else would be on board with you or would already be trying before you got the idea to try to persuade them.

I know I trot this old saw out every time a post like this comes up, but having been in situations like this for nearly my entire career the only end result has been either my being terminated due to wanting to improve things and constantly trying to bring it up (even subtly), or getting frustrated with the fact nobody except me wants to improve things or, often in my experience, even knows how to improve things, and quitting after a couple of months of frustration and "Why isn't anyone even aware of better ways?" moments.

Now, I'll offer some optimism. If, and only if, others on your team (at least one other person, so it's not only you - otherwise it looks like you're just whining instead of trying to help out), then you can start slow. Write your own code properly, of course. Bring up minor quality concerns during meetings or code reviews if you do them with other developers (e.g. things like "This method is 1000 lines long, it should be broken up", or "We should break out these four pages/screens into reusable components so we don't duplicate code"). You must start slowly, and you must have buy in from other people, or you will just burn yourself out and regret coming into the office every day.

Answer 3

All the principles and best practices in the world aren't going to help any if the people above you don't buy into the idea or don't really care to. With that being said you mentioned "grass roots suggestions are ignored" which really means that they don't care what you have to say about the process.

This is not necessarily because they are bad people, perhaps just because they are so overworked and unbelievably stressed out by "important customers screaming at them" that they simply don't have time to take a process that is good enough most of the time to entertain the notion of establishing an excellent process all the time. Running a business is a dirty thing sometimes so change has to be incremental and people pushing for it must be persistent and patient.

With that being said code reviews don't have to be involved with the leads or the managers, in fact sometimes it is better if they aren't involved at all. Getting two peers and equals together to review a new module gets BOTH developers thinking critically on the code and running through "best practices" in their mind, even if this is normally considered a BAD developer, this person will be forced to consider the practices by actually judging on them. You will find that people resistant to established practices will soon start changing their coding behavior to avoid criticism in code reviews. Further it fosters leadership amongst team members, supports ownership of a feature as well as improving code quality.

Code reviews improve DEVELOPER quality, and the best part is that your direct superiors who are busy putting out fires need very little involvement.

Answer 4

I would highly recommend buying a couple of copies of Martin Fowler's excellent book on refactoring. The principles in there can be applied even of the starting point in your code base is a complete mess (although it's easier if there is some structure).

In order to get any mileage out of refactoring, though, you'll probably also need to start implementing unit tests and automated integration tests, so that you can experiment with your code base without being petrified all the time coz you have no idea what's going to break if you change this or that bit.

You can introduce this on your own and wait for others to marvel how come you are suddenly starting to achieve hyper-productivity (because that's where you are heading), and then follow you. Or you could talk to a few sympathetic souls and get them to join you. Or you could try and introduce this to the team as a whole. Obviously the best would be if your team leader/scrum master/whoever is in command would pick up your idea (and that usually works best if (s)he thinks its their own idea!) and run with it.

Of course you can do code reviews. But I promise you, once your code base is covered with unit tests, you won't them any longer, other than to make sure everybody's code adheres to the same style rules.

How to get people involved? Hmm, difficult. I would have thought that even the folks who just do it for the money are at least interested in keeping their jobs. So if you are in any kind of position of power you maybe want to sit them down and make them understand that working in a team means getting involved, and if they cannot or won't do that then there's a mismatch between them and the job spec.
For all others it's probably best to do a little bit of work on your own and then present the results. That should get them interested. And seeing that you are already doing that, all you really need to do is sell it to them. Prepare a little demo of how well your unit tests work and what they allow you to do. Demonstrate refactoring. Illustrate time savings.

The usual problem is that more often than not good coders are bad sales people (and vice versa. I know because I have been in both camps). And now I am asking you to become a sales person. Considering that most likely everybody else in your team is an eve worse sales person (otherwise they would be posting here instead of you), you should have some success even if you don't do a brilliant sales job.

BTW: the brilliant coder who is too busy to explain himself is actually more of a liability (think of the "hit-by-the-bus" scenario). At the absolute very least he needs to document his code, otherwise you might as well get rid of him now. Remember that you don't write code for the computer. You write code so that other coders can read and understand it. The computer could be fed with a compiled stream of bytes, it doesn't care about programming languages or syntax or any of that.