Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am working on a fairly large and buggy application - and due to the way it's written (I'll spare you details, but it violates rules in most areas you can think of), it is next to impossible developing it without major refactoring.

Significant part of the app was authored by interns, n00bs etc.; but there has also been a programmer in the rank of Master Developer, and with all humility, the code he left behind is dubious as well, in a different way perhaps but still.

Granted, his code tends to get the job done - most of the time - but it's typically cryptic, reinventing the wheel (eg. a big custom method accomplishing a rather ordinary SQL db backup) etc. Basically, needless confusion plus lots of overengineering

And it got me thinking that being a highly skilled coder (I deliberately don't use the word "developer", assuming that it indicates a wider set of skills), if not accompanied by other qualities, can actually be sort of poisonous.

Assuming that it's true, some of the reasons I could think of are:

  • if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.
  • if one is experienced enough to easily maintain a mental image of a complex program, one is less inclined to split it into modules, layers etc.

So my point is that if a fluent coder happens to be a bad developer, their fluency not only doesn't compensate for the latter, but it actually does even more harm instead.

What do you think of that? Is it true (to what extent if so)?

share|improve this question
24  
"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." --Abraham Lincoln "Sharpen your ax on your own time." -- Most Bosses –  JeffO Jul 28 '11 at 12:34
15  
Some confusion here for me caused by the title, as when I read 'fluent' I.ThinkOf(this).KindOfThing() –  Benjol Jul 28 '11 at 12:55
    
Have you asked this senior developer the reason he did these things? As you already indicated the application is buggy. So perhaps the senior developer was limited in what he was able to do with said buggy application himself. If his code only works "most of the time" then it contains bugs and should be replace and/or fixed. –  Ramhound Jul 28 '11 at 13:26
    
@Ramhound - no, as he'd left the company before I joined. He was the last person to work on it before I took it up. I know from coworkers that he used to be in rush, as fixing the app was a priority due to many customer complaints. But he wasn't doing a very good job in terms of time management, as he clearly was ramming through an open door every now and then. BTW he created his own library for localizing WPF and Winforms applications. –  Konrad Morawski Jul 28 '11 at 14:08
1  
highly related: this and this. Some (a lot of) people get stuck at this stage... –  BlueRaja - Danny Pflughoeft Jul 28 '11 at 16:24

7 Answers 7

up vote 22 down vote accepted

if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

Yes. I've been that guy. And I've learned that it's a terrible thing.

It's all very well for you, you don't have to learn something new.

But what about the rest of your team? They become very reliant on you. They cannot google for "Clive's Quicky ORM" to get help on the object-relational mapper you've written.

And then comes the day they need to hire someone new and they can't look for people with experience in Clive's Quicky ORM.

And finally comes the day when you leave and somebody notices a bug in your ORM. And it will be there, because you don't have a whole community of people testing and fixing your product.

Yes, learning Hibernate might have taken more time than writing something lightweight. But the benefit of doing so is far too great to ignore, IMHO.

share|improve this answer
1  
I've been that guy too - and I disagree with the second sentence. Being able to solve most problems doesn't mean that your solutions are robust, maintainable, flexible, scalable... or even that the initial implementation is developed that quickly. A lot of the best ideas you learn outside of language/library reference manuals are things that are "why didn't I think of that?" simple, and also flexible, scalable, etc. One of the worst things - realising that I was exposed to an idea earlier, yet dismissed it as a pointless academic absurdity with no practical use, so when I needed it... –  Steve314 Jul 29 '11 at 3:10
6  
In some organizations, getting approval to use a 3rd-party library can take six months or more. In some cases, you may wait the six months and get denied at the end, anyway. I've built one-off ORM before just because I didn't want to waste time dealing with the bureaucracy when I was already on a short timeline. –  Toby Jul 29 '11 at 12:37
2  
@Toby: Fair point. But those companies are generally beyond saving anyway. –  pdr Jul 29 '11 at 13:42
    
Not to mention US Air Force is the same as those companies @Toby mentioned. We tried to push Ruby on Rails through, but they didn't like it. –  Travis Pessetto May 14 '13 at 16:01
    
@Toby there are a few cases where reinventing the wheel is the correct thing to do, the key is to make sure you understand why you are –  jk. May 14 '13 at 16:16

•if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

Skilled in the language but not the tools. That's not really even being a strong coder. It is just polishing one skill (language knowledge) and allowing another to get rusty (library knowledge). The other way around is just as bad, but easier to spot.

•if one is experienced enough to easily maintain a mental image of a complex program, one is less inclined to split it into modules, layers etc.

That's just laziness disguised as a skill. It doesn't take much effort to keep what you're actively working on in your head. It does take skill to find the proper seams and split the code along them. Coders who say it was faster or better to leave everything in one spot often can't see which items to split out.

share|improve this answer
    
Yes indeed. And I suppose I'd be more opposed to folk of this kind if I hadn't earned a good living over the years coming in to clean up after them... ;-) –  Mike Woodhouse Jul 28 '11 at 15:56

Just make sure this isn't because he's been working in a "If your keyboard isn't clicking, you're not working" environment. We all look back on code and wonder what were we thinking. Also, is this shop in the practice of refactoring their code? That may have been a luxury he wasn't given.

However, we do need to break away from our first idea (the one you can just sit down and hammer out) and do a little more planning, research, thinking. The temptation to get each little problem out of the way is tempting and the whole project is littered with this practice. Nobody wants to pay people to fix things that "ain't broke", so why refactor.

Edit: Let's make sure we don't punish those who do happen to know the answers. There are those who are fluent and write good code with speed. The key is not to approach every problem this way.

share|improve this answer
    
Exactly my thought. If the company's main focus is to deliver as fast as possible, then people often work late hours and do stuff they would not do if they were allowed to work without pressure. You feel more "productive" and useful if you type lots of code that you think about while typing. Leaning back to think, or even to have a chat with colleagues about a problem problem ... that sort of stuff easily makes you feel like you are delaying the project. You could be coding in that time, right? ;-). –  deadsven Jul 28 '11 at 14:02
    
I've been lucky. I was allowed to work from home after relocating. Everyone wants to know if it's done and not am I working. I'm not going to be punished for knowing the answer. –  JeffO Jul 29 '11 at 2:32

100%.

The cynical way of looking at this would be that these kinds of coders are actually keeping the majority of developers in work, fixing bugs which are so fundamental that you can sink thousands of developer hours into it without getting halfway to a stable, flexible, secure, modular or [your favorite software property] system. These systems have so many idiosyncrasies that the very thought of migrating to something else, even with 95% of the features already in place and a vibrant community behind it, is considered somewhere between ridiculous and grounds for being fired.

In short, fluent coders can do more damage than a horde of competitors, but the price is usually paid over many years. And they were usually simply doing their job (as defined by someone else).

How to tell if you're a developer or a coder? I guess that's impossible, but every time you find a way to make your code simpler without reducing quality you've taken another step towards enlightenment.

share|improve this answer
    
+1 for simpler/enlightenment –  Toby Jul 29 '11 at 12:39

The problem you described was basically NIH ("not invented here") - are there other symptoms?

Sometimes NIH, particularly if it's isolated to one or two people, can be dealt with in a group discussion ("Joe here has some experience in doing SQL backups using standard libraries - what do you think, Joe?"). This could be less confrontational than you just directly going to the person and saying "Hey! Use the standard library, dummy!" :)

share|improve this answer

Having been both in your situation and having caused similar situations I understand your frustration, but I think the answer to your question is a flat "no". Fluency doesn't guarantee that a programmer is going to produce maintainable code. Often organizations force programmers to deliver poorly designed and implemented software due to ridiculous budget and time constraints. It's possible that the fluent programmer is cutting corners only programmers care about to deliver something that customers do care about. Obviously this isn't good in practice, but sadly a reality most every programmer has to deal with at some point in their career. There is also the chance that fluent programmer is just being lazy or complacent. I can speak perfect English, but it's easier and more fun to use slang.

As for the using other's code or rolling your own argument, I think it really comes down to what gets the job done best. Sometimes "best" doesn't account for things like style and maintainability if "best" means deliver a six week project in two weeks. This is why we refactor and refine. Also, the developer has to be aware of what's available in terms of third-party code and they have to know how to use it and trust that it will work and be properly supported/maintained. Given that there are thousands of optional frameworks, libraries, and APIs for any popular development paradigm using such things can end up costing more time, energy, and stress than just rolling your own. Also, I do find cases where third-party code just doesn't do exactly what I need it to do - which is when it's highly beneficial to be fluent.

share|improve this answer

I'm in that boat (legacy fluently written code) and was of the fluent type myself for a while.

The biggest hurdle to "quick and dirty" solutions is always when you need to add more to it later on. When you need more features. There's only so much you can do without structure. After that, it breaks, and it's costly to rearrange it (yet satisfying, but not really appreciated).

Basically, you have to guard yourself against ANY HACK which could potentially become a "workable solution", ready to be sold by an eager salesperson. It's the old "It's not ready! - But it works, no?" conundrum.

share|improve this answer
    
how does this answer the question asked? –  gnat May 14 '13 at 15:47
    
@gnat The question being "What do you think of that?", my answer was what I thought. I'm still of the same opinion: fluency (thus being able to do quick solutions, hacks, etc) can lead to harmful code in the long run. You can't just be fluent in a language, you have to know how to organize code. –  MPelletier May 14 '13 at 16:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.