|
Does good code matter?
Fate Hani gives a very interesting (and hillarious) rant on this issue. It's not so much a question as to whether good code matters, but whether all the methodologies, frameworks, and other bells and whistles that are *supposed* constitute "good code" matter: http://jroller.com/page/fate/20040309#is_good_code_relevant
I think he may go a little overboard, but I don't think he goes *that* overboard.
Crimson
Friday, March 12, 2004
The bit about jobs being so boring that people are compelled to make them interesting by inventing frameworks is spot on.
Sum Dum Gai
Friday, March 12, 2004
I am glad someone else said that, I am sure I learnt about how to write a framework to write a framework at university.
I always wanted to know how much of it was rubbish.
Aussie Chick
Friday, March 12, 2004
There are two ways of defining "good code". From the pragmatic black-box perspective of an outsider, good code possesses the desired functionality, few bugs, high performance, and allows rapid bug fixes and enhancements. In the alternative definition, a purist reads the source code and judges it be some standards of how code should be written.
In my last job, where we had intense deadlines, the end-users were quite happy with my code while other coders criticized its implementation. In my current job, where I have a more reasonable schedule and I've learned the value of refactoring, my code does fairly well by both standards.
It's best to disregard the purists who criticize your code while creating stuff that doesn't work correctly, is unmaintainable, or is way behind schedule.
Julian
Friday, March 12, 2004
Sometimes, results are the only thing that matter.
I used to manage a department and had a programmer whose primary job was to develop and maintain software for in-house electrical test systems. The programmer did a great job, and I gave the person a good annual review and raise.
My boss, not a technical guy, just didn't get it. Everything the programmer did wasn't visible, so with cash flow tight at the company the boss overrode me a lowered the raise.
The next year the programmer performed the same. But that year, the programmer wrote a small VB app that took a couple of weeks to write. The entry validation sucked, the readibility was awful, and the code just wasn't that "good". But it saved the people in one department a lot of time and fixed a major quality problem.
Come review time, cash flow was even tighter that year, but the boss managed to bump up the raise a few % points over my recommendation.
That's the difference between quality and perceived quality.
Anon
Friday, March 12, 2004
This guy Hani writes to offend, but is usually deadly accurate in his comments.
I first came across his writings when searching for people with similar (bad) experiences with Tibco software. I laughed for ages when I read the way he described the same things I'd been bitching about for months.
Now I delight in watching him skewer JBoss and the rest of the Java mythology.
HeWhoMustBeConfused
Friday, March 12, 2004
The thing with Java is you hit the wall of dinimishing returns quick. Because the language guards you from doing anything dumb... or clever.
I feel for those guys on the messageboard. I remember how boring Java was, how much I hated programming and how it was just for the money. The problem is that a programmer is out to automate things. But usually the language itself isn't seriously programmable unless you step outside the system and develop tools that take the program as data. Not all languages are like this.
I totally agree with this: "Their work is simply....too....boring. All these frameworks and web doodahs are more often than not simply the product of a hopelessly bored mind desperate to inject some sense of meaning into their daily grind." The people who write these frameworks seem to be Smalltalkers who wish Java/C# and XML weren't the "hip new tools." But at least Java was an enormously important language that ushered in other important languages like Ruby and Python.
Tayssir John Gabbour
Friday, March 12, 2004
Java officially announced: May 23, 1995
First public release of Python: 1991
First ruby release: December 1995 (development started in 1993)
If anything Java ushered in C#.
Anonymous
Friday, March 12, 2004
I mean in terms of mainstreamness. As I understand (and I could be mistaken because this was before my time), Python greatly benefitted with the influx of Java people who were fairly agnostic WRT garbage collection/refcounting, and who placed a premium on usability over bare-metal coding. I actually did hear Python predated Java.
From reading old usenet posts, it seemed that people in some nonmainstream language communities felt like they were in some dark age where programmers had enormous biases against different ideas. For example, the 2nd oldest surviving language family had dynamic typing, but only now do people stop claiming it can never scale in an engineering sense. Complementary "technologies" like Test-Driven Design that seemed to rise to popularity during Java, make people more comfortable with these ideas -- Bruce Eckel was famous for a while for declaring how TDD made Python's dynamicity preferable to Java's static typing. A number of influential authors switched; I don't know if this would've been possible had Java not made people question their beliefs, overpowered by newbies raised on Java.
Tayssir John Gabbour
Friday, March 12, 2004
It seems to me that Perl had the biggest part in driving Python's acceptance. A good number of Python programmers were formerly Perl programmers or do both. I'm in the latter camp (I get paid to write Perl, but rather use Python after learning it recently) and it seems that just about everyone who knows Python knows Perl.
Anonymous
Friday, March 12, 2004
I have to say I'm surprised that so many programmers here agree with the assertion that programming is boring. Personally, I find it to be extremely interesting. Satisfying too, in the same way as if you built something concrete. I'm a heck of a lot better at building things with my mind than with my hands, so I thank my lucky stars that I live in a time where programming for a career is an option.
WRT to the idea of writing "good code" being worthwhile, I guess for me it's always been a matter of personal pride more than anything. I like to look at what I've done and admire it. At the same time, I've always felt that good code is more maintainable and easier to debug than bad code, so that justifies the extra time it takes to construct.
ken
Friday, March 12, 2004
People who dump on frameworks are just pissed
because their framework isn't popular. Cause
their half ass hack of an attempt is surely
god's gift.
If you actually make anything you
open your self up to critcism. Doubly so if
you publish it. I wish more people had
the balls to put their self out there instead
of hiding behind an oh so easy cynicism.
son of parnas
Friday, March 12, 2004
good code only matters in the long term. most people only code in the short term
Zealot
Friday, March 12, 2004
The term 'good code' depends on context. This is a management issue.
If you have a small, well defined problem and no requirement to extend functionality and no performance issues, then you can hack together the perfect, cheap solution and walk away.
If your problem is not well defined, if your market is growing or changing, if you support 100 users now but don't know what the top end is, if your functionality is likely to drift, last for years, undergo technical earthquakes: then you need frameworks, excellent design, and long, long pen-sucking sessions.
The art is knowing where you live on that spectrum, setting that expectation and managing the people who want to build the Petronas Tower for you to keep your dog in.
So, good code matters, knowing what good code is matters more.
Woodentongue
Friday, March 12, 2004
Assuming you set these definitions as universal for good code:
* it works (i.e. minimal to no bugs)
* it is as fast as it can be (while still working right)
* it is maintainable and extensible
I would say beyond that, the rest of the definition can be set by your own shop. Your group will be the one supporting it, so you decide what syntaxt conventions to use, what approach to use, commenting style, etc. etc.
As long as your group is all on the same page, and it meets the important things listed above, who cares what anyone else thinks.
I feel a lot more pride in producing a product that has high value and quality than I do from the *skillz* it took to build it.
Clay Whipkey
Friday, March 12, 2004
I don't think as fast as possible is a requirement for good code. If the program runs fast enough to be usable then that is good code - even if it uses a suboptimal algorithm.
The other two definitions - bug free and maintainable make sense. I think a third definition is the "value add". I can write very bug free and maintainable code that doesn't add value.
In this regard I think frameworks can be good. If many people are using/working on a framework then the framework can become well-tested and robust. I for one am glad that I'll probably never parse http parameters directly off a URL string again. That is what the frameworks are for.
Likewise - the same process can backfire. Wide adoption of a framework can cause the standard to become bloated or broken in regard to simple applications. Also, many frameworks just don't add value. If it takes more lines of code to use a database query framework than it does to just write raw SQL then you might not be gaining anything.
NathanJ
Friday, March 12, 2004
When does good code and a well thought-out framework or elegant design matter? When you least expect it, that's when. I consider these things insurance for projects gone wild. There are many ways to implement specific functionality. The idea behind patterns and frameworks are to anticipate and meet change gracefully. Given a well-seasoned developer, anticipation for change can be built into your system at the function level when the requirements/design phase has helped you identify potential areas of change. Those unidentified sleeper cells of changes in mid-development or after release are the requirements that tend to cause the most significant schedule and budget headaches for solution development. In my opinion, a good solution designer knows what he or she knows, is aware of what he or she doesn't know and creates a solution taking into account the unknown. Therefore, when attempting to begin a development cycle on a project where the requirements were not allowed to be completely fleshed out (i.e.- political issues, budget, etc), make up your own requirements. Identify all the areas of the solution where there are giant question marks and make your solution a flexible framework that will cushion the inevitable changes. This type of insurance has saved me on multiple occasions and kept a leash on risky projects that had the potential to get away from me.
Roland Rodriguez
Friday, March 12, 2004
I read the rant. I wonder what the author does. I didn't see. I wonder if he has spent his time just working on his own code. I know that I've spent most of my career working on code written by other people. As a contractor I've often had to finish or fix bugs written by others. I was the first programmer hired full-time by a couple of guys who heretofore had outsourced all their work (about 200 websites) to DIFFERENT programmers. I was first programmer at an ad agency that had outsourced. I was then taken on to work on a CMS that everyone in the company HATED to work on. I will tell you this, good code does matter if things change. Anybody who says otherwise is showing their inexperience. BTW, I find coding to be good work, not boring at all. If I encounter something that is boring I write a script to do it. What is bothersome is working on BAD CODE, not a question of boring. Now that I think about it I've told a customer that I simply will not work on his code base bacause it is so awful.
Me
Friday, March 12, 2004
"I don't think as fast as possible is a requirement for good code. If the program runs fast enough to be usable then that is good code - even if it uses a suboptimal algorithm."
Interesting. The majority of software project reworks or outright failures come about because of performance issues. It's always fascinating that grand visions of frameworks beats out performance so frequently, when in real world use performance is often the critical factor.
.
Friday, March 12, 2004
By "usable" I think it was meant "as fast as necessary so performance isn't a problem, even though it could still be faster."
NoName
Friday, March 12, 2004
Yes, the issue of performance can actually make an interesting impact. Maybe at first, if a programmer is used to a style that is inefficient as far as performance, it takes time to learn and/or write the more efficient code (and maybe not). This might end up costing some in the development stage. BUT... if you produce a product that has demands an unnecessarily higher overhead in system requirements, you either turn the potential customer off (I don't want to upgrade my memory just to run this software) or pass additional cost onto your customer (I have to pay an extra $50 for more memory so I can run this software).
I would think it would be worthwhile in the majority of cases to spend the extra development time writing the fastest code for the functionality you are delivering. A faster product will not only be easier to sell, but it will bolster the reputation of the dev. co.
On the subject of "value-add", I would think value is really more of an attribute of good design, not good code. If you are deciding on the value of a feature in the coding stage, you probably have bigger problems than defining good code.
Clay Whipkey
Friday, March 12, 2004
It's all a bunch of rubbish.
chris
Friday, March 12, 2004
here is a nice comment on this piece
http://fishbowl.pastiche.org/2004/03/11/frameworks_good_code_and_the_opposite_of_yagni
eddy
Friday, March 12, 2004
There's an important point that he hasn't made. A lot of developers care more about what the project is adding to their resumes than about its overall success.
Egor Shipovalov
Saturday, March 13, 2004
Writing code that is "fast as possible" is not a way to produce quality. Inlined subroutines, hand optimized reverse increment loops, multi-threaded routines, pooled connections, and pre-computed magic numbers all make your code run "faster". But each of those techniques bring your program further down the slippery slope of unmaintainability.
In the real world you seldom have enough time to optimize everything. And you can spend a great deal of time optimizing any program of significant complexity.
Let's say my program consists on 10 routines that each take about 10 ns to run. Should I make each routine run as fast as possible by optimizing to 5 ns? Maybe each of the routines is called only once, except for one routine which is a loop that gets called about 1000 times. So my total execution time before optimization is 1090 ns. If I only optimze the single loop I reduce execution time to 590 ns. Optimizing the other routines reduces that to 545 ns and I'm barely saving any more time.
Also, if this program runs once per night as a cron job then I think I'm wasting development time just to shave 500ns off the processing time.
Making your code faster than "fast enough" might be a fun exercise, but I still disagree that it makes for good code.
NathanJ
Saturday, March 13, 2004
 Recent Topics
Fog Creek Home
| 
