11–20 of 54 posts
"One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
"Deleted code is debugged code." — Jeff Sickel
And probably my favorite (because this doesn't apply only to lines of code):
"The cheapest, fastest, and most reliable components are those that aren't there." -- Gordon Bell
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
There is also sometimes a trade off between saving time for the programmer and saving time for others. For example a manager might want a feature that saves them 10 minutes of time once a month when they want to produce a particular report but may cost programmers several hours a month just keeping this feature up to date. In this case it comes down to who's time is more valuable.
The best way to explain this to people is in terms of "tax" (since everyone hates that). I was once asked by a management type "I used to get all my changes turned around same day, now I seem to wait weeks or even months. What's going on?"
Of course the simple answer to this question is that a year ago the program was about 10Kloc , now it's more like 200Kloc. It's also much more "mission critical" than it was. A year ago the program was small enough that I could easily imagine all the consequences of making a change in my brain so I could do basic testing and push to production, now a small change can have many consequences so it has to be thoroughly tested first.
So the analogy to make would be the government building infrastructure for say the road network. The upfront cost of building is $x , but when doing that you commit to $y spending per year (in terms of cost+time) to keeping that going.
Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing.
It's also partly a political issue, I've spent months adding features to codebases that I know for a fact are not required because somebody with enough influence simply insists that it will be important. There is only a certain level of argument you can get into before you get to "do as you are told", that level will of course depend on many non-technical factors.
Another interesting point is that I find sometimes people will request feature X because they are perusing a line of though that will eventually lead them to conclude that they actually need feature Y. In many cases feature Y may be easier to implement (or maintain) than feature X but they simply haven't reasoned that far ahead yet so will insist that they want feature X now but acknowledge that they may change to feature Y a few months down the line.
Any day that has a negative LOC count is a good day :) This usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is now boilerplate. If I can also add a feature with a negative net LOC count, it is a gold-star day :) That being said, sometimes just dumping a pile of code that passes tests, but is large (bloated), unwieldy and redundant is the right move. It give me somethin…
The main problem of this strategy is with other people - as soon as you have a whole team pounding away at the same piece of code, the incremental changes obscure a high-level revised view of the problem, being distributed across several minds. Descent into a ball of mud becomes the status quo.
On the other hand, optimizing the source text prematurely(either via code golf or Big Architecture) is even worse since it's not even built on a stable foundation of intention, then, but on guesses or convenient hacks.
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code because their idea of re-use is copy-pasting the same bit of code they found online into every place they think it will fit and changing it around in various ways in different places so it becomes very hard to abstract later. They also like to stick with the same set of now deprecated APIs they learned 10+ year…
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard.
"Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing."
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
In fact, I can only feel sorry for any business which depends fundamentally on software and doesn't have a developer as the main stakeholder.
Any day that has a negative LOC count is a good day :) This usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is now boilerplate. If I can also add a feature with a negative net LOC count, it is a gold-star day :) That being said, sometimes just dumping a pile of code that passes tests, but is large (bloated), unwieldy and redundant is the right move. It give me somethin…
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
Code you never write never breaks. It has astonished me how much code people can crank out. It does not astonish me that they spend most of their time maintaining things they've written.
... but doesn't do anything either. :P
I find as a general rule, the more that my application tries to abstract and protect the user from the "technical" nature of the platform the more code I have to write. For example I produced a CMS that was intended to be used by content writers who were not technical. However as the complexity of the website increased (more dynamic content on pages etc) I had to write a lot of code because there were a lot of except…
Part of the zen of Python is "Flat is better than nested". Until recently, I always thought of this at a code block/function level. Recently I realized that this is also important when modularizing and adding layers of abstraction. The more layers of abstraction (from foo.bar.baz import Baz) you add, the more code you write and have to "keep in your mind". This presentation by Jack Diederich at PyCon 2012 really open…
Earlier quoted context omitted.
I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code because their idea of re-use is copy-pasting the same bit of code they found online into every place they think it will fit and changing it around in various ways in different places so it becomes very hard to abstract later. They also like to stick with the same set of now deprecated APIs they learned 10+ year…
"I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code (...)" No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. "Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly…
I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too.
If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all. If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run.
After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers.
I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers.
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing.
It's an interesting point about automation and how much stake a developer should have in a business. Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere.
Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made?
This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
Way too many people think programming is the end. If I could build awesome stuff without having to write code, I would. Unfortunately, I still have to write code today. That's why my current project is about writing lots of code now, so others don't have to write code later :) As the article points out, that's where current tools are heading. Hopefully in the future we'll have better abstraction so everyone needs to code less to get more done.