I've been thinking for a while about creating the One True Process that would ensure that code that passed it would be Good Code. Let's call this the Golden Colander. It will be a way to filter out all the bad code and only allow the "golden" code through. Think of it as an idiot proof automated code review.
Conceptually, if you had something that was this good, you could get that army of infinite monkeys with infinite keyboards that you always wanted to do all the grunt work.
If you had this Golden Colander you wouldn't have to manually code review someones work, you wouldn't have to run code coverage on it, it would be automated, fair and black and white if code was good.
A couple of things pop into my mind as I go down the path of this thought experiment:
1) I would be out of a job. :-(
2) at this time and for the foreseeable future, this is an impossibly complex tool to build. Not going to happen any time soon.
I love automated tools and love to apply them to any work I am doing. But there is one "failing" of the tools I have seen: there is nothing that can make as good an evaluation as a person. Compilers might tell you if variables are not being used or other common problems, but it can't tell you that you are doing something architecturally stupid. You can add unit tests to a project, but not force anyone to run them. You can say "add comments", but there is no automated process that can evaluate if they are good comments. These are some of the things that I would love to fix if there was a Golden Colander, but alas, it's a myth.
Thinking about these things has brought me around to the value of a code review (or pair programming). Nothing can help to prevent brain dead decision quite like explaining it to your peer or superior. It's funny how little shame is required to get people to think things through or be a bit more careful.
Now, catching things in code review is great and all, but that's reactive. The damage has been done and now you're in "fix it" mode. I have found that it's far better (cheaper) to do something right the first time than doing it crappy and then re-doing it. What does this mean? You must hire the smartest people you can to do the job. 2 people that that are 1/2 as smart as personA else won't do the same quality as personA. They'll do worse, just faster. This applies to every field that I can think of, not just software.
Since google only hires the smartest people, I bet that the QA department has a much harder time looking for bugs than other places. It's like in cooking, if you want better tasting food, start with the best ingredients you can.
I'm going to end it here since I think that I am rambling but here's the conclusion: no process can compete with starting with the smartest people for the job, and giving them the right tools.
You must hire the smartest people you can to do the job.
ReplyDeleteI don't think this is always the best idea. I think it should be more like "You must hire the best people you can to do the job". I changed best for smartest because I don't think that sheer brain power helps in every situation. First, you don't want to have really smart people working on really easy stuff, because although they may be able to do it well (assuming they don't get bored and quit), you are wasting a lot of money by paying someone really smart (who demands a high salary) somethat that someone of lesser skills (who demands a smaller salary) could do just as well. It's OK to hire people who aren't the "smartest" as long as the tasks they are doing are within their capabilities. You don't want people with PHDs programming web forms and fixing font colours all day. That's a waste of resources in both money, and in brain power. Those PHDs could be doing much more important stuff with their time.
Okay, yes, "best" can be switched for smartest.
ReplyDelete