Are You Proud of Your Code? 682
An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way? If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it? I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms. Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"
Something to note about other people's opinions (Score:5, Insightful)
I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.
Re: (Score:2)
One thing to keep in mind when determining the quality of your code is that other people will most likely criticize the quality of your code. Usually saying that it sucks, when usually its just the person having their own way of doing things. I don't know why this is, I think its just human nature. I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.
In most of my experiences its not their coding that sucks its their lack of comments or poor commenting that makes their code suck.
Re:Something to note about other people's opinions (Score:5, Insightful)
The former is wrong because while it's great that we now know what each little piece of your code does, it's still a challenge to see the forest for the trees in all but the most trivial cases (it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting). A good method name doesn't tell the reader why the method is there or what its intended usage is. The latter is wrong as well, because suddenly naturally flowing code is broken up to the point where comments become a distraction and make the code harder to read (incidentally, this is why I started using justified end-of-line comments... it helps with the distraction).
You should always comment your classes (or your data structures if you're using a non-object-oriented language) -- state the reason they exist, what requirement they fulfill, their role in the application, and any caveats to using them. Comment your constants, class and instance variables if it's not bleedingly obvious from the class description what purpose they serve.
Comment your public methods! Your public methods are essentially the exposed API into your code, so if you want your successor reusing code you wrote rather than writing his own that does the exact same thing, it had better be absolutely clear how it is to be used. At a minimum, this should include what the method is there to do, a detailed description of each parameter to the function, and any constraints on the parameters, side effects of invoking the method (Does it write to any files? Set any external variables? Allocate or free any memory?), the range of values that can be returned, a description of any special return values, and any exceptions that can be raised when calling the function. Comment your private methods as well, though with your private methods you may be justified in just explaining why the method is there.
And for the love of God, don't comment your private variable accessors unless they get or set in an unusual manner. And you don't have to comment constructors that just assign parameters to instance variables.
Finally, while those agile guys are right in that your code really should have a natural flow and speak for itself, you should still comment your runtime code. Longer functions should be divided up into "paragraphs" with comments stating what's about to happen and how the current state contributes to the overall goal of the function. If your functions have extremely clean divisions of functionality, consider breaking them up into smaller private functions unless you're concerned with every last ounce of performance and can't afford the 10-20 cpu cycles necessary to do a function call (or declare the methods as inline). If you're doing something in a manner that's unorthodox or not immediately readable or that will make someone reading your code go, "what the hell?", either rewrite it (=D) or comment it to justify why you feel it was necessary to do it that way.
Automated unit tests can also be a good supplement to well-documented code, as they give natural examples of code usage and can serve as tutorials for people trying to learn your code. Often this displays intent a lot better than comments can, since doing is often more effective than saying.
I find people are more concerned with whether code is commented "enough". I think it's better to be concerned not with the amount, but the quality of comments.
Re:Something to note about other people's opinions (Score:5, Funny)
# Les gars sont agiles droite. Si le code est écrit Bien, il va parler pour lui-même.
# Il n'ya pas besoin de Double emploi avec ce que dit le code dans une autre
# langue (Anglais). C'est peu comme votre commentant Anglais paragraphes d'une
# interprétation française. À moins français est votre langue maternelle c'est
# juste aller Pour obtenir de la manière et de rendre la lecture de la même Anglais
# Plus difficile. Comme un programmeur, c'est mon travail d'être Parle couramment le
# langage de programmation de mon choix. Reading Code devrait être aussi simple que de lire un livre.
The agile guys are right. If the code is written well, it will speak for itself. There's no need to
duplicate what the code says in another language (i.e. english). It's kind of like commenting your
english paragraphs with a french interpretation. Unless french is your native tongue it's just going
to get in the way and make reading the english even more difficult. As a programmer, it's my job to
be fluent in my programming langauge of choice. Reading code should be as easy as reading a book.
# Cela dit, parfois, vous avez vraiment à écrire Quelque chose d'anormal, et, dans ce cas, vous devriez
# Commentaire. Toutefois, ces cas sont rares Entre.
That said, sometimes you really do have to write something abnormal, and in those cases you should
comment it. However, those instances are few and far between.
Re:Something to note about other people's opinions (Score:5, Insightful)
Also, humans tend to read left-to-right, top-to-bottom. Any worthwhile program is filled with loops, branches, conditionals, calls, recursion, etc. As the program size grows, it becomes very difficult to sit down with the uncommented code and just read it, and actually take away the general gist of what was just read. To do so requires several sessions of hard concentration and focus, and time to reflect on and digest how it all works together. Well-structured, well-written code can only go so far.
Comments, in many cases, make up for that lack of aptitude. It's not restating, it's clarifying what the code does so as to make it less likely for the reader to get lost and help speed up the learning curve.
Re:Something to note about other people's opinions (Score:5, Insightful)
But I'm saying that well written code does not need clarification.
Here's some well-written code:
int nIMin = m_nIMax;
int nIMax = m_nIMin;
int nJMin = m_nJMax;
int nJMax = m_nJMin;
So is it a bug? I can hear you protest now that you'd need to see it in context to know. But if I add a single short comment:
int nIMin = m_nIMax;
int nIMax = m_nIMin;
int nJMin = m_nJMax;
int nJMax = m_nJMin;
you know that my intent was to initialize max with min and min with max.
There is no way to express this in the code itself, and this kind of situation crops up all the time in well-written code of even moderate complexity. People with limited imaginations, who lack the capacity to see that their code could be read in many different ways, are generally unable to grasp this point, even when presented with multiple examples. Sad, really.
That's Not Good Code (Score:5, Interesting)
The biggest thing I see wrong with other people's code is not at the syntax level or to do with commenting. It's based on a misunderstanding of basic CS principles. An example is in order from last week...
In the codebase I work on, there's a module that analyzes documents and tags them, assigning different weights to each tag based on relevance. (Think of the way google works--it reads a web page and tags it with terms, then if you type in one of those terms while doing a search that document comes up--yes I know this isn't the way google actually works, save it. :-p ) At one point we send a list of tagged documents from one system to another, and this area was the source of many, many bugs. The responsible developer spent the better part of last week slaving on this code and every change seemed to introduce more bugs than it removed. Finally, I got involved to see what the problem was.
Here is one thing (out of many) that I found. After the docs arrive in the new system, each doc is supposed to be persisted along with the top 5 most relevant tags (the rest discarded). The code was written to create a Document, check a hash table that maps the doc to the number of tags it currently has, add a tag if that doc doesn't yet have five, then increment the value associated with that doc in the hash table. When I saw this, my head almost exploded. At some point, this developer thought it would be a good idea to create a hash table and keep this information, information which is available in the document itself (he could've just called doc.getTags().size() to see how many tags it currently had). Now he created this hash table and all his code was written to depend on it, so of course he had to write a lot of code to keep it in sync with the state of all these documents.
This sounds like a simple enough thing, right? It's not necessary, and it's not the best thing, but it's a fairly simple mistake and one that couldn't impact code readability all that much, right? Maybe--but consider that this is one of about 10 simple mistakes I found, and you can imagine the explosion of interactions of all these simple mistakes...and that's why we burned a person-week on something that should've been trivial. When I pointed out to this developer that he could just get the number of tags directly from the doc itself, and doesn't need to keep this state in some other object too, he said something to the effect of, "That's a different approach, but whatever...one's not better than the other."
But one is better. If this developer understood the difference between intrinsic and extrinsic, he never would've written that code in the first place much less defended it. To put a fine point on it: the number of tags associated with a document is intrinsic to the document itself, so that is where the information should live...not there as well as some hash table somewhere. The document is the authority and the final word on how many tags it has at any moment in time. (There's a principle in databases called the SUA Principle--it means one should keep data in a Single place, in an Unambiguous manner, and that should be the Authoritative source of that data and no other. It applies here too.) Putting this info into some other object, even if that object exists solely for the purpose of tracking that info, means you're creating an object that stores information that is extrinsic to it. Never a good idea...now you need a whole bunch of supporting code that keeps the extrinsic info in sync at all times.
Let's say I'm designing a Ball class for use in a physics application that students learning physics can use. They can shoot the ball out of a cannon, put it under water, in deep space, on Jupiter, etc, and see how the simulation behaves. As the developer of this class, I decide to add a characteristic to the ball that keeps info about its "heaviness". What should I add, a getWeight() method or a getMass() method? The developer I was talking t
Re: (Score:3, Informative)
Though I'm sure you can design a particular application in which a square is behaviorally a rectangle, and therefore it would be ok to have square extend rectangle, it is not universally the case.
One of the best things I ever did was head over to Object Mentor's published articles [objectmentor.com] page and click on the Design Principles category. There you will find a paper on the Liskov Substitution Principle which defines exactly when it is appropriate for one class to extend another. (You won't go wrong reading all th
Re:comments are important (Score:3, Informative)
I typically preface m
Re:Something to note about other people's opinions (Score:4, Insightful)
Besides making up for language deficiencies, most comments should be exactly "this looks bad, but it is the right solution because [insert reason]" or "this code sucks, but [insert reason]". Good comments aren't English translations of the code, they provide the "what I was smoking when I wrote this". Bad comments are "initialize counting variable".
I should also add that good comments should be written for everything publicly exposed. Good implementations of Intellesense will make life easy down the line by sucking up the comments (or xmldoc for visual studio projects and perldoc for perl).
Really, this entire debate is an old news. People should really RTFM [amazon.com]
Re: (Score:3, Interesting)
Since we are nitpicking, I would say that I do not use hungarian notation. It assigns variable names based on their type; I assign variable names based on their expected usage and their scope. For example the m_ prefix tells me where to find the variable, rather than what it is. I would also use type prefixes in cases where they say something important about how the variable is used. For example, "m_pDocument" is a better name
Re:Something to note about other people's opinions (Score:4, Informative)
Suppose you have an exception raised in a given class. You know the line number, and you open the class... if it's involved in serving a purpose that's low-level enough, it's going to take you a far more time to figure out what it's for, how it's used, and what role it plays in the project as a whole if you don't have, say, 3 simple lines of plain English in the header comment.
Personally I don't write too many comments in my "normal" code. I write progressively more as the code gets more complicated -- some features are simply too complex to even fit the implementation in my head all at once, so I write a shorthand walk-through of the implementation before I start. When I'm done, sometimes the code has actually boiled down enough that I can chuck that (sometimes I'm not so lucky).
You have to comment implementations that "look wrong" or are counter-intuitive, possibly because of client demands ("the last software package did it that way, so our other systems are designed to correct for it..."). What, are you naming methods calculateScaleWronglyPerClientRequest()?
It can be wise to flag methods (or classes) that will *appear* unused to refactoring analysis, because they're loaded & accessed dynamically.
I could go on.
Re:Something to note about other people's opinions (Score:4, Interesting)
duplicate what the code says in another language (i.e. english).
Some of the time, that is correct. Most of the time, it isn't. But that's just in my field (financial software). There are two languages in use in the software I write and maintain: "code", and "business". It is vital, in my area, that code is commented well, to explain the business reasons behind the code. Small loops sometimes speak for themselves and don't need commenting. For example, a method called "getAllCashSecuritiesForAccount", if it contains only a simple loop, doesn't need commenting.
But because developers come in who don't have a financial background, and don't know their way around the system, comments in the code are essential. It helps them understand both the code they are looking at, and the business flow.
But the main reason for having clear, concise comments in the code is so that you don't have to read the code. For example (apologies for the VB):
The above comments are all aligned. They appear in the IDE in a different colour. They are written in plain English. They are clear and concise. If I am looking for a bug which involves the total value which has changed being wrong, then from scanning 3 lines, written in plain English, it is fairly clear where I should start my search. Yes, given a few more seconds, I can read through the whole code, and see what is being done. But it's quicker and easier to read 3 lines of English than 15-odd lines of code, which aren't aligned.
In fact, possibly the most useful aspect of comments like the above are to eliminate all the code you don't need to read.
You could argue, of course, that the above could be broken down into 3 seperate methods, all clearly named. But I think that's overkill. This is a simple method, doing three simple things. I ought to be able to read it all the way through without having to flip between three different methods, which exist only to save the developer taking the time to type some clear comments.
Lastly: yes, I am aware that the above code performs two seperate iterations of the same objects, and is terribly inefficient; it is for illustrative purposes only, and on no account should be treated with any seriousness
Re:Something to note about other people's opinions (Score:4, Insightful)
Plus sometimes you can understand each operation in the code block but not know what it does. Have you ever looked at an MD5 implementation? You need a comment that tells you what it does in general terms even though you know what it does in specific terms.
I believe in making my code self documenting as much as reasonable, but any time I'm not simply reading data and outputting it (or reading data and inputting it), a backup comment describing the purpose both makes it easier to read and to maintain.
Re: (Score:3, Insightful)
#warning "This call fails in
I also put short comments in about each 'paragraph' block in the code and plenty of TODOs where work still needs to be done or extra features could be added.
I do also write fairly full design documentation as I go
Sorry, I have to bite about this. (Score:5, Informative)
and I've met people who won't even look at code unless every single line is commented telling them precisely what it does, so "int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a".
Why on earth would you write a comment like that? That is ridiculous. However, the line DOES need a comment. It's declaring a variable with a non-descriptive name and doing something specific with it. Now, the comment should do something like say what the variable is used for, if it's non-obvious. In this case, "int i" is usually used for loops, so it doesn't need a comment unless it's *not* used for loops.
int i = a + 2;
or
int i = a + 2;
writing comments like "initialise variable" is useless, but thinking that may be all there is shows a misunderstanding about how comments work.
You can assume the person reading your code is a programmer, familiar with the language used, and able to follow general program flow. However, he may not be familiar with the rest of the system, nor with any specific tricks you may use[1]. Comments should be like a director's commentary on the code, pointing out what may not be obvious, and giving the bigger picture - the reason why a specific variable is used a certain way, or what a messy few lines of code may be achieving, eg:
(horrible loop declaration here)
(even more horrible regex here)
(custom function calling here)
It's said comments are like sex - even when they're bad, they're still pretty good. I'm pretty sure I've never spent 3 hours trying to work out how to get THAT to work, though!
[1] eg, I use a relatively uncommon trick in Java doing string comparisons of if(!"blah".equals(myString)) because it can't fail on the null pointer check that if(!myString.equals("blah")) can. A simple example, but something more complicated will save someone time if it just has a quick comment next to it saying what that section of code is achieving.
Re: (Score:3, Insightful)
I'm griping about comments that triple the size of the source code and disrupt the code's readability, yet say nothing that can't be discerned immediately from the code.
Comments should describe "what" in only very high-level terms, which is why "what" comments are better suited to method and class level. Beyond that, they should primarily talk about "why", and to a lesser ex
Re:Sorry, I have to bite about this. (Score:5, Funny)
No, programming is like sex. Make one mistake and you end up supporting it the rest of your life.
Re:Something to note about other people's opinions (Score:4, Interesting)
I do otherwise agree with all your points; the best place is a middle ground between agile's self-documenting and the traditional ZOMG COMMENTS. At my (non-agile) workplace, we document at the top of each function what the function does and what it takes and returns, as well as documenting any complex or unintuitive block of code within a function. (The ideal would be to avoid unintuitive code entirely, of course, but this is not always possible when dealing with things like VoIP goo.)
Excuse me if I'm rambling, but... (Score:4, Interesting)
So yes, comments should say WHY more than WHAT (specifically) a line or block of code does. A short narrative is usually the most helpful, ime. Basic description of what the method (or even a crucial line if it's the least bit unconventional or otherwise unintuitive) does (in bird's-eye-view terms / how you would explain it to a non-programmer), and WHY it is doing it if that purpose isn't obvious from WHAT.
And I also say (most of) my predecessors' code sucks, but in this case, it does. There was one guy who seemed to have a decent idea of what he was doing, and I think he got burnt out by the complete buffoon of an "IT Manager" they had at the time (hurray cronyism! He still works here in his own project group because he's friends with the big boss). But the other guys...one would have actual end-user visible error messages like "the stupid polack messed up again", and had one of Shakespeare's plays in its entirety linked on one of the maintenance web sites. The other guy consistently set up SQL accounts with "password" and sysadmin privileges (I've gotten it secured now, but it's causing quite a bit of havoc for some users). Crazy and stupid, respectively. Then we have a contractor (still with us, hopefully not much longer)...who is arrogant AND stupid (with coding, anyways...quite manipulative with the non-technical people who control his paycheck). He implements concepts and technologies that he does not understand in completely useless and excessively complicated ways. He also has a big problem with turnover of his underlings, resulting in even crappier code. The rest of us want to completely scrap his project because it's so bad (the aforementioned "acid trip code"). But you know what they say: "CONTRACTING: if you aren't part of the solution, there's good money to be made in prolonging the problem."
I am lazy: I make sure it works before it goes out, and I write it so the user can configure it to do what they need without having to bother me to do hard code changes, recompile, and redeploy. I've already got enough of that with existing code I've not yet had time to rewrite.
So, in short, if you are neither crazy nor stupid, your code probably won't suck that bad. Every time I'm skeptical of my own code, I just look at the code I am maintaining and replacing. I simply remind myself: mine actually works. I wrote them from start to finish, so the code is consistent. My boss can look at it and understand what it's doing with his experience with older languages and teething knowledge of
Re: (Score:3)
I've met people of the agile variety who insist that well-written code needs no documentation: that if you carve your code up into small, tight, appropriately named classes and methods it becomes obvious what your code does and your code becomes "self-documenting", [...] it's still a challenge to see the forest for the trees [...
Re: (Score:3, Insightful)
The reason Agile people lean away from documentation by default is that documentation is by definition redundant.
And redundancy is a Bad Thing because? Yes, code duplication is undesirable. Clarification where it is needed is not. Structural engineers would tell you redundancy is a very, very Good Thing.
For an agile team coding like that, I'd expect them to be doing test-driven development, working in a team room, doing pair programming, and swapping pairs every few hours.
And scrumming twice a day? Just messing with you. You seem to be describing an XP environment... XP is known to be an unstable methodology, both in theory and practice. Heck, the flagship XP project at Daimler Chrysler floundered until the day it was decommissioned, even with the big XP cheeses at the helm. Change m
Re: (Score:3, Insightful)
That may be true, but when I think back over my programming career to date, and think about the problems I've had with code, I can assure you that "There were just too many comments!" doesn't come up all that often :-).
Re:Something to note about other people's opinions (Score:4, Insightful)
With comments, it was about 150 lines.
It was a reasonably tricky set of decoding code that did a lot of fancy things to get the data out of a packet for a specialized application. It worked quite well, with corruption of about 20% still being recoverable into the original data.
Anyway, nothing about the encoder was even remotely obvious. I wanted to make damned sure that whoever had to maintain that code had at least a reasonable clue as to what was going on without having to draw out charts and wonder why the indexes used were flipping at certain points. It wasn't comments like "this is an integer." "Now the integer increases". It was more like: "If the accumulated error goes above the threshold indicated, then we have to move back at least one step to find a different pathway. Since we know that the first pathway was not a match, then we increment the error threshold, increment the index, and *decrement* the position in the message." (I can't remember exactly, it's been a year since I wrote that, I no longer work there, and there's an NDA anyway.)
Another piece of code I wrote stripped the GPS data from a GPS module's RS-232 output. It was trivial to write the code, since it was an iterative loop. However, comments for each line made it impossible to get lost in the series of 15 nested loops and in the placement of commas and other fields. It was really handy to see at a glance exactly which lines were used to skip to any given field.
(Special thanks to the lameness filter for not letting me post it quite right!) Any coding practice has to be flexible enough to allow you to make your point. If you're not commenting because you think the code is obvious, then maybe you haven't coded real stuff, or you haven't coded really tricky stuff. Maybe I write my code with a little bit of overkill in the comments, but at least I know that years from now, anyone can take a look and know exactly what I was thinking and know how to update the code.
My code's been reviewed by an independent auditor as "better than most".
Re: (Score:3, Informative)
The most important part is not in your boss but in you - if you want to be proud of your code, you have to start by taking pride in the readability of you code. Your ambition should not be to write code that is readable, but textbook quality: it should be suitable not just as an example to others, but should itself be instructive to others. Not hat you can always do that, but you should hold it as something you _want_ not something you 'ought to'.
Yes, crunch times and asshole bosses
Re:Something to note about other people's opinions (Score:5, Insightful)
Re: (Score:3, Interesting)
I started looking up the terms being thrown around here lately for coding...'agile', 'cowboy', etc. I'd never really heard the terms much.
Do places really have all this stuff laid out for programmers? Standards? Naming conventions, development cycles? How do they find the time for that? I've never really seen ti
Re:Something to note about other people's opinions (Score:4, Interesting)
Re:Something to note about other people's opinions (Score:4, Insightful)
Doing good software design up-front saves a huge amount of time in writing and debugging. If you're doing an OO project of any significant complexity and you get your class definitions messed up, then the code implementation is going to suck, both in performance and in maintainability.
It doesn't only apply to big projects. My code is aimed at 1k or 2k FLASH targets... if you don't design it right up front, then it's not going to fit. When you're coding for something that's going to get masked into ROM, you want to be able to show that every line of code has been tested and that there are no degenerate situations. Add to that a realtime environment where you don't know when certain interrupts are going to happen in relation to each other, and proper design becomes the difference between something that works all the time, and something that is dependent on all kinds of seemingly unrelated occurrences.
Re: (Score:3, Insightful)
You have to make time for the important stuff, its not finished until all the i's are dotted and the t's are crossed as far as management is concerned. The alternative is much worse, let me describe a typical scenario for you.
Let's say you rush through and get some code that "appears" to work, you tell your boss "Good news, the code works." The next thing you know you need to have it to the customer tomorrow. Turns o
Re:Something to note about other people's opinions (Score:4, Insightful)
Moreover, single-character variables outside the scope of a loop should be banned from the face of the earth. It's all right to use them when coding, but when the coding is done, for god's sake rename then to something sane.
Re:Something to note about other people's opinions (Score:5, Funny)
Re:Something to note about other people's opinions (Score:5, Funny)
CalcCallWaitingTime StripIllegalCharacters CreateInterfaceToACD DrawCalendarOutline may well be quite a long title ( often it's easier to acronymise them before I hand the code over ) but it's amazing the number of loops you can reuse if you have enough switches.
Re:Something to note about other people's opinions (Score:5, Funny)
That way you only need to create a single do loop and allow your cx(...) sub (result passed back in the 14th argument unless the 3rd is "E" or above in which case its pushed onto the reference you passed as arg[19 + val(arg4)].
The last guy who tried to use the code was so awestruck with my genius he passed out!
Ah, kids these days... (Score:4, Funny)
I remember one piece of code that makes even that seem tame. Assembly, mind you, back in the 386 days.
Someone had calculated something as a 4 byte float, then took it as a 32-bit integer, swapped the higher and lower 16-bit words, wrote it into a memory location at the start of a function, and then actually jumped to that location. I.e., he actually executed that result. That was actually in the (uncommented) assembly source code, mind you, not some accidentally disasssembling a piece of the data segment and discovering that it makes no sense.
To this day, I have no clue what that did. Awestruck is putting it mildly.
Re: (Score:3, Interesting)
It was written in Borland C 2.0, shoved into 3.0, dragged across to Visual Studio 6, then keelhauled into 64 bit support (from 48 bit initial functionality). We re-used that codebase for every project, tweaking and modifying, forking where appropriate per product family. Management asked what it would take to make it more maintainable and myself and the one other developer still with the company said: 8 months of dedicated time for one of us, with guaranteed time for code re
Re:Something to note about other people's opinions (Score:5, Insightful)
At this point you try to justify the change to management, who will "schedule it for sometime next year", since this is not causing them any pain, only you get that priviledge. From that point on, you're stuck with someone else's bugs forever.
Now you're upset and become very vocal about the problems you now have to deal with.
There is a difference between "different" code that works, and bad code that routinely causes problems.
Usually the cracks show about a week or two after the guy leaves. And by cracks, I mean serious, client affecting shit.
Re:Something to note about other people's opinions (Score:5, Insightful)
But your code, of course, draws gasps of admiration and awe from all who look upon it.
Come on. When was the last time you had anything good to say about anybody else's code? Ever? All programmers say all other programmers are incompetent. And typically, management believes us.
Actually... (Score:5, Insightful)
Now, I've written a lot of bad code in my life, and I'd like to think a lot of good code to. I've seen beautiful code before. New attack vectors and amazing ways to approach problems I never would have though of. And each time I see those nuggets of perfection, I snag them. They get added to my pile of code samples for later use. Either in a straight copy or as a foundation of an idea that gets recoded, depending on license requirements.
Bad code is easy enough to deal with, bad design however... that will kill a project. Bad code can be hot fixed, cleaned up, or straight up replaced. But bad design will require new work from the ground up, getting the users and management to come back to the white board, verifying the requirements... If the system is not designed to meet the needs of the users, a memory leak won't be an issue because no one will ever use the software.
-Rick
Not quite true (Score:3, Insightful)
Not quite true. I can think of a few people whose code gave me no reason for complaints. To pick just two extremes out of the pool:
- one of them is pretty much the pragmatic programmer prototype. He'll (also) apply some pattern only if it's needed, not because it would be fun to have it on the resume. Sometimes a switch
Re: (Score:3, Insightful)
You know...I 'used' to get all upset about office politics...how requirements were screwed, this...that...etc.
When I finally realized that is the job is ONLY a paycheck...it is not my life, it is not even remotely a personal thing, just business and a paycheck....my life got much easier. I'll do what they want, I'll change what they want to the best of my ability, in the end, all that matters is getting a paycheck
Re: (Score:3, Interesting)
Nobody else but me takes any pleasure in good clean code, so I really shouldn't care much either. Honestly, there is very little business case for good clean code. You never see products that have "Now With 75% more clean code!" on their cover, do you? People dont pay money for that. They pay for "Now Solves 75% more Pain!". In other words, refactoring, rewriting, or optimizations are all cost centers that should be minimized.
Re:Something to note about other people's opinions (Score:5, Insightful)
In my experience, not everybody dares to work this way. It is a bit embarrassing if your boss enters your office and you're just leaning back in your chair, day after day. But on the other hand, if they wanted someone who would always seem busy, they hired the wrong person; they should have gone for a typist. Thinking is an important part of a programmer's job.
A second advice would be to keep abstractions as simple as possible. Think "What do I need and what API do I need to do that?". If you can get away with an API with only an init function and a "worker" function, then be my guest! K.I.S.S. is very important. Again, to make things as simple as possible requires a lot of thinking.
And while you are thinking it helps to have enough experience to have a "mental compiler". I can write and test code in my head so to speak. But that is something you only get after many, many years of intensive programming.
Re: (Score:3, Insightful)
It's more intuitive to find that programmers lack the TIME to just think. Courage has nothing to do with it.
The longer ANY programmer spends on the same code, the better it gets designed (if not written).
Really good programmers criticize themselves as they write and are almost never happy with a refactor.
All three statements are correct. However, I fail to see the connection between them, and I'm not really sure where you're going.
Let's just start at the beginning. Do you really think I don't have deadlines too? Yet, while the rest is panicking, I'm taking a walk through the building, or looking through the window. I refuse to start coding right away. To me, this pays off: Once I have figured out exactly how I am going to tackle the problem, I need to write less code, debug it less and once it is in the fi
Re:Something to note about other people's opinions (Score:5, Interesting)
When I look at my own code it's a mixed bag. The stuff that I earned the most money with is actually programmed quite bad, some of the most elegant stuff I wrote is sitting unused on the shelf.
I find that in a commercial setting I'm far more inclined to 'cut & paste' to keep moving rather than refactoring just to save the time. Sure, it leads to maintenance headaches down the line and I quite often just scrap stuff and rewrite it rather than figuring out what it did and why. Tools evolve at such a tremendous clip that I don't think the lifespan of code is anywhere near the point where it could be justified to spend say an extra week or two to get an algorithm tweaked to perfection if the next release of the tool or framework is going to have it built in anyway.
Faster machines also lead to sloppy code, I'm running a lot of production stuff on uncompiled PHP, whereas in the past I've rolled out code in assembler because I could beat the C compiler by a couple of cycles on most tight loops.
Times are changing, and that is the biggest 'driver' against 'clean' code, it won't be long before the actual code will start to disappear. For some environments that is already happening.
Oh well, old guys like me will find employment writing for embedded systems, which are about a decade behind the curve.
Re:Something to note about other people's opinions (Score:5, Informative)
Re:Something to note about other people's opinions (Score:4, Interesting)
It comes from learning Z80/8080 assembler first, before BASIC, before C. Until that point, I knew a few macro languages.
In my mind, I'm still in a 32K machine, living with the OS, writing strings to hardware ports, and using my own interrupt vector code in concert with the host cycles to get work done.
When I work in C or C++ (heaven forbid #), there's a link list in my mind about array conservation, minimizing strings, using hashing and strict Booleans to get a job done.
No, I'm not an embedded systems coder; I just end up thinking like one.
My comments used to go thru an assembler, and I'd look at the code and try and re-optimize it. And when my code would explode, it would explode to unrecognizable shards of crap until I learned atomization (objects) and resource re-entrance. Now when my code doesn't work, my deadman's switch monitor twigs, which backstreams messages. It makes coding highly involved, but vastly more productive because *I CAN* reuse my code.
I worry more about the OS than my own code; there's so much that's not predictable in operating systems today. They should do more work with smaller kernels and leave modularity out of the kernel. Just my 2c.
Re:Something to note about other people's opinions (Score:5, Interesting)
Here are some pet peeves of mine involving dealing with other people's code. I don't think many of these are subjective either.
Re: (Score:3, Insightful)
This is at best personal opinion, and AFAIK all the actually testing done on this shows that 1 space indentation isn't enough, which is why 2, 4 or 8 spaces are the norm. My opinion is that TABs should never be used for indentation, as none of the tools will multi line things up correctly (Ie. you need to use TABs to the start of the original line, and then space to line up). Also TA
Re: (Score:3, Funny)
Everybody does it, from companies big to hobbyists small, so therefore a university cannot possibly allow it.
Re: (Score:3, Informative)
That said, I and my coworkers use includes in headers all the time. (ONLY include a header if you need the full definitions; if it's just a FooClass pointer, forward declarations are far be
Re:Something to note about other people's opinions (Score:5, Funny)
You should realise that programming is an art. In art school what you''re referring to is called a critique. It's a good thing. From an old tome I wrote about ten years ago, Steve's School of Fine Art [mcgrew.info]:
-mcgrew
Condsidering the subject matter, every comment on this story should be modded "flamebait".
Re:Something to note about other people's opinions (Score:4, Funny)
A: 10. 1 to change the bulb, and 9 to say "no, I would have done it like this..."
For me, this is part of the "Is programming is a science or an art?" argument. You can send a person to Art College and then have them paint for 10 years, and even then they won't necessarily produce masterpieces. Sometimes we comment like that on code we've taken over, because it really is awful...
Re: (Score:3, Insightful)
I can read the code. I can figure out what it's doing. What I want to know is the reason behind, say, maintaining a counter in a file between runs in order to start over next time in the midst of a long list of
Re: (Score:3, Funny)
Same here (Score:5, Insightful)
Re: (Score:3, Insightful)
1) The bos probably already knows this is some respects, however...
1.a) Should the boss act on this knowledge, he or she will lose the customer, this is not profitable
1.b) The company could get a bad reputation of not following the customers requests, losing more potential customers
2) The customer, in the end, knows if the product is functional or not in their environment, better than you do. If
Actual Software Engineering (Score:4, Interesting)
In what other line of work does principal construction begin before the customer has defined what it is they are ordering?
A software is not a product in itself. It's not like an "apple" or an "orange", it's more like a "building" or a "vehicle". A building and a vehicle can be the solution to many different problems. A truck doesn't necessarily solve a customers problem if he's looking for a way to transport people in style from A to B.
But while I think that most people understand this, they have a very fuzzy and indistinct concept of the cost of changing the specification once construction has begun because you can't walk the customer out to the building, point at the construction and say: "To make the changes you require we will have to tear out that wall there, remove all the concrete laid here, that will require a week and scrap more than four tonnes of construction material".
This is where software engineering comes in: With a good model and by sticking to the principle that you begin with a specification from which you construct a series of test to see if the specification has been fulfilled. From the specification a design is made. The design specification is used to implement tests to see that the design has been followed. From the design the code is written and on the code the tests are run.
Now when the customer changes the specification you can look at the design and the code and see (hopefully) how substantial the changes will be and what the cost will be. Your customer will thank you for being more accurate in your estimation, for pointing out the costs (which is the only thing your customer will care about, remember that time is money and is just another type of cost).
I have so far only worked in one workplace where this model was used and it was used very successfully in my opinion. Writing all those documents surely sucked, until it came time for implementation, which was frighteningly quick and painless. The ultimate pride for the well documented, well planned, well concieved and tested code has made me utterly incapable of being satisfied with any other way of working (which is why I've switched jobs a lot).
Changing to a structured approach to working is costly, but the benifits are bountiful and will ultimately save money and time. I can almost promise that while you might lose a customer or some goodwill of a few customers in the interim, in the long run, the customers will flock to you since you are delivering on time, the functionality they asked for.
The 2 strongest defenses (Score:3, Informative)
There are two good ways to defend against shifting requirements.
First, keep in mind during design that changes will happen. They may be in 5 years or they may happen before the first line of code is written. If your design is modular and consistantly uses a decent internal API, many changes won't require a great deal of pain.
The second defense is the "change order". If you do not have a change order process in place, the customer will expect to make major revisions at the last minute without consequence
This Should Explain It (Score:2, Funny)
This post [slashdot.org] should explain it. If you think hiring practices are discriminatory for minorities, try being like me!
Cherish YOUR THUMBS!
Getting better. (Score:5, Informative)
When looking back at my first project, I feel the same. But I also think that I've learned a lot from it, and all subsequent projects were much, much better.
So, by being "not proud" of your code, you've made the first step towards improving it.
Re:Getting better. (Score:4, Informative)
More Design (Score:3, Informative)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
The continuous feedback of easily understood information as to what the design is and where you are goes a long way to keep the client from b
Re:More Design (Score:4, Insightful)
Theoretically speaking, yes. Practically speaking, no. In fact, no no no no no no no. I've found that more time in the design phase means less time in the actually-doing-stuff and fighting-about-scope-creep and why-have-we-only-1-day-for-testing-and-bug-fixes? and you-didn't-ask-for-that-yes-I-did-no-you-didn't-yes-I-did-then-show-me-where-it-is-in-the-requirements phases.
You're 100% right that better design usually allows for better code; however, when you're in the real world where your actual work is interrupted every 2 or 3 hours by "status" meetings or calls from a "project manager" or some kind of "business analyst" or whatever asking if something is done, and your clients only care about it working just then and there so they can meet THEIR client's deadline (so they can then meet THEIR clients' deadlines and so and so forth), well, then you just get the project done, knowing full well that your questionable code is screwing yourself or someone like you over in the future.
You really have no choice. Principles, aside from the deeply held moral ones, don't carry much weight, especially if you work at a larger company. Calling for standards is all good and well -- until my fat, white (sometimes pimply) butt is on the line. Then I just get it done. I'd rather I get another paycheck than piss clients off and have 10 meetings (cutting into even more of my time) talking about how to implement coding standards that will, for all intents and purposes, never actually be implemented, even after we've decided to implement them!
You have to communicate (Score:5, Insightful)
Getting good IT practices is about establishing a business professionalism in IT that is respected. This means that you have to explain to the business what "good" looks like, you have to understand the business drivers so you can put your challenges into that context and you have to talk to the business in terms it understands.
All too often IT folks bitch and moan about coding, testing, requirements, design time or whatever and how its all the fault of the business. This is victim mentality IT, the way to change it is to actually work out what "good" would be for the business and then work with them to deliver it.
This means the most important coding skill in successful IT departments is the ability to communicate.
Customers often WRONG (Score:2)
Otherwise, it would be the other way around, and THEY would be serving YOU.
AS you might guess, I hated retail.
The virtue of constraint, and other musings... (Score:5, Insightful)
I've had several jobs where I've found that although management never seems to approve of a slower process in itself, they do begin to see the values once they notice that my code tends to be less buggy than that of my peer programmers.
As for turning around bad practices... That's always hard. Culture is a tricky thing. But it helps to use analogies, lots of analogies! System grown too large with too many kludges? Compare to building a skyscraper on the foundations of a cottage. Management wants to speed up a project by senselessly adding more people? Compare to: "One woman can make one baby in nine months. Two women can make two babies in nine months, but two women can't make one baby in four and a half months..."
Be creative, be thorough, and be proud of your work. Always try to make the next iteration better, but also remember that sometime meeting the deadline is all that counts.
My two cents, I guess...
Apples/Oranges (Score:4, Insightful)
And as the first reply said, someone will always criticise your code. Decent programmers know this and still do their best.
Worse Than Failure (Score:3, Funny)
That said, I do revisit code that I'd written a few years back and think "WTF were you thinking?!"
Unreasonable expectations (Score:2)
Always be proud of your code. (Score:2)
I'd say that you should always be proud of your code and always do your best writing it. I don't mean that your code must be perfect -- nobody is perfect, but if under current time constraints, requirements and all other circumstances you can do better, then do it.
When evaluating your old code you should take circumstances into account to: may be you were in a hurry and "fast" was more important than "good" at the moment -- it's OK, it's a part of a job. Go back and refactor later. Besides, you are ma
Management (Score:3, Informative)
I know that with my own management, they're quite uninterested in quality - and entirely interested in the "schedule". They have a schedule, and want to meet it with our client (we're consultants) no matter what that does to our quality.
Of course, once the code is accepted by the client then by #definition it is good enough and changes to existing code are only possible if we can prove that the existing code is buggy.
Then there's the bizarre requirement that developers use copy/paste whenever possible. It's not as if we get paid by the line, but it seems that some of the senior architect types think that LOC matters. (no jokes please)
Add in management's desire to see as little change to things as possible, we get a very poor heurestic for Hill Climbing [wikipedia.org] as a model of our software development "practices".
Be proud of the work, not the code (Score:5, Insightful)
Re: (Score:3, Insightful)
- readable (meaningful variable names & tabulation)
- commented
- pragmatic (using enum, and all)
- basic design (classes and methods should have been designed prior to any coding (at least the biggest par of it). You feel it when you read a code.
For the rest...If a method needs 20 lines or 100...As long as I can understand it, I don't care.
TIME! (Score:4, Interesting)
From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.
But the number one thing holing me back is time. When I'm coding on the company's dollar, there's only so much time to spend in design, in writing test cases, in having someone peer review your code. And thus, there's just not enough time to spend doing things in the absolute, 100% correct way. There has to be some compromise.
I suspect that even if I had time, I would run out of mental energy first.
Lost out (Score:5, Funny)
Edsger Dijkstra
Sorry mate, there is no hope
"Have any developers here successfully lobbied... (Score:2)
I didn't need to, I work for a competent company that aren't going to compromise the quality of their product on the whims of a single customer.
I also happen to think my code's great, thankyou very much. I couldn't imagine going through life thinking my code was awful. I'd lose the will to live and find another career.
Work for engineers not software companies (Score:3, Interesting)
They understand the need for excelent documentation, rock solid requirements and that you don't get halfway in a project and change its direction (ie, "sure, the Golden Gate is halfway done, but we'd actually like it to go from Lime Point and meet up with the Bay Bridge around Treasure Island Road"). They understand that some things take half the time to do but are four times as expensive to maintain, and they prefer quality over quantity.
Least the ones I worked with
Do some open-source coding to feel clean again. (Score:5, Interesting)
The product I work on at work features all three. It can be 'interesting' to maintain sometimes. That being said, it's frequently possible to rewrite sections and management sometimes listens to the programmer types and has let us restructure things sometimes. For example, we've mostly gotten rid of the RPC stuff.
When I want to satisfy my urge to work on good, clean code, I do some open-source work. Open-source tends to have that, because nothing else tends to work for very long.
All Code Sucks... (Score:3, Interesting)
There is no Holy Grail of code.
What is good coding style to me, may be anathema to you.
Ok, there is utterly shit code (which probably accounts for a fair proportion of all code if my life experience is anything to go by), then there is 'run of the mill' code, then sometimes rare glimpses of 'great' code.
Great code for me is when you see it and understand the programmers intention, and you think: a) I would have done it that way, or more likely b) if I was smarter I would have done it that way. You learn from great code, if you're already a good coder.
I think the greatest obstacle to 'great' code is 'language fascism'. Some languages are better than others, that's true, but they way some people carry on you'd think it was only possible to write 'great' code in their language of choice. This behavior is generally exhibited by those that can code in one (or at most two) languages only.
I'm generally proud of my code and am happy for others to scrutinize it. All that means is that I spent the time to make it as good as I could withing the prevailing time/cost constraints.
I used to write a lot of assembler. Some of my colleagues used to think it was cool to use obscure instructions, in unintended ways, just to show how 'cool' they were at flipping the registers. I never subscribed to this idea and always used 2 or 3 common instructions instead of one 'neat' instruction. Performance never seemed to suffer and maintenance programmers were eternally grateful.
Code is communication (Score:5, Insightful)
By far the largest part of the lifespan of any code is Maintenance. Code has to be intelligible. Not just through commenting, but in every construct and usage.
Think about effective communication. The effort to be clear will improve what you are doing. It will also make your mistakes evident so you can correct them.
Takes a group to judge an individual (Score:5, Insightful)
I used to work for a small-sized IT business; a popular community that housed some 130,000 members. It began with the loss of a fellow employee who had basically coded 99% of everything on the site. To that date, everything had worked fine. We had some issues every now and then, but a backup system helped us from getting hammered if anything bad happened.
We never worried too much about him leaving because, for starters, I had some experience with the code/system. In addition, the now departed programmer had left a comprehensive list of features and explanations of his system that would help any programmer (that would replace him) to get around any tricky problems that would/could occur.
Unfortunately, I won't go into what type of business this was, but let's just say that it's not typical programming skills. When I began looking for his replacement, I realized how hard it was to get someone with adequate skills and all the knowhow that was required besides the actual programming. As we were on a tight budget, it was important for us to find that one guy who didn't expect a zillion dollar salary. Typically, that would be someone who shares our interests, a recent graduate who knows his ways around programming.
Eventually I found one guy who claimed to be all that we wanted. After a month, it turned out that the guy was more and more frustrated over how things worked at the company. He disliked about everything about the code and spent most of the time cursing. At this point, I started to believe that our entire code sucked.
Roughly a month later, we decided to rebuild "everything" so that he could have his ways around the code. Since we only had one programmer, I had to comply because it was an important role in the company. My limited coding skills provided no extra help in evaluating our current code, so I trusted this guy since he seemed to be very thorough and experienced. Also, I was promised it would take no longer than one month to do all this.
What a fool I was. If it ain't broken, don't fix it. I should have known, but a company on a tight budget and no one else with good programming skills forced us into this move. Turns out, our super experienced programmer needed not one month, but two, three, four, five, six and seven months to complete his task. By then, he had reprogrammed almost everything and merged some of it with the old code. We waited for the relaunch of our software with great anticipation. Three! Two! One! Go! Oh crap, everything f*cked up.
Following the launch of our new software, we had months and months of trial and error problems. Members were complaining and nothing went in the right direction. Eventually, we were essentially bankrupt and had to let the superb programmer go. The guy who had left us with a huge mess.
When I read this Slashdot story, I had a smile on my face because I learned that a programmer can only know that his code is perfect by the response of many other programmers who can view his code (i.e. open source). Some programmers seem to think their code is perfect and that occurring bugs are caused by impossible-to-foresee problems. The point of my story is that if you truly want to know if you are a good programmer, you must let a lot of programmers decide that for you. Unless your name starts with J and ends with ohn Carmack, of course.
The normal response of an inexperienced programmer (Score:5, Insightful)
All this means is they have a fixed idea of how it should be done and cannot bear to see it done any other way. Frequently (as you found to your cost) the final product is the result of trial-and-error techniques. It's very likely the original programmer thought of and tried the way it should be done, then found the flaws in this approach and adopted methods that produced the results.
It's equally likely that some of the ugly code in any implementation is to get around bugs in the development system, programs it interfaces with or even the O.S. itself. The inexperienced programmer only sees the ugliness of the end result, they assume that the original programmer was dumb/lazy/old-fashioned (because that's what they see in themselves?) and in their arrogance assume that there's nothing worth keeping and only a complete re-write will meet their high standards. If only this was Usually none of the "experience" is documented - only a description of what a module does, not why that method was chosen.
Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops.
Re:The normal response of an inexperienced program (Score:3, Insightful)
* Low-level form and factor: The code is written by somebody of much lower ability, so the code is disorganized with lots of run-on functions. You can understand the code, but modifying or maintaining it is next to impossible just as speaking with invalid grammar is very difficult if you know better (ie "somebody sent up us the bomb", or repeating verbatim pretty much anything GWB says).
* Syntax
TCO (Score:3, Informative)
Saying "no" to the customer is not normally what's called for. Instead, your team must clearly state the total cost of any proposed change. Factoring maintainable quality into cost estimates is an art that an organization must learn if it wants to get asked to do another job after the money for this one runs out (project drift leads to no results leads to unhappy customers, as you well know). When the customer responds with "Well, isn't just as simple as changing X into Y?" then that's when you get to say "no."
Yes (Score:5, Funny)
Yes, yes and yes (Score:4, Insightful)
Yes, I have convinced my employer to stop allowing cowboy coding practices -- she didn't even realize it was happening. I'm currently head of the programming division of a inhouse IT dept for a large travelagency specialized in cruises
Anyhow, I managed to convince the CEO that there was a problem
I am now trying to reform the bunch of code cowboys that currently works here to a well disciplined programming team
The codebase is still very messy at places, but many basics (use of one and only one database class e.g.) have improved very much and I think the people here are happier for it. It's much less frustrating to work on nicely formatted code that doesn't have braindead sections that aren't commented.
To make a long story short, if you're not proud of the code you write, make sure you improve it.
after 8 years of professional coding... (Score:4, Insightful)
Project deadlines, crazy customers, chief engineers, thunderstorms, even a Tsumani. It's just you.
Reason:
if you write buggy code, whatever the reason may be, it falls back to you. You will have to fix it, you will be MADE responsible for it. EVERY time. No one asks WHY you did it.
And you don't like it yourself, which is a bad thing. One should LOVE his work, not hate it.
If you force yourself to push everything else into a state that enables YOU to write good/nice/beautiful code, you will gain something. If not, you will suffer. That's about it. It has nothing to do with other people, with companies, with unemployment.
So, get up, and write that good code. Whatever it takes.
Good luck
Pride fades with time (Score:5, Interesting)
Usually, when I unearth the code 6 months later I wonder if there's any way to get this horrible piece of hacked crap out of the CVS somehow...
It's just that, well, you learn. You improve. Yes, even after more than a decade of coding, you still learn and improve. You learn new tricks, you learn to use new libraries, and you discover better and more efficient ways to use them by using them. So generally, yes, I'm proud of my code. For a while.
To be honest? (Score:3, Informative)
This might be harsh, but the solution is easy... (Score:3, Interesting)
Having problems with bad interface? Design better interfaces. Jumbled, complex code? Refactor it. Slow execution? Improve the algorithms. There's basically no project that takes longer time by doing things right, more often than not the opposite is true. A good refactor can save tons of time.
There's no magic bullet, however much support you get from superiors or coworkers. The only thing you can do is simply write better code.
Always write code... (Score:5, Funny)
Perspective and Experience (Score:4, Insightful)
Many good comments already. I'd like to add some based on my experiences since 1972.
Background: I was fortunate to be introduced to structured programming early on. I've used, and helped develop/test tools to implement, various coding methodologies (CASE, anyone?) I've worked on operating systems and compilers. Yes, plural on each of those. I've worked at huge multi-nationals and a 3-man startup.
Observations:
Lastly, here is a quotation I found back in the 80's (IIRC from someone at SofTech) and it has guided my thinking ever since:
Strive to understand your problem.
Don't try to solve it.
A fully-stated problem
embodies its solution.
Development Methodology (Score:3, Interesting)
Your deliverables (above) will be a part of your project charter. You will also include stuff like: a list of stakeholders, RISKS AND ASSUMPTIONS (such as a deadline not being met, etc.), testing, and of course "Success", which will be a list of metrics that define a successful product (ie: it can generate payroll checks, it can print report A, etc). Then, take your project charter (look it up on google) and put a bunch of lines on the bottom for you, the team and the management and the key users to sign off on. Do not start work until it gets signed off. Then make a copy for yourself and file the original with the project documentation. Work and complete all the features to be developed. At the end, take the project charter and make sure everything is fulfilled, then give it to the "customer" and have them sign off again for completion (after you demo the software).
Usually scope creep means poor project management, and as a developer you can't expect anyone else to do it. Just do it, you will be very thankful you did. Also, if it's a short project, try something called Quick-Kill [ddj.com] project management. Large projects need a better methodology. I use one I made up that's based on the quick kill and some microsoft stuff, with some unix version control stuff, and oracle business process analysis stuff... Over time you will develop your own methodology and become a star senior programmer making $300,000 a year.
Have fun
Occasionally I ... (Score:4, Interesting)
Then I go through a totally re-write the code from end-to-end. I look for unused sections, variables, etc. I re-order all the logic so that it is logical. Then I test for the necessary period of time.
Since most of the code is already written, I start by writing out the business rules and I make the order of the code follow the order of the business rules, more-or-less. I put ALL of the business rules into the code as comments. I also send the rules to the client/boss/myself/others.
Doing this just once a year, on each critical section of code actually saves me much more time than the initial investment, so everyone wins.
legacy (Score:4, Interesting)
One such system has two very different kinds of programmers. One kind produces very small, tight, elegant code. Each line may be complex, but there aren't very many of them. Another kind generally codes for conceptually easier tasks, and has a verbose style. Individual lines are trivial assignments, but there are sometimes thousands of them.
The elegant code is MUCH more difficult to debug. It's also, generally, broken much less often. The verbose code is generally very easy to fix.
But i've gotten an appreciation for other ways to do things. And, there aren't nearly as many of us 'elegant coders' out there for replacement. But i still don't see how some apps can be accomplished at all without us. This appears to be language, library and tool independent. Fred Brooks seems to have something to say about this.
I'm firmly in the realm of 'elegant coder' myself. My favorite piece of late is 750 lines of very dense code involving a seven dimensional hash (but sometimes six - it varies) with dynamic indexes. It replaces a 25,000 line chunk that had to be changed every year. The new bit never needs change. However, despite ample documentation and three tutorials, i was unsuccessful in showing the new team how it worked. The new system has designed this bit out completely.
One thing about both projects is that the employer either started a project to replace them, or actually replaced them. In both cases, it was an incredible amount of work and expense to do this. Millions of dollars. It would have been both cheaper and better to fix their problems, and update their user interfaces. At least, once an appropriate programmer was found. Oddly, we have at least two on our current team.
Oh, yes. The replacement projects went over budget and were late by at least a factor of two. Much more, if you consider that something like half of the functionality was removed. And there seems to be one chunk that the new team doesn't seem to be able to deliver. Perhaps the new team needs an elegant coder.
In 2 letters... (Score:3, Informative)
No.
Honestly, most of the time writing bad code is not faster than writing reasonably good code.
To improve even more, try having a policy of doing a quick code review before non trivial check-ins. Knowing that you'll have to show and explain your code to a peer, that does help in resisting the temptation to take some shortcuts (e.g., why save time writing when it will take longer to explain). Code reviews should be easy to "sell" to upper managers, as they provide a certain degree of mitigation for the risk of one programmer leaving.
Customer = Wrong (Score:3, Interesting)
The worst part is when the customer doesn't know what's best FOR THEM. Especially when it's your job to do what's best for them... then you have a contradiction. I work in advertising, and I run into this constantly. It's my job to help my clients sell their products/services, and they've hired me to do just that. But many times, clients think they know how to do it themselves, and then tell me what to do, when their ideas could, likely, harm their image and their sales.
What do I do? They've hired me to do my job and help them, but their very instructions will certainly harm them. My hands are tied, I just want to scream at them, "Let me do my job, and make you lots of money!"