Smart and get things done, good enough?

Question

I have been troubled by some stuff for some time now and would like to hear if anybody has opinions about it. Over the years I have seen several developers that would be considered smart and get things done. As it turns out the code they make is surprisingly crappy.

I certainly don´t claim to be an expert myself but there are issues I consider any decent developer must know about, such as proper naming of variables, methods and classes, which goes a long way to making cleaner code. Other things include issues such as, code should be readable, easy to understand, preferably have some thought behind it, use small methods instead of mammoth methods with hundreds or even thousands of lines of code in it. These are things that in my experience (11 years) has been proven to work well no matter what kind of project I have been involved in.

In the last 2 to 3 years I have been working with several really smart guys.I have seen them solve some really tricky problems and I have seen them use some rather advanced programming constructs. They have been able to get some advanced stuff working.

So they are truly smart people and yet the code I have seen them do is totally unacceptable by my standards. Do I have a right to judge them considering they are smarter than me and that I certainly need their help at times? Well, here is my problem, the code they make have crappy variable names, very very long methods and OO design is absent but the code tries to be OO. (In one medium-sized project the smart developer had only used three! classes, that is not OO to me.) Once I had a suggestion for an improvement, plenty discussed with a developer I totally trust, and implemented it. One of the smart guys remove my code and reverted it to the old ways "this is the way it always has been done before". And so the list goes on.

Som my questions are something like this: Firstly, am I totally missing something here? Is good variable naming unimportant? I am a sucker for code quality, and perhaps I am overdoing it? How do we define smart? Being able to do sophisticated c++ code and being able to do some smart algorithms, is that by itself smart enough? I don´t know what to believe, either the smart guys aren´t really smart and mess things up or I have to rethink my own ways of doing things.

What do you folks out there think?

/Confused developer

Answer 1

If you want a maintainable code base, you need to have standards. Naming conventions and methodology are both an important part of that - so you're right to want these things to be correct.

It doesn't matter how clever the developer writing the code is - it's the developer who will maintain it that you need to worry about, so you need to teach these genius-developers a few conventions.

It helps if...

1. You write down your in-house coding style
2. You get the buy-in of someone who has some authority to say how things should be done

YOu can then raise the issues with people, with a firm house style. If they don't like the style, it raises a brief and purposeful discussion about whether the point in question should be adjusted in your house-style.

Answer 2

You are already asking the right question: "How do we define smart?". Obviously a coder who arguments "this is the way it always has been done before" is not very smart. In my opinion a smart coder is smart enough to know the benifits of a clean coding style (like good variable names). Just beeing able to write a fancy algorithm does not make you a smart coder. Self-reflection is very important, too.

On the other hand - you are writing about a lot of project-manager topics. Smart developers should know, that a clean coding style is important - but the coding style itself should be existing already and its correct use should be controlled (automatically as far as possible).

Answer 3

My opinion would be that they're not "smart". Smart does not just mean knowing the technicalities of something. It means being able to implement that knowledge in a sensible, manageable and future proof way that other developers can continue to maintain.

If someone is an autistic-savant when it comes to solving development problems, with complex code gymnastics, then they're not helping you or your team (or the product) if its nigh on impossible to maintain that code in the future.

Answer 4

Being smart and getting things done is completely different from producing maintainable code.

It's two diferent qualities all developers should work on.

The first is hard, it comes from a mix of talent and the strive to continually learn. The second is easier to learn, but sometimes harder to accomplish. I personally try to develop allways thinking wether or not my code will be maintanable in a few months/years.

Theres a well know phrase about maintanable code (i'm sure some will remember) that says something to the effect of : allways code as if the person that will be maintaining your work is a madmen with an axe and knows where you live.

Answer 5

It's hard to judge from what you describe.

IMO, these are the "rules":

• The best solutions are the least expensive - considering development time and the maintainability.
• Bad maintainability is more expensive then a few hours or even days additional implementation effort.
• Readability is most important for maintainability.
• Naming, structuring and order is most important for maintainability.

I have worked in a few projects where they made things very different. You can't change existing projects by one day to the other.

• It's most important to have a common understanding how structures should be done.
• You get worst structures when every developer does things how he ever did, ignoring how other team members are doing it.

The "smart" people say your code is not how things are done in the project, either because they don't know how to structure code or because you don't understand their structure.

It could be that the structures are not really object oriented. I know more projects that are not really object oriented then such that are. Nobody says that this is not sufficient for certain projects.

If you think that the project really suffers from poor maintainability, you should propose to go to a higher level. First steps are better names (anyway) and better structures, next step is toward OOP. Developers need to be taught, also the "smart" ones. Send them to OO trainings. Learning real OOP takes years.

Then you as a team should agree in where new structures will be applied, when and how old structures are going to be refactored.

You are in a team. You need to agree in how things should be done.

Answer 6

Shipping is not a feature.

I would consider myself just as picky as you describe yourself when reviewing code and writing my own code. But since I've had the chance to be an entrepreneur / programmer I have seen how little code quality matters in terms of the bottom line. If you don't ship, you don't eat. You can have the best code in the world but if you can't ship it or sell it, it's worthless.

So it's important to try and balance the two, that's the REAL trick in my opinion. ;)

Answer 7

With "Smart and gets things done", you're referring to Joel's "Guerrilla Guide to Interviewing", and if you read that you should know what he actually meant with "gets things done": Someone who's able and willing to work towards an actual practical result, without getting distracted by dogma, lofty ideals, personal interests, excessive generalization or architecture spacefaring.

That doesn't necessarily mean a cowboy coder, but certainly someone who's pragmatic. Also, remember that Joel is looking for employees, not independant contractors. An employee with cowboy coder tendencies can usually be reined in and convinced that coding standards and good design are important.

In the end if you're in the business of selling software, crappy code that works is still infinitely more valuable than a piece of code art that does not work because the developer spent so much time polishing the details of an overengineered framework that he never got around to implementing the actual functionality.

Answer 8

Smart / Not smart is, in many ways, an illusion. Can your guys produce what you want? In this case some of them are excelling at part of their job and falling down on another part.

I work for a helicopter company and am considered "smart" however I have learned more about quality in the years that I have been here than in the rest of my time in the software business. Most of what I have learned has been from "Not so smart" people. Quality is not about smart/not smart. What it is about is to much to go into here, but check out http://en.wikipedia.org/wiki/Quality_management . Watch out for ISO 9000, one of my managers says it can suffer from concrete lifebelt syndrome, if you make a concrete lifebelt, it can help you make it perfectly.

A few points:

Do you have a set of standards for coding, either your own or somebody elses published set? If you don't then your programmers won't follow them, so that is the first step.

Do you have a "No Blame" Culture. One of the enemies of quality is blaming people when they do something wrong. The best responses are of the type "You need some more training on that".

Do you audit your code for quality? Let you programmers know that you want to improve software quality and that as part of the system, some of them will be trained to audit code against the standard. Audits don't need to be threatening, it is simply a case of saying OK Para 1.7.1 says you should follow such and such naming convention, there is little evidence of you doing this, this is a non-conformity. This is fed back into the quality system to decide what to do about it. If you have a guy that solves hard probelms consistently produces unreadable code, perhaps they need to have more of an analyst/designer/prototyper role.

http://en.wikipedia.org/wiki/File:Capability_Maturity_Model.jpg

Answer 9

"Smart and gets thing done" is supposed to be who you hire.

That doesn't mean after you hire them you chuck them all together in a room, shut the door, and hope for maintainable elegant code to emerge.

By analogy, If I stuck all the correct ingredients for pizza together in a bowl, I wouldn't get pizza.

After you have made the right hires you need to apply all the software engineering practices that produce the standard of code you are looking for. That is not "Smart and gets thing done". But that's not what "Smart and gets thing done" is for.

Answer 10

I guess that it's all a matter of defining what those two things mean (ie, "smart" and "get things done"). For instance, according to your definition, those developers won't really match the definition of "smart and gets things done" simultaneous because it looks like you value some specific standards in code.

And if you have code that works but doesn't comply to a specific standard you value, then things aren't really done - yes, to me there's a difference between having a working feature and having a complete feature (where complete means that it works - which, of course, is mandatory because we must satify the guy that is playing the bill - and that the code has reached a certain level of quality). There might be some times where you might not really have the time to write "beautiful" code; however, the great developers I've found along my programming life do have the tendency to go back and improve their code through refactorings

Answer 11

They don't understand OOA/D and they won't grasp it unless they are spoonfed with it. What makes it even worse is that some of them really think they know what OOA/D is and as Stefan Steinegger said, it takes years to fully grasp. I've had a formal education in it and I still have a long way to go before I master it. Misconceptions are harder to cure than simple ignorance. My conclusion is that the only chance is to have someone with authority to ask them the right questions, like issues about maintainability, unit tests etc. Can they define what a unit test is? Can they tell unit tests from system tests? Can they give a good explanation of coupling/cohesion and why they are important? Do they know what makes global state a bad idea in many cases? How many times do they think code is read versus written? Another common statement is "theory and practice are only the same thing in theory" which I believe is a bad excuse for introducing technical debt. It's alot about getting your priorities right.

Answer 12

I am working in a small society, and we are working on both the hardware and software part. None of the developper as a real software background, since we all have a scientific background with very little exposition to C code.

After some years working here, and because I am working on the linux part of our devices, being exposed to open source software gave me some interest in the field, and I started putting my code under version control, read some blogs and books and got interested into software quality.

I consider my colleague as 'smart and get things done'. One of them particularly fits the description. And the produced code is far from being reusable or versioned or fully understood. So definitely, smart and get things done without any consideration to code quality is possible, but I guess it is not scalable. As long as you can "manage the complexity", you are in the get things done area, but when complexity increases, being smart is not enough.

Answer 13

According to Joel, there's also a third: Not a jerk.

Answer 14

Smart and clean code are impossible to define. It all depends on the developper's background.

Some constructs will feel straightforward for Ruby, Python and C developpers. Trying to mimic them in PHP would confuse PHP developpers (eg. how to escape a small loop on errors? Using for(;;)...break, using continuations, using catch/throw, etc. feels natural, but not for PHP-only developpers who think that writing a new function and using "return" is the only natural way to do it).

Functionnal-style programming will feel natural for people who use functionnal languages. Try to do something similar, even very simple, in a procedural language and people will find that complex and messy.

Since PHP hasn't had namespaces until very recently, object-oriented programming is, for PHP developpers, mostly a way to reuse function names in different contexts. Most PHP object-oriented apps use nothing but classes that are just instanciated once, or with nothing but static methods. This is what they will define as something smart. This is what a Ruby or Java developper would cry at.

So, your mileage may vary.

Answer 15

According to Joel def: if they solve problems with crappy code - they are not smart. And I think this is the point. Smartness does not mean "good talker". Smartness does not mean "solves tasks"... Smartness means "solves problems, and the solution is efficient and elegant".