Good programmer is the one that put code into production?

Question

Recently I found on a blog this:

" So I changed my mind and now my single reason that identify good programmers is “A good programmer is the one that put code in production” it means that good programmers makes programs that works and works for long time. Surely I really think that with DI, IoC, AOP you can create better programs, but the fundamental stuff is to put code in production. Bad programmers do not put a lot of code in production, because if they produce crap software, they will begin to spent so many time in maintenance, that they will not be able to ship anything anymore. Good programmer at other side, makes programs that work, they put them in production and then just leave them away, to return only when the customer needs another release. "

So what do you think about this?

Answer 1

It's true: the ability to deliver trumps pretty much everything else.

We all like to solve problems and come up with solutions but, let's face it, that last 10-20% to get something across the line just sucks a lot of the time. You tend to be dealing with minutiae at that point, you're fixing bugs people find, all the key development is "done"... it's just a support problem.

Yet finishing it is key.

It's also why I think having a college degree--regardless of the discipline--is important for a programmer: it demonstrates persistence and the ability to see something through for 3-4 years.

Answer 2

The problem with that is some code is harder to produce in large quantities than others.

Answer 3

Sounds like it misses the common scenario: a bad programmer produces rubbish software which is band-aided into production, but then causes a maintenance nightmare once it's already there. Shipping something is easy. Shipping something which works, continues to work, and can be maintained over the long term is much harder and more important in most cases.

It also ignores the fact that there are many reasons why code may not go into production, some of which are out of the programmer's control. Steve Yegge mentioned on the podcast that his previous projects at Google had been cancelled - does that make him a bad programmer?

Yes, getting code into production is important. Doing it as quickly as possible is not the be-all and end-all though. Better to get something maintainable into production in 6 months than to rush something out in 5 months which then takes a year to actually turn into something useful... you've got to look at what's shipped over the course of many years to really get a good idea.

EDIT: As Cletus points out, the post is really geared at "the technology isn't important; shipping is". I agree with that aspect. I just disagree with the overly-simplistic statement. Even if you take into account the extra part: "makes programs that works and works for long time" it isn't quite enough. While I certainly appreciate the YAGNI philosophy, I've seen plenty of code which just about works at the moment, but is a complete nightmare to change because no thought was put into future work. I'm not saying we need to go overboard on this, but again it's the long-term impact which bothers me. If the current code "works for a long time" because no-one dares to touch it, that's not good code.

Answer 4

Good programmers produce code with less number of issues and not a bug free code.

On the other hand, it might be in-correct to think that all shipped code are written by good programmers. Take the case of Windows ;-)...

Answer 5

Well, I would extend it a little bit. You are true that the first lecture is to make it work, than to make it reliably work. For the latter you already need a good programmer.

Every product suffers from changes in use cases. So I would say that a good programmer can produce production quality code that is able to be altered with less effort to fit in a altered usage scenario.

Answer 6

hmm...

A programmer who puts out stable code into production is a good employee, but not necessarily a good programmer. A competent programmer yes, but a good programmer?

A better programmer might indeed obsess over features and architecture. I don't want to get into "that" discussion, but as an extreme, this programmer might not be a good employee....but he might indeed be a great programmer..?

The point is, I think that quote is far too simplistic to mean anything.

Answer 7

I'd say a good programmer is one that put code into production…

…but I'd up the ante by saying a kick-butt great programmer puts maintainable code into production. Bad software that comes out will cost more in maintenance than good software. It should makes perfect business sense in the long run that bad software should be cancelled, preferably early.

Answer 8

I think it misses the point that a Programmer is not the same as a Software Engineer and the responsibilities of the latter lead to well-designed and well-developed applications.

Answer 9

To my mind the quote is wrong. Good AND bad programmers end up getting code into production and in my experience they seem to do so in roughly equal measure. On average 80% of a software project is maintenance anyway so getting to the production stage is not the complete measure of success.

The quote would be more correct if "getting software into production" was preceeded by a rigorous QA process.

Answer 10

This rant

• simplifies the evaluation problem to "good" and "bad"; a switch is easier to make than a potentiometer, but the latter serves a greater purpose.

• takes the programmer out of his context: he's just a member of a team. If he would get crappy specs, he would be a great spec-corrector if he put great code to work.

• doesn't differentiate between working code and maintainable code

• has a point that 'real life' programmers shouldn't go too academic too often (as I tend to do, but I'm working on it :) )

Answer 11

Some programmers are simply incompetent; they produce crappy code that accomplishes 60%-80% of the requirements, but is so buggy and unreadable that it never ever reaches production quality.

Other programmers are so enthusiastic about quality that they spent too much time discussing minor topics; redesign their architecture again and again and try to follow all the best practices they can find, only to find out that by the time when they reach the 50% mark, their application design is already outdated, because someone has invented a new fad that has to be followed. Eventually, they run out of budget and the project gets cancelled. Like in "Duke Nukem Neverever".

Good programmers are those who create programs that meet the goals. It should not be a big, unmaintainable mess, but when sacrifices have to be made, so shall it be. Good programmers accept that perfection is a goal that is too costly to archive, though it should always be pursued. Good programmers deliver acceptable quality in time and bugdet.

Answer 12

I can agree with Andy AND with Spoike. What I mean is that Andy is right that there are good programmers and good employees and that being a good programmer does not mean you are also a good employee. BUT, there is a big but... Sometimes a good programmer, with clear ideas and good arguments why things should be done the way (s)he suggests can be ridiculed by his/her fellow employees because they don't understand what is been said. I was in that situation once and even my direct boss did not want to listen. So, was I a good employee? Probably not in the eyes of my fellow developers and my boss! Was I a good developer, I tend to believe I was and still am. Spoike is right if good code is also maintainable code (and well documented!). That is what I was after. I left that company on my own initiative after being told that I had to shut up and simply do as I was told.

Answer 13

I think it's not about putting code into production, but useful, usable features.

I'm working on an analogy to explain why LoC is a bad metric for performance. The one I got so far is this:

Programmers go out a get the deed for a plot of land, then proceed to build an invisible building on that plot of land. They have to pay property taxes based on how much land they use, and generate revenue based on how much space the building has. Obviously you want a tall building: more space in less land area. But base area limits how tall you can build, too. Also, really tall buildings leave the occupants uneasy (an least in Manhattan).

The run-down: land area is code size, building height is feature set. Each feature has some minimum amount of code it takes to implement. Too many features and usability goes down the drain (that's the 11th of September analogy).

Productive programmers are those who are the best enablers of the software's users. They put features not just into production, but to use.

I think you need to control for popularity of the software, but I'm not sure how you measure what's left. Otherwise, a coder at facebook who writes two lines of no-op code is more productive than a guy who writes a two-line C compiler which nobody uses.

Answer 14

Without having the production server crash after the update...

Answer 15

I think it would be hard to find someone to take the opposite side and say "undelivered code is good code," unless it is some low quality bad code.

Customers also (sometimes understandably), have a hard time estimating how many developers they need to hire for the list of features they want. If you cut enough features to ship code, you still could end up with unhappy customers. You also have to manage customer's expectations to the point where you have the feature list down to what is possible with current resources.

Answer 16

Well, you got 9/10 in my books... I'm ok with all u'v have said.

All the best.

Answer 17

The OP's central point is valid: Putting code into production is very, very important. All the other goop (DI, IoC, AOP, etc.) should support that primary goal. The extra technology should be there to help deliver functional code into production.

I'd also want to see what happens after that, though. We've all seen projects that limp across the finish line, becoming a "declared victory" even as they demolish operations. There is, without a doubt, a massive framework backlash rampaging around the 'Net. It's only partly justified. To the extent that these frameworks let me separate concerns cleanly so I can continue to evolve a system without code rot, they have value. To the extent that programmers get caught up in feeding the framework, they are not delivering value.

"Feeding the framework" is any additional work necessitated by the use of the framework itself. Writing XML beans files for Spring is feeding the framework. If my objects are only used in one context, then I don't get any value from separating interfaces and wiring beans together in a different file. In such a case, I'd be better off just newing up the objects when I need them. So, I guess I'll go a step farther and say that the cost of feeding the framework must be more than offset by the net present value of future efficiency. Some frameworks will pass this test, some won't.

Delivering code into production is the start of the system's life. I'd also want to see what happens to the frequency of normal releases after the first one goes into production. Poor quality code tends to result in a decreasing frequency of routine releases. (Now, emergency releases, on the other hand...) Good quality code maintains a constant or increasing cadence of releases.

Answer 18

A good programmer thinks ahead of his code, forward to the execution and the cpu clicks that the extra if inside those 3 nested loops will have on run times and hard disk wear and tear.

A good programmer knows why false != $value is better than $value != false and ++$i is faster than $i++

A good programmer would never write something that will just do, it's close enough, "it takes slightly longer to run, but it would take me ages to google and implement that haversine function".... never.

Doesn't really depend on the rate of deliverables, more the quality (and so saved maintenance time).

Answer 19

Bad programmers also have code in production. It breaks. It does stupid stuff. It says one thing, but the business rules do another. It spews SQL statements. (If you are curious, I ranted about it on my blog: What not to develop).

On another occasion, I was in a shop and it added my bill up wrong. Okay, it was only out by a penny, but what other craptastic code was in there (Learn to frickin' count)