Slashdot Mirror
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?"
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.
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.
Yes, I'm left. You have a problem with that?
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.
Often times you can avoid a lot of this headache by spending more time in design. If you can flush the project out in some detail during design, and include the customer, more of those changes will be included in the original design before you ever start to code. Unfortunately, others in your organization will often feel like design time is wasted time. You have to be steadfast in your will to spend time in the design phase.
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.
An Eye for an Eye will make the whole world blind - Gandhi
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...
.: Max Romantschuk
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.
ilovegeorgebush
No matter what I think of my code, I always know (pray) that it'll never be bad enough to be submitted to Worse Than Failure.
That said, I do revisit code that I'd written a few years back and think "WTF were you thinking?!"
Summation 2
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 as a model of our software development "practices".
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.
The answer to your question as to what is holding you back is complicated and multi-faceted. I'm sure you'll receive many interesting answers (and I look forward to reading them...hopefully it'll help me become a better coder).
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.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
Edsger Dijkstra
Sorry mate, there is no hope
The best code I've ever had the pleasure of working on, was made when I worked for an actual engineering company. Not software engineering, but engineers that build physical stuff.
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
We do not live in the 21st century. We live in the 20 second century.
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.
PHEM - party like it's 1997-2003!
...to somebody, for some reason.
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.
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
Full Tilt
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."
What do you mean they cut the power? How can they cut the power, man? They're animals!
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
I often use "Programmer: Alan Smithee" in the comment header
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.
... 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.
... 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.
... 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.
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.
---
"The chances of a demonic possession spreading are remote -- relax."
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
Generally, whenever I complete a set of code, it's perfect. It's flawless. It's the stunning pinnacle of coding, and it should go on some kind of display page where everyone can marvel at it, worship it and experience its perfection so they may find true enlightenment.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
StoneCypher is Full of BS
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.
Badgers, we don't need no stinking badgers! - UHF
"Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"
Good luck with that one. Successful technology companies use pie in the sky marketing. Reality does not sell. When you are not saying yes I can do it faster and better then you are whining as far as CEOs are concerned.
I have a great career and made lot of money writing crappy code. My bosses have always loved it because I am fast to produce an end result. I call it prototyping and constantly remind my employer that I am creating a demo of what can be done. But in the end the demo always goes into production. I have seen several programmers much better than I get fired because they could not bring themselves to lower standards. I guess I'm just a code slut.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Ok, so this might sound a little harsh, but you see, the solution to your problem is this: code better. It really is that simple. Yes, it's nice if you can anchor things with project managers or whatever you have above you, but it's not really necessary.
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.
...as if the guy who is going to maintain it is a 6'6" tall two feet wide bodybuilding psychopath who knows where you live.
My opinion? See above.
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. In turn, this will result in crappy code since the project will suddenly be late and go from profitable to a net loss.
OTOH, if you gracefully hear the customer out, then produce a change order for them to sign which outlines how much longer it will take and how much more it will cost, all is well. They'll either tell you to forget about the change or they'll approve it and the extra work is extra profit. There may be a few customers who will cancel the project in a huff, but that was their choice to make. At least you don't get the reputation for producing fragile bug ridden unmaintainable junk.
A useful rule of thumb there is that if you can accomplish the change more uickly than you can produce the change order, just do it to keep the customer happy. If that encourages them to bury you in trivial changes, you can always gather them up into a change order at that point and explain that the project is now too far along to trivially make those changes.
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.
Adopt a development methodology that defines what features will be developed and what features WILL NOT be developed. Now you have a place to put all those "great ideas" people have while you're still making the base product. You can also keep them in mind while making other modules, so you know you can make them later. This eliminates scope creep. It may not seem like a piece of paper will work, but as a society we all know the power of forms. Act like it's not your choice, that someone in management is making you use the methodology. No one will want to contradict anyone else so they will just accept it. And when it works, and you come in on-time and on-budget it will become part of the corporate culture.
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 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
Cool! Amazing Toys.
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Once in a while I take a small change and tell the client/boss/myself that it is a really BIG change.
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.
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
I am one of those people who likes lots of code. So much so that I've developed a style, similar to how I used to code 68k assembler, of running comments down a second column (usually 40-60 characters in) that describes what is going on. After all, it doesn't interrupt the flow of the code, and if you're editing Java on an 80-column fixed-width interface, you're doing it wrong to begin with. I wouldn't say I comment every line, probably one in every 3. However, this gripe with over-commenting is fundamentally flawed:
:) However, if it was being used in a loop, why is it being set to a+2? Is a some sort of offset in an array? Is it a user-entered value? THIS is what the comments will illustrate, eg:
// skip the first two elements in the loop as they contain other data
// user input will be off by 2 because of (strange reason here)
// now split the input into an array and parse ready to give to the file handler
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.
My last two projects have been to babysit and sun down legacy systems. These were written in Perl, are web & database based, were written over a period of about ten years by multiple people, had no development system (all changes are made in production), and are each at least a half million lines of code.
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.
-- Stephen.
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.
A polar bear is a cartesian bear after a coordinate transform.
Ah, kids these days... so easily impressed.
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.
A polar bear is a cartesian bear after a coordinate transform.
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.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
I fully agree. I inherited a LOT of uncommented and shittily commented code, and it is a royal PITA to figure out WHY it is doing what it is doing (which was basically your point). On the other hand, at least with crappy comments, there is occasionally a nugget of useful information...I despise the comment-free code more, but the code itself also looks like it was designed by someone on an acid trip.
.NET. And the other programmers whose code does NOT suck (separate project group) have given me positive feedback on what they've seen of mine. A limited degree of self-doubt is good for keeping you honest with the quality of your work, but don't worry about it TOO much.
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
* 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.
>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?
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.
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
but have you considered the following argument: shut up.
Patterns were developed to create a common ground where people can think about problems in a similar way.
I don't think that's worked. If anything, they've just created more confusion and more ways to head down the wrong path. The more experienced developers merely call them "suggestions to consider", not a central bible of truth.
Table-ized A.I.
It is not that I don't care, it is just I've had to train myself not to care.
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. They do not directly add to a companies bottom line. New features do.
That isn't to say clean code is bad; create an unstable buggy app because your code sucks and you'll loose money. The trick is finding the minimal amount of "good clean code" you need to write to make your userbase happy. Anymore and you are wasting resources.
I'd argue if your paycheck is tied to some nebulous idea of "good code" is getting rewarded wrong. Your paycheck should depend on another, equally nebulous notion of "good user experience". I'd rather you write a nasty hack job that makes everybody smile when they use your application than a hard to use application that pisses everybody off, but has "good code" in it.
Good Code is code which creates a happy user. No other definition should be allowed.
I fully agree - Having well worded comments is just as important as well thought out code. There are many times when I am debugging a piece of code and I know what the code is doing by reading the code, but since there are no comments I have no idea what it is supposed to do. And if you have to work on code that is not documented anywhere , except in the murky gray matter of someone that thinks they remember telling someone to write something, the in-code comments become essential.
I typically preface my more complex code blocks/functions etc with a brief algorithm this way someone in the future knows what I was intending to write and well and when I am writing I can verify that my code does what my algorithm says. This sort of documentation also helps clarify the task and helps define all possible logic scenarios. This way you can write a more complete, stable piece and possible bug free (yeah right) of software.
This is just a mature way of programming.
P.S. - I never claim someone else's code sucks just because they don't have my 'style' of coding. I just want the code to work properly.
The unfortunate truth, and this goes for ever profession, is that the customer is almost NEVER right, in fact, you can count on them being wrong about 95% of the time.
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!"
Multiplayer Gaming (defined): Sitting around, discussing single-player games with my friends, at the bar.