Write Less Code
mikegrouchy.com
mikegrouchy.com
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 something to refactor and abstract, and gets things done.
It's all about balance.
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.
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.
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.
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"?
If I could build great software without writing code I would. Unfortunately we're not there yet. As you said it yourself, most businesses now depend fundamentally on software. So being inside and working to make your code base as good and maintainable as possible, and understand those processes is important. So we do care about writing good software. But not because we love writing code, but because we hate that.
In fact this is probably a big motivator in the number of open source libraries available now, they were developed by somebody who wanted to achieve thing X but they needed to create byproduct Y in order to do that.
So it makes sense to share by byproduct Y with the people who need to make thing Z.
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.
I have not seen a programmer who hated programming and wrote good code.
I don't think the assertion that raw, passionate emotion (ie. hate) drives a good developer is an ideal, or a correct one.
To be a good programmer, among other things, you need to love good code, and hate bad code.
Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.
"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
Just to clarify. I think what he means by that statement is that, we assume that components not yet built would be cheaper, faster and more reliable than they would be in reality. Which is almost always true.
[EDIT: Just realized, it's true the other way around too, if you eliminate the need for a component, it becomes the cheapest, fastest and most reliable component.]
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 exceptional cases "I want this side bar to appear on all of these types of pages apart from these 3 because of condition X and this other one because of condition Y". This means that my code ends up being an enormous pile of if statements with a huge number of database flags at the backend and checkboxes on the front end.
In the end it proved more effort efficient to produce a simple tag language for the front end and expose that to the designers and content writers, this took a lot of complexity out of the back end which could then concentrate on providing the primitives for the tag language.
You do move some complexity to the front end here for sure, but people are often better at specifying what it is they mean if they can actually generate and tweak it to some extent themselves and show the result rather than trying to explain everything in an email.
Another great example of this is Unix command line utilities , the basic interface for many of these has remained relatively unchanged since the 80s whereas GUI applications seem to be continuously redesigned.
This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when reading at a later date. It has become tiresome and now I consciously start at the other end, making the simplest thing that could work. Layers of abstraction then come naturally as needed.
At that point you can introduce bugs because somebody modifies the old code in a way which would not be allowed under the new abstraction and then the new code ends up reading data produced by the old code leading to a cascade of failure.
The phrase you're looking for is "Conservation of complexity" :)
... but doesn't do anything either. :P
All code needs to be taken into account holistically. Sure, you added some code that sends alerts. It actually does something. Well, do your customers care? Are they willing to upgrade to the latest version? Does that piece of code actually change the business strategy, market penetration, or mindshare? 90% of the time code is checking boxes against competitors or providing some benefit that does not have a huge impact to the bottom line of the business. Again, MOST code.
So I make assumptions based directly of years of experience. Most of the code anyone writes barely does anything. The amount of code that is written compared to the amount of code that actually makes meaningful changes to the business or the world at large is probably 50:1.
If I had any thought in mind besides just to be a contrarian it was, to quote Voltaire, "A witty saying proves nothing.".
I've been around the block a bit too and I know that these articles on HN and the one-line summations of "write more code", "write less code", "write purple code", "Code you don't write doesn't have bugs", etc. don't really mean anything more than my stupid "... but doesn't do anything either. :P".
It's like throwing people random tools out of a toolbox. "When you do carpentry, use a chisel", "For building houses, a hammer is what you need", etc.
If the carpenters you're throwing a chisel to don't know how to properly use a chisel, then just throwing one at them isn't helpful. If they already know how to use a chisel, then you're not helping them either.
Maybe you were just trying to give them a clever-sounding quote with an obvious rejoinder to throw out on HN and thus promote a little discussion? In that case, I guess it worked well enough. :)
I agree with the advice doled out by the author about spending more time on thinking than actual programming. This is something most good developers eventually learn as they get more experienced. To immediately dive in and implement as you find issues would cost you more time in the longer run.
Also, putting it on paper always helps. Especially when you're dealing with large software or changes to complex algorithms. It helps to visualize it on a more permanent medium than the brains fickle whiteboard.
Ultimately, unless you work on the software like you have a stake in it, you wouldn't spend enough mind on it to do the continuous re-factoring and improvements it takes to make great software. This is especially true in a commercial environment where deadlines and releases and user visible improvements are the focus of the management. It is upto you to care about what happens under the hood and eventually you will wish you had.
"The problem is largely philosophical: as software developers we're trained to think in terms of rigid systems of objects, design patterns and re-usable code. You might set out with the great idea to build a system of classes with clearly defined interfaces that inherit from one another when specialized behavior is needed. You might model all this in Lua using any number of class and inheritance patterns to try and enforce your vision. But, if you're perceptive, you'll soon start to suspect that all of the work you're doing to build an architecture really doesn't add much practical value. You may find yourself in the situation of having spent a lot of time defining a traditional OOP-style inheritance hierarchy and a big pile of fancy data structures only to realize you've created nothing more than an especially convoluted way of initializing tables.
Fortunately, there's an easy solution: don't do it. "
From : http://getmoai.com/wiki/index.php?title=Structuring_Your_Moa...
(I got this from akkartik but can't remember where.)
I think that quote, or something like it, is from the 80's.
I've found this is the hardest thing for non tech business partners to understand, because most of the time, it appears as if you are doing nothing.
The more experienced I get the more I come to view big code as an anti-pattern / code smell.
code == ui
maybe this is all about the zen of coding.
Arranging, configuring and connecting components/widgets with GUIs is a very powerful way to solve all sorts of problems in many application domains. Unfortunately, the more powerful a system like that is, the less attractive it is for 'software developers' because it means they mostly aren't writing code, but rather are dragging around widgets.
I'm building a system like that anyway, for my own personal sanity. It is definitely a tool for advanced software developers to create, publish and configure widgets, not just for users or designers, although its also specifically for users and designers as well. I expect that most software developers will not appreciate it because it will make it too easy to build powerful applications without writing code.
The biggest thing holding back software engineering right now is source code.
The problem is that the definition of programming and software development is outdated. Programmers write colorful ASCII codes.
A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?