you're so adorable.

bitrot is very real.

One month ago, I actually believed I would never deliver code that I was ashamed of...

+++

bitrot? I've always found this article amusing:

http://devblog.avdi.org/2011/08/22/y...de-is-my-hell/

There are plenty of people who produce code they will never look back on and say "boy that was stupid." They are the people who fail Fizz Buzz tests.

Great code and a great business proposition aren't exclusive. The better the codebase the easier it is to adapt/change/add features.

Wait we should actually stop production of cars to fix small issues a floor person reported? That's just not how we work here.

Lol, one size fits all, eh?

Think about an edtech company that needs to hit a deadline of the start of a school year or they miss a full year of sales. An ecommerce site that needs to be up and ready by black Friday. A sports site that needs to be ready for the start of the season. A bug that needs to be fixed for a customer so they can meet their important deadline.

Those are just obvious examples. You seriously don't realize that the same concept applies in thousands of different (some subtle) ways?

I'll also add that my above post is just one reason why its stupid to write great code all the time. One other reason is that the best you can do is write great code given what you know today. Requirements change and sometimes that feature you've been working on isn't necessary anymore and so you just throw out the code. Sometimes the nice extensible code you wrote is extensible in the completely wrong way. Or its extensible in so many ways that you never need that its actually harder to do the few simple changes you actually need to make. And so on...

While:

is true - it also misses so many points and ignores things like deadlines, finite time resources, and overall efficiency.

It's simply a balance between speed and quality. Sometimes having a new feature out tomorrow is more important than having the new feature written in a better quality way.

Having your programmer add 15 features in a month might make more business sense than having them add 3 features in 1 month. Is it misguided/bad decision making to favour speed sometimes? I don't think so

And to end my ranting:

I'm not saying you shouldn't strive for great code or that it shouldn't be your default position. I'm just pointing out that if you never write something that makes you say to yourself "Uh, that's ugly. I'll probably regret this..." you're probably erring too far on the quality side of things at the expense of a lot of other things.

Here's a paraphrase of a really nice tip from the pragmatic programmer book. It really sums up how I feel about code now.

As for this...

How about going back into a 3,500 line file from 1.5 years ago that has php/mysql/html/js all mixed in as well as in-line style tags littered everywhere and of course most of the JS events are attached directly to the elements in-line.

Then imagine stuff on that page depends on data from 3-4 other pages and you also have 8 other files in the 1-3k line range filled with the above bad coding decisions.

All of that starts from "hey, it's only 1 style tag" or "whatever, I want to improve my hourly by just finishing this and moving on". They destroy you later though. That is technical debt.

I'm with Shoe Lace here.

Sure, there are valid exceptions to every rule, but technical debt becomes expensive quickly, in a real way, sometimes immediately, and is not just some abstract future albatross.

And in fact, while I think a programmer who took an absolute hard line on the view Shoe is espousing might be making a small mistake, a programmer taking your view, jj, while in theory could be more optimal, in practice usually just uses that view as an excuse to be lazy, and would have been better off taking a hard line approach.

Great code is a means to an end. It's not an end in itself. And if you sacrifice your ends to reach your means, you're doing it wrong.

Of course, as stated, that is true. The point is that, as a matter of experience (certainly in my case, ymmv) -- it is almost always the case that when you sacrifice the means (good quality code) you will, in fact, not meet your ends. And the aphorism you are invoking, which sounds so reasonable one cannot argue against it, is in practice usually a rationale for making bad choices.

I generally agree but I also think nice code is some sort of art. It can def be and end in itself to solve some problem in a beautifull way.

And that is definitely a mindset some would call academic.

+1

To go even further, just about the only way to write code no one complains about is to write code no one ends up using. If your software is successful, it will be used and stretched well beyond its limits, which will make users and maintainers complain.

Case in point:

http://forumserver.twoplustwo.com/19...picks-1185894/

On the first page, people have picked:

Oracle, FireFox, Acrobat Reader, IE, Microsoft Word, .NET Framework, Java, IIS, DirectX, XCode, Netscape Navigator, Windows and DOS

All of which are impressive engineering feats by extremely talented programmers.

There's some truth to this, but espousing a hardline view is not an effective safeguard against laziness because you can just as well use it as an excuse for laziness. Feel some great new feature is difficult to add? Convince yourself that adding the feature would compromise code quality. The feature is a hack! There's no clean way to do this! Etc.

I think it's more often the case that we're lazy when we're complaining about the code, than we're lazy when we're writing the code others would later complain about. STFU and fix, that's what we are here to do. True WTF moments are fairly rare and I find that quality of the programmer matters more than their level of dedication to writing good code. Good programmers write good code effortlessly whereas mediocre-to-bad programmers often write worse code the harder they try, because their understanding of what makes code good is context-free. So the harder they try to meet the abstract goal of "good code" the further their mind is removed from solving the problem at hand, which results in solving imaginary problems and writing worse code. Solve actual problems, not imaginary ones.

That is completely false. Academics all around me claim developing software is science not art.

I'm also not saying that it is generally the case but the idea of writing code because it pleases you to do so is very real.

shabby,

were you the one who threatened to start a thread about how different posters' styles closely reflect their professional experience? cuz i think this last topic contains some great examples.

this is pretty much it.

jj/Neil are coming from the business end perspective

most others from the code hacker perspective

its an endless loop that i cant seem to find an answer for. but as i get more and more jaded about programming, i am tending to move towards the "code is just a means to an end" side. who the hell cares if you produce the most elegant code if you have to slave away for years doing it. id rather be outside for a walk in the park. and that can be achieved by telling another programmer to meet the deadline so we can ship the product so we can all get paid.

i am coming from both perspectives fwiw

i think this is a false dichotomy. the point is it takes much, much longer to write bad code, even if your perspective is only like 2 weeks away. if your perspective is today, then yeah sure you can save some time.

The whole argument is full of false dichotomies, or at least the argument is pointless without getting more specific. How bad is the "not perfect" code? Where is "good enough" at on the scale of crap to nerdvana?

yeah i agree

yeah perhaps its best to have the programmers strive for great code, and the managers striving for speed of release, and ideally a balance is achieved somewhere in the middle

It's best to not have managers ldo :P