Are You Proud of Your Code?

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?"

Comments

Something to note about other people's opinions

[suso]

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.

Re:Something to note about other people's opinions

[JustinKSU]

Codes is an expression of the programmer's though process. Everyone thinks in a different way. Invariably the last person's code will seem to suck because you have to think differently to understand it. Patterns were developed to create a common ground where people can think about problems in a similar way. Regardless of how pointless and off track a project might be you still should be able to design reusable concise code if you follow the right kind of patterns.

Re:Something to note about other people's opinions

[Chatsubo]

A lot of the time you find that, while someone is still employed, they do a good job of hiding their mistakes and covering up. It's when they leave that things start to go downhill because now suddenly, someone has to go read and understand their code. Then you realise it's a patchwork of quick fixes and bad design, and decide nice clean rewrite is in order.

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

[computational super]

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.

Re:Something to note about other people's opinions

[SavedLinuXgeeK]

Thats nice if you are an artist, but most people's code is paid for by XYZ company. Many of these companies have coding standards, most languages used have coding standards, and there are so many proven and accepted design patterns. This is to say that personal flair to coding style is fine, but if you are avoiding conventions, defying standard design patterns, and doing whatever the heck you want, then that is unacceptable.

I know its stated that design patterns should be followed in the parent's post, but that coupled with standard conventions should keep other people's code form 'sucking' because you shouldn't have to think differently to understand it.

--my $.02

Re:Something to note about other people's opinions

[goatbits]

It has to do with ego. Most programmers have this huge ego thinking that they are the smartest programmer around. It is rare to find a programmer that believes there code could be improved. They also believe that there way is the best way.

A solution to this is to apply simple checks to the code.
1. Does it function?
2. Is it readable?
3. Does it obey functional rules. IE (It does NOT over write memory or what not).

It the code passes these simple rules the code is fine, leave it alone, it does NOT suck.

This does not mean it could not be improved in some way. Open discussions in code reviews could enlighten every one. (Please leave your ego at the door).

Re:Something to note about other people's opinions

[Tesen]

One has to ask also, is it the code that breaks or is it the underlaying system the code is written around? I left my last job in a hurry (was about to kill my boss... seriously, that bi-polar bitch just generally pissed me the hell off to the point I was about ready to come in with a tactical nuke... no really kaboom ya bitch!).

Anyhoo, the systems I was tying together were old mainframe systems with SAP and then my own SQL backend. So you'd get data that you had to match between legacy and SAP, then of course the code would not "break" but you'd need to add some logic to massage the data. Of course, I left and suddenly the data issues were caused because I could not code, it had nothing to do with an ever changing difference between a legacy system built 25 years ago and an SAP implementation that still does not work right.

My basic response to one critic I saw after I left was: "How come they got the data when I was there and now they can't get it because I am not?" Those that can do, do... those that can't just bitch and moan.

I got stuck supporting a very old delphi application in another job, it pulled in flat files from another system daily, often these files would not show up due to batch jobs failing. I had MQSeries setup to pull in the same legacy data this app needed for some other systems. The first thing I did was to populate the delphi application (I was not given the time to convert it to a full SQL backend/rewrite it :P) paradox tables from a SQL DTS package. My team members said the previous coder "sucked" because of the flatfile populating, they were in error - he did not suck! That mechanism for data updates was the ONLY method available to him in 1997. People judge way to quickly, I think it is a matter of ego stroking to make them feel better about themselves.

Tes

Re:Something to note about other people's opinions

[Mr2cents]

I think part of the problem is that programmers lack the courage to just think. I recently had a programming problem that I thought two weeks about. That's go to work, think, write down some key ideas, pitfalls, things to do etc. on a piece of paper and go home. After these two weeks I had three A4 papers with some text scribbled on it. Then I spent one week coding, and when I finally tested it it worked from the second time (one small bug found).

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:Something to note about other people's opinions

[SilentBob0727]

Over-commented code (the kind where there's 2-3 lines of comments for every one line of code -- not every closing brace needs a reminder that we're exiting a code block, thanks!) is pretty awful too. 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", 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".

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

[oliverthered]

hmm.. I tend more to the Agile way typically my comments look like: // Add a beginning and end of line match (this may be a bad thing? still needs to be thought about/worked out properly)
#warning "This call fails in .net 1.1 because of a bug in .net 1.1, the easiest way around it is to use .net 2"
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 along with every problem I come across and the possible and chosen solutions.

I find that a lot more helpful then any comments in the code as it gives me the big picture and tells me why things were done and other ways that they could have been done.

I can also usually drop any project and pick it up again months later and quickly and easily pick up where I left off.

If you really want to find out what side effects a function has or how everything hangs together there are tools to do that (or they can easily be written) and they will be more accurate and less misleading than any comments someone can write.

Re:Something to note about other people's opinions

[coaxial]

Right-o. Too many people don't comment their code at all. I've spent a day before just commenting other people's code, just so that I could begin to know where the bug was. Don't make me figure out what your for-loop is doing. Just tell me. You want your code to be as clear as possible, and comments make the complex clear, and the obvious more obvious -- which is good, because it's obvious that what is obvious to one is not always obvious to another. ;)

Re:Something to note about other people's opinions

[SilentBob0727]

This is a false analogy. Human language is symmetric in that it is designed to be produced and consumed by a human. Programming languages, on the other hand, are asymmetric in that regard. As such, reading a computer program requires a certain amount of aptitude that's better suited to a computer -- for example, tracking the entire program state at any given time. Granted, you only have to track the state that's relevant to the current context, but recursively switching contexts (see function call, go look up function, finish reading function, go back to function call, keep reading previous function) is something a computer does well and a human doesn't do well.

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

[Nevyn]

Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.

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 TABs and spaces mixed are the spawn of satan, and given that we can't get rid of spaces getting rid of TABs is the only sane option.

Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).

What people call C is really two languages, and the pre-processor doesn't understand enums so that's a major reason to use macros instead. This is esp. useful when you are defining an interface and need to expand it (Ie. #ifdef FOO /* code for older interface where FOO doesn't exist */). You can mostly get around this by using enums and then defining macros of the same name to the enums, but that doesn't always work ... or you can just not use enums because noone else does either.

Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

While that's a nice goal, it's really really hard to do well. Making a shared library that does X is at least 10x harder than just doing X IMO. ... making it work well can be even harder. And the maintenance burden is probably closer to 100x harder, unless you take the retarded route like OpenSSL and cause everyone using your API massive pain.

Re:Something to note about other people's opinions

[TigerNut]

When software or firmware is a major component of your commercial output, then it is important enough that it should get as much up-front design, in-process review and documentation as your hardware.

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:Something to note about other people's opinions

[Anonymous Coward]

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; // initialize to opposite ends of range
                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.

Re:Something to note about other people's opinions

[Brad Eleven]

My experience in inheriting others' code is that I've found the "why" to be missing. I've seen a wide range of comments, from 10K lines of C with exactly two comments ("this part is tricky" and "just in case") to a current project with 25K lines of KSH with a comment-to-code ratio approaching 3-to-1.

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 filenames. It's obvious that the entire list doesn't need to be reprocessed every time, but why stop without processing all of them?

Ideally, the code itself would contain such rationale as an adjunct to documentation describing how the modules, scripts, etc. all fit together to accomplish some goal. That's what I strive to leave behind--either for someone else, or for myself when/if I encounter my code again years later. I've done this about a dozen times so far, and I usually laugh at what I was thinking "back then." Even so, it's readily apparent what I was trying to accomplish, so that I can either tune it up, fix it, or adapt it to a situation that has changed.

The most hilarious code I've ever worked on was hand-optimised C, replete with explanations about why the arrayname + offset notation was so much faster than the arrayname[offset] notation. The fellow seemed to have been so proud of himself for that style that he forgot to check the logic. Most, if not all of the comments came across as bragging about how good the code was, sprinkled liberally with the repeated declaration, "CODE IS MORE EFFICIENT!!!"

The only other comments I really appreciate are those that explain something that might look weird to someone else. I don't mind extra comments so much; they can be grepped out like so much beer foam.

Re:Something to note about other people's opinions

[Tim Browse]

Over-commented code (the kind where there's 2-3 lines of comments for every one line of code -- not every closing brace needs a reminder that we're exiting a code block, thanks!) is pretty awful too.

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

[coryking]

I would challenge [the staunch agile supporter] to come up with a "well-written" alternative And your code comments will tell them that you tried to create a well written alternative but it didn't pan out because [insert comment here].

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 :-)

Re:Something to note about other people's opinions

[SilentBob0727]

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 management software where everyone is required to read the commit logs seems to work better at fostering a team code environment than pair programming. There is something to be said for an employee having their own space. In my own experience, the only time pair programming has ever worked is in an EXTREMELY small (read: three people) team. It just doesn't seem to scale. Usually someone sits back and watches the other one code, going, "huh?" until they either give up and do something else or have to switch.

That said, XP has some good ideas (I test-driven development, refactoring) that when combined with the good ideas of the more traditional methodologies (story cards be damned; formal initial design and modeling are important!) create a more flexible development environment.

Every time I get the urge to document something, I first try to make it clearer, so the documentation isn't necessary. When I can't, I document. I would agree with you. Documentation is not a substitute for poorly written code.

To put it more succinctly: Quality comments enhance the readability of quality code. In other words, the art of comment writing is just as important as the art of code writing: there are good comments and there are bad comments. A few well-designed comments can go a long way towards elucidating a block of tricky code.

If you've got good unit test coverage, nobody should be afraid of deleting anything. If the tests fail, you just hit undo. Except when you have a function that's not called anywhere except from its unit test... then if you delete the function the unit test fails! You have to delete the test AND the function and then suddenly you have the same situation of fear of removing two things instead of one.

Re:Something to note about other people's opinions

[magical_mystery_meat]

The no-comments maxim of Agile is, frankly, horseshit. Kent Beck came up with it to sell books to people who don't like writing in English. It's nothing but a rationalization for egomaniacs who think they are incapable of writing bad code.

Do you have a cast-iron photographic memory that can always recall what you were thinking at any given moment, six months later? I know I don't. But most programmers think they're infallible and that their code is perfect. They forget that someday someone else is going to have to work on this stuff, and what makes sense to you will likely be complete gibberish to everyone else.

I've seen the long-term effects of this philosophy and it's not pretty. I recently worked in a mature (4+ years) codebase that had been Agile from the start. It was a horrible, convoluted morass of spaghetti, mixing poorly designed classes and refactored-to-metrics code that used 10 methods and 5 classes to do what one sanely designed method would do. There were massive bugs that nobody could find, the code was inefficient, it took a good six months to get the best people in town trained well enough to work on it (and this place hired all contractors so they were writing their code as flashy as possible to show off just in case the other guys on their team happened to interview them for their next assignment).

I won't consider many programming practices to be completely invalid, but refusing to comment is one of them, and I will not work in such an environment again. It is a sign of stubbornness and hubris and neither of those are agile states of mind.

Re:Something to note about other people's opinions

[Beardo the Bearded]

I once wrote a bit of code that was about 15 lines.

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!)

At this point, get the GPS longitude minutes:
$GPGGA,180432.00,4027.027912,N,08704.857070, W
                                  ^^
 
GPS.longitude_min = get_number
GPS.longitude_min << 4
GPS.longitude_min |= get_number
 
Skip the period:
$GPGGA,180432.00,4027.027912,N,08704.857070, W
                                    ^
skip_period;

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:Something to note about other people's opinions

[fbjon]

That's not the worst problem with the code, my immediate question was "what is v, and why do we want to put several doubles in it?". It's like reading a suspense thriller, the ending provides the explanation. A single line comment at the start: "//Read in doubles and print in reverse order" would give all the explanation needed for anyone to figure out what happens, even for someone who's never seen C++ before.

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

[nahdude812]

There is too often a difference between what a block of code does and what it is supposed to do. Code comments can indicate the intention of a block of code. This is a big deal, because I see code which passes test cases all the time, but which don't work as intended especially under exception circumstances (what if the arguments were a value other than what was expected).

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:Something to note about other people's opinions

[nonsequitor]

do people out there really have TIME for coding methodologies, reviews and the like?

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 out your code is a mess, nothing has been thoroughly tested and it breaks when the customer tries it.

Your boss is pretty upset at this point, you've just embarrassed your company in front of a customer. You work with the customer find out how it broke, fix it with a hack, knowing you'll clean it up later and send a new version to the customer. You still haven't fully tested it at this point, but thats okay because they needed this last week.

The software breaks again, the cycle repeats a few more times and now you have something which is stable. You ask your boss for time to clean up the hacks, he says no, I have another project for you. A month later the software breaks again, to fix it you realize you have to rewrite the whole thing because the lack of proper design and hacks layered upon hacks make it necessary to do major rework.

By the end of all this you've lost a customer, they've decided that the price of doing business with you is too great because you're unable to estimate how long and how much a job will really take, and it interferes with their business.

Now consider the alternative, you throw together some code that works and tell your boss "Don't worry, I have some proof of concept code finished and it will take only 3 more weeks to finish this project." You use that code as an example and design, have design reviews, code, have code reviews, and do unit and integration testing. When you deliver it to the customer, it works, is robust, and you have a happy customer.

As a programmer, it is your job to properly manage the expectations of those around you so that plans can be made around your deliveries. If your code always works when delivered, as opposed to almost invariably having easily exposed bugs, you build a reputation for being reliable and having accurate estimations. Sure it takes longer, but a few extra weeks up front can save months of time down the road.

Re:Something to note about other people's opinions

[tilde_e]

How about int nReversedIMin = m_nIMax; for starters? Do you really believe a single line comment that could be 40 lines above the code that uses nIMin is sufficient? Adding the comment there just says "I intentionally made this code confusing. Good luck."

I think if you relax your absolutism a little you can find better solutions.

(BTW, m_ is a very weak convention. 'this' is much more clear and some compilers can enforce that you *must* use it -- Eclipse/Java project settings for example. I've also seen someone prefix every function parameter name with 'arg', what is that about? Talk like a pirate day?)

Re:Something to note about other people's opinions

[Mr2cents]

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 field, I don't get as many support calls as some of my collegues. I get the job done and the customer is happy. But should you measure my productivity by how much code I write each day, I would be a lousy programmer. This is exactly what I mean by courage: in the face of deadlines, mass hysteria, panic and worried bosses, you need to sit back and relax.

Your second statement is beating a dead horse.

Your third statement... I don't know how you got there. Where did refactoring enter the discussion?

I'm not sure how that is helpful advice. You can't know how simple you can make something without usage. We come back to spending time reworking something you've already written. Once you see how other people (or just yourself) need to use it in the real world, you know how complex it *NEEDS* to be. Programmers are generally lazy and do not write things more complicated than necessary. When you start out sometimes it can get out of hand, but you come back to reality or dont ever come back. /For who, exactly, was that advice...insightful? What I do is I write an as simple as possible API, and I pretend it is already implemented. Then I can use it in the rest of my code and if it is insufficient, I rethink the API. Of course you cannot always foresee all the neccesary functionality beforehand, but that's something everyone has to live with. If you know a way to make a completely stable API right from day one, I'm very curious to know.

On the other hand, if you constantly need to change the API, it's a sign you haven't clearly defined what you're willing to abstract. Again, thinking about the problem will make it clear what you need and in 80% of the cases it will do fine without modification (rough estimate from personal experience).

And if you think everybody writes code as simple and short as possible, you're either not very experienced, or else I want to work where you do.

PS: I could be wrong, but from the tone of your post I conclude that you consider me some sort of babbling fool. Let me assure you, I'm not - at least not on this subject. Sorry if I sound arrogant (hey, you started it), but my IQ is 135, I've been programming for over 20 years now, and I really, really know what I'm doing. Don't mess with me ;-).

Same here

[polar red]

the problem is... the client doesn't always know what he wants, and the continuous changing of the specs (and hence of the code) make it a mess. It gets worse when near release some 'minor' changes have to be included and a lot of code has to be written in a very short time. There's a big difference between the theory of the 'waterfall-model'(and it's derivatives) and reality.

Re:Same here

[ByOhTek]

That, and "convincing the boss the customer isn't always right is a dumb and pointless thing for several reasons"

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 you think otherwise, you need put your arrogance in check so that you can produce useful quality code.
3) The customer, in the interim, still knows their situations and setups better than you in most cases. While they may need to change requirements for overlooked circumstances and situations, that doesn't mean they don't know what is going on.
3.a) Pointing out that they have missed something isn't necessarily a bad idea though, if you do it in a respectful manner. This can actually improve their perception of the quality of your work.

You have to communicate

[MosesJones]

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.

The virtue of constraint, and other musings...

[Max Romantschuk]

I seem to find that trying to code more slowly than I could helps a lot. I'm not the most efficient coder there is, but I tend to produce less bugs and have more time to make better design decisions when I slow myself down.

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

[ilovegeorgebush]

In programming, there are a million and one ways to do the same thing. There is no right or wrong, only good & bad. I've seen some damn shocking code over the past few years, and I've written my fair share too. It's swings and roundabouts, it's up to you to learn from your mistakes and push yourself as a programmer to better your code quality. Keep in mind that what you right is what people use, and it's the difference between "computers suck" and "hey, that was cool!".

And as the first reply said, someone will always criticise your code. Decent programmers know this and still do their best.

Be proud of the work, not the code

[PIPBoy3000]

I have a lot of applications that are elegant enough. It may not have perfect validation for every field and not all the GUI bells and whistles, but it does what it's supposed to. I know my share of developers that spend a ton of time making their code elegant and beautiful. In one case, the developer spent so much time making their N-tier application with huge numbers of tables that were normalized to the bajillionth degree that they were finally let go. The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.

Re:Be proud of the work, not the code

[oliderid]

Personnally an elegant code is:

- 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.

There is hope!

[big ben bullet]

Buzzword alert: Agile!

But seriously: Things like Test-Driven Development (TDD) and even Behavior-Driven Development have proven to be great approaches in software development.

Also, software management methodologies have evolved in a tight interaction between business (customer) and the development team. Take 'Scrum' for example... think 'iterative'.

If your superiors aren't convinced that at least the test driven part is necessary then you should seriously consider getting out of there.

You can still write crap code, but at least that crap code is backed up by a unit test. Otoh, if your test is crap... you _are_ the weakest link: Goodbye!

Code is communication

[Dystopian Rebel]

After a long time in the software industry, I came to realize that Code Is Communication.

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

[eebra82]

Gather around me kids, for I am sitting here in my 18th century rocker to tell you a story about a programmer.. A good programmer..

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.

Re:More Design

[0xdeadbeef]

Design time is wasted time. People don't know what they want, and they won't make meaningful decisions until they have something running in their hands.

Here's a start to better code

[Man_Holmes]

My advice would be to read The Pragmatic Programmer book by Hunt and Thomas. It provides the best blue print I have seen to solving the problem for you.

You may not be able to implement all the changes at once but you will find that you've got more authority than you realize.

You may not even agree with all of it, implement what makes sense and your code will improve. I've found with my friends that the longer you've been coding the more sense that the book makes.


Man Holmes

Yes, yes and yes

[YeeHaW_Jelte]

Yes, I am proud of my code, or maybe not always the code but at least my coding. It's not always possible to create beautiful, well mantainable code. I try to, but sometimes there's just not the time.

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 ... it's a pretty large department for such a small company, as we write all our inhouse software ourselves and have been for the last 5 years. When I came to work here, the codebase was about that old -- 5 years -- and maybe a two dozen different 'cowboys' had been writing the software resulting in a large heap of steaming shit. They were not centrally coordinated and everyone of them was doing things in his own style either out of laziness of ignorance.

Anyhow, I managed to convince the CEO that there was a problem ... she had no idea that it was a mess, the company being a travel agency and she having very little knowledge of automation herself. I used a difficult coding project (connecting to a GDS, the guys that administer plane reservations, car rental, cruises etc) and a general optimation project ( the application was becoming very slow due to all the bad programming going on ) to build her confidence in me and asked her to put me in charge of code sanity. She did.

I am now trying to reform the bunch of code cowboys that currently works here to a well disciplined programming team ... and I hope I'm succeeding. Gave them code standards to work to, asked them to clean up the code base where they stumbled upon crappy pieces, moved from Visual Source Safe to Subverion (thank god!) and started regular meetings once a week.

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...

[w4rl5ck]

I came to the conclusion that you are the only person who is ultimately responsible for the state of the code you write is YOU. Nothing else, no one else.

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 :)

Re:Customers often WRONG

[Anonymous Coward]

The customer may not always be right but the customer is NEVER wrong - the privlege pf the paymaster

The normal response of an inexperienced programmer

[petes_PoV]

.. is to criticise the code they inherit.

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:More Design

[Foolicious]

Often times you can avoid a lot of this headache by spending more time in design.

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!

Re:Lost out

[bhaak1]

Just for the record: AmigaBASIC was my first real programming language (LOGO on paper doesn't count).

That you don't know this quote (it's from 1975 BTW) and have been to the university just shows how much CS is a science without respect for its history.

That you don't have heard of Edsger W. Dijkstra is shame.
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra

Tell me, do you consider the GOTO command harmful?

Perspective and Experience

[martyb]

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:

• I've written crap code. I think it's part of the rite of passage. I did the best I could with what I knew, and when I knew better, I tried to do better.
• I've read books and taken courses, but there's no comparison to just diving in and reading LOTS of OTHER PEOPLE's code... and then learning from it.
• Attitude is important. There is a HUGE difference between "That's stupid" and "Why did they do THAT?" Be open to be educated.
• Be organized. In your thinking, notes, and code. In my experience, bugs tend to congregate at the interfaces. Be it a procedure call or return or in an interrupt handler, I try to keep things as clean as possible. Hacks WILL come back and bite me/others.
• Make junk stick out. When I'm pressed for time and know I'm taking a shortcut, I flag it as such. It's easier for me to find a needle in a haystack if I use BIG needles.

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.

Actually...

[RingDev]

One of my coworkers told me the other day he loved my new authentication and credentials system I used for the Data Access Layer. So much so that he snagged it and used it in another system that had similar authentication requirements.

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

Management has a role in this too

[Anonymous Coward]

I've worked both as a manager and as a programmer, and -- although the programmers do have a significant impact on the quality of the code -- I feel that management's impact is even greater. Technically, even if the programmers all suck, it was ultimately a management decision to hire them (or to not hire enough developers, or to not train them if needed, or to re-assign them if required, or fire them if warranted). Sure, other factors may constrain what management can or can not do (budget, etc.), but... the buck stops somewhere, and that's usually at some manager's desk.

Now, I have seen programmers that wrote lousy code, but I've also seen a lot of really good, bright, motivated developers that were forced to compromise the quality of their code because they had no other choice. I remember one newly hired, enthusiastic jr. developer complaining about another developer's code (cutting and pasting, hacking, etc.), and then 6 months later he was resigned to the fact the he himself had to hack most of his code in order to meet the latest deadline..... this being a deadline that was already 50% shorter than the original developer estimate, grew larger due to "extra" customer committments (while keeping the "schedule" basically the same), and having to have worked most evenings and weekends for quite some time to "stay on schedule". There really wasn't much else that programmer could do, and he couldn't work any longer hours then he was already doing. If the schedule wasn't being met, then the developers were expected to make that time up and they weren't getting much sleep as it was.

And yes, the developer (not the manager) was still held responsible for the quality of the code afterwards. During one team meeting, a manager even stated "do whatever it takes, just get it done". So the developer did do whatever it took -- including design and coding shortcuts (and this was the developer's last resort: he tried working longer hours, but at some point couldn't keep it up). The developers even told management that they would need to take shortcuts to meet the deadline. Of course, the management critisized their designs and coding skills months afterwards.

Some of those managers believed that this aggressive scheduling was a "good thing" (after all, "...work expands to fill the amount of time given...", along with the reasoning that if they only give the developers 3 months to a 6 month project, then they have 3 months of buffer). Now, some managers were keen on actually changing things (as per some developers suggestions), but this turned out to really mean: "We're interested in changing things if it means that the developers change the way THEY do things. We're still going to keep managing things the same way we always did." That latter part was probably partially intentional, and partially unintentional (some really did want to change the way things were managed, but they themselves were too familiar with the old way of doing things to really change anything).

Now, I don't want to put too much blame on management (and some of my slant might be a bit biased, since the incidents are still fresh in my memory), but the point is that management can, and does, have a significant impact on the fate of the project and on the quality of the code being produced. Just because the developers are the actual ones writing the code, doesn't mean that they're solely responsible for the quality of that code.

As for improving the situation, I HAVE seen companies make changes for the better when those changes were management-driven, and driven by a manager that knew what changes to make and believed in them. When the changes were initiated by the developers, they tended not to really get adopted -- mostly because management didn't really embrace the new way of doing things. Not that that's a reason to remain quiet if you're a developer: your best bet may be to talk with management about why things aren't working well under the current system, and why things need to change (along wi

Re:Sorry, I have to bite about this.

[SilentBob0727]

I think we're saying essentially the same thing. I'm arguing for better commenting and learning what kinds of comments are unnecessary.

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 extent, "how" (if the how isn't plainly obvious).

I think the "if in doubt, comment" suggestion is actually bad advice. It leaves people thinking, "God, I really should write a comment here, but I just don't know what would make this line any clearer." Crap like "// create an integer and add two to it" comes about as a result.

>> It's said comments are like sex - even when they're bad, they're still pretty good.

I would suggest over-commenting is like having sex while watching a porno -- great at first but after a while it becomes a distraction. When comments are well written, it really becomes a case where less is more.

Not quite true

[Moraelin]

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.

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 block with 10 cases is really all you need, you know? His programs tend to be compact, work and be actually fairly easy to get the hang of.

- one of them is, well, pretty much the opposite. His programs tend to be a lot larger than they need to be, and have layers upon layers of patterns even to print "Hello World". With some reflection thrown in for good measure. Strangely enough, though, they _are_ well organized, and you can fairly easily find the class that processes a given event or command... or the singleton factory that supplies it, or the manager class it's registered with, or...

Are they perfect according to my tastes? Nope. But I can nevertheless tell good code when I see it, even if it's not perfect. And say it.

On the other hand, at the other end of the spectrum, I've had to deal with pieces of code which were truly atrocious. E.g., one particular program not only raped all best practices known to mankind, but also was living illustration of half the techniques from How to write unmaintainable code. Literally. It even had stuff like the using people's first names for variables, in addition to the more mundane techniques like mere undescriptive names, obfuscated flow, heavy use of global variables, non-obvious side-effects to those variables, or methods which can also do some 2-3 other unrelated things if called with the right parameters. And I don't mean just side-effects or cramming more functionality in one call than expected. I mean stuff like the class which should have normally sent an email, could render and print a PDF _instead_ of sending one email, or update the contract in the database instead. And for bonus points, not even determined by parameters, but by the contents of those global variables. But, again, the nicest touch was finding uninformative variable names like Pete and Eve in the very first class I opened.

Basically IMHO lumping it all into one everything-is-the-same "all programmers hate each others' code" pool doesn't do it justice, and paints a misleading image. _Some_ may be just nitpicking about the style, but some code is genuinely evil stuff that should be buried at crossroads with a stake through its chest.

Re:My code is ok

[cayenne8]

"He also happens to be the one that signs my paychecks. So, there is only so much I can do."

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, the bigger the better.

This also helps to realize, there is always another job willing to sign a paycheck for you...you are not stuck, if someone offers me more $$, I will immediately go that way, no malice, it is all just business.

Once you can get into that mindset, your life will be much better, less stressful, and you make more $$ as you go along.

Re:To be honest?

[Anonymous Coward]

One of the marks of incompetence is thinking you are competent.
One of the marks of competence is understanding how incompetent you are.

Re:The normal response of an inexperienced program

[0xABADC0DA]

All programmers criticize the code they inherit. The key point is what the criticisms are. As a rule of thumb:

* 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 and naming: The code is roughly at your same level of ability. You can understand it and modify it, but you don't want to because it smells bad.
* High-level structures: The code is written by a more skilled programmer. You probably do not understand why the code was written as it was even with documentation, and even if you do then changes you make will cause a lot of side-effects and unexpected errors. Sadly you should rewrite this code because you cannot make other than superficial changes since you fundamentally do not understand it.

Generally the code is at the lowest level you are complaining about.

Another common trait is to deny one's own faults. First of all, if somebody says something is "equally likely" as something else that's almost always some kind of rationalization. There are precious few things that are equally likely (or fair and balanced), and in this case any decent programmer should be able to determine immediately if there are some few ugly sections vs the whole program being a huge pile of crap.

Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops. Another mistake is to have programmers of very different talent (as opposed to experience) working together. This invariably causes the very talented ones to leave and the poor ones are left with code they don't understand.