Slashdot Mirror
Programming Mistakes To Avoid
snydeq writes "InfoWorld's Peter Wayner outlines some of the most common programming mistakes and how to avoid them. 'Certain programming practices send the majority of developers reaching for their hair upon opening a file that has been exhibiting too much "character." Spend some time in a bar near any tech company, and you'll hear the howls: Why did the programmer use that antiquated structure? Where was the mechanism for defending against attacks from the Web? Wasn't any thought given to what a noob would do with the program?' Wayner writes. From playing it fast and loose, to delegating too much to frameworks, to relying too heavily on magic boxes, to overdetermining the user experience — each programming pitfall is accompanied by its opposing pair, lending further proof that 'programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes.'"
What common mistakes do you frequently have to deal with?
And now for the printable version with all the tips on one page:
http://infoworld.com/print/145292
Y
What common mistakes do you frequently have to deal with?
- Software only tested by programmer.
- Manual only written by programmer.
- Support can't do a day without programmer.
A good programmer should know when to delegate. Or their boss should. Depends on office culture perhaps.
Hivemind harvest in progress..
...just try to avoid errors and you should be set.
Until you spend enough time with it, to learn why the original programmer did as he did.
As I see it, most projects start out with a good structure and the best of intentions, and then comes deadlines and the developer having to juggle several projects at once, and then a shortcut is taken here, then there. And suddenly you end up with a non-documented project where the only person that knows how it works is the original developer.
There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.
I've also had to take over projects where the original developer was using new technology because he thought it would be fun (at the expense of the customer). Having a huge website in PHP/MySQL and then having crucial parts of it in Ruby/PostreSQL is just a maintenance nightmare.
My <1000 UID is with a hot chick
Equating web programming with all programming.
Learing how to do it in the first place.
Programming mistake No. 1: Playing it fast and loose
Failing to shore up the basics is the easiest way to undercut your code. Often this means overlooking how arbitrary user behavior will affect your program. Will the input of a zero find its way into a division operation? Will submitted text be the right length? Have date formats been vetted? Is the username verified against the database? Mistakes in the smallest places cause software to fail.
Fair enough. So debug while you code. Seems like good advice.
Programming mistake No. 2: Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Checking a few null pointers may not make much difference, but some software is written to be like an obsessive-compulsive who must check that the doors are locked again and again so that sleep never comes.
Doesn't mistake number 2 contradict number 1? Or am I missing something? I guess he's saying debug while you code, but not too much. After reading the rest I see that that was his algorithm for writing the whole article. Rule 1: do x; Rule 2: But not too much! I didn't really find the article all that useful.
All programming should be assembly language programming anyway and a lot of his rules don't seem to apply to assembly language programming. Remember rules aren't necessary when you are a programming god who only codes directly in machine opcodes. Even assemblers are for weenies. Man up and become one with the machine!
Quite an experience to live in fear, isn't it? That's what it is to be a slave.
The most common programming mistake to avoid: Reading badly written articles about "what programming mistakes to avoid".
Doesn't mistake number 2 contradict number 1? Or am I missing something?
Yup. FTA:
Below you will find the most common programming pitfalls, each of which is accompanied by its opposing pair, lending further proof that programming may in fact be transforming into an art -- ...
Hivemind harvest in progress..
I very rarely see programming mistakes. There seems to be 2 kinds of programmers.
- Those who care about what they do and try hard.
- Those who don't care about what they do and don't try hard
The later write terrible code, but it is just because they are either lazy or aren't suited to the profession and can't get enthused. Very rarely do you see someone who cares about there work make a big mistake (and if so they are probably just starting out).
Programming mistake #0: Believing that your computer degree (Computer Engineering or Computer Science alike) automatically puts your code in a high level of quality.
Not to bring any academia vs industry argument, but many students miss the idea of a Computer degree with programming courses in it: The degree intentionally doesn't go to details because it needs to give you a background into a broader set of subjects. Industry needs one to be very attentive to details in that one thing he's doing at the moment.
The only common mistake I see is not firing the programmer who makes any of those "common" mistakes. There is absolutely no reason for any of this shit to be "common" unless "programmers" who make them are uneducated dumbasses who should never be allowed anywhere near software development.
Now, please, give me the list of "common mistakes" made by surgeons and aircraft engineers, and compare them with this list of amateurish crap.
Contrary to the popular belief, there indeed is no God.
It gets worse when BAD programmers, think they are good.
Unless you're coding in machine opcodes like a previous poster suggested, you're already losing some optimization potential by relying on the compiler/interpreter to do it for you. Even in C you're relying heavily on machine generated code. So why is garbage collection so bad?
It seems to me like the structured programming debate all over again.
Dilbert RSS feed
Pointer typedefs were a bad idea in the 1980s. They're just terrible today. One pet peeve of mine is this:
typedef struct _FOO { int Blah; } FOO, *PFOO;
void
SomeFunction(const PFOO);
That const doesn't do what you think it does. There was never a good reason to use pointer typedefs. There is certainly no good reason to do so today. Just say no. If your coding convention disagrees, damn the coding convention.
He gives one example of an attempt to avoid null pointer errors in Java next:
public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}
But is it a good idea to use null to mean "no value specified"? What would be better, and what are the tradeoffs? Storing 0 or ""? Storing a special (constant/static) instance object nullValue?
I'm not a lawyer, but I play one on the Internet. Blog
So why is garbage collection so bad?
'cause it tends to flush predictability right down the toilet. When is the garbage collector going to swing around to do its thing? Are you *sure* it's going to be when it has enough time to do so? Or is it going to pick exactly the wrong moment? Am I going to run out of memory at an awkward time triggering a collection of thousands of objects I haven't used in ages?
Yes, all of these have perfectly valid workarounds.
However, then you are right back to knowing exactly what your compiler and environment are going to do, and sometimes even holding its hand. Manually triggering a collection isn't all that different from handling memory management yourself.
The Right Tool for the Right Job sometimes is low level. And by the way, many great programmers know quite well what the compiler will do with particular important bits of code, and if they do not, will invoke the compiler to generate assembly or intermediate-language code to be sure. Yes, in garbage-collected languages too, I've used ILDASM quite a bit to know what C#/.NET was doing, exactly.
1) VB
2) Perl
3) Silver bullets
3) Writing your own "framework".
4) Using somebody else's "framework".
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Is it indecent of me to reminisce on the days of olde when such a topic would simply turn into a lengthy discussion mocking BASIC programmers?
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself. Garbage collection is for little boys. Men deal with it on their own with techniques that work and are efficient.
So mega-strongly disagree dude. Not saying you shouldn't do heavy lifting when necessary -- just that you should only do it when necessary. Don't re-invent the wheel every time. Frameworks exist that do work for you for a reason. Chose your frameworks well, understand them in depth, and you can do good things. If you "start from the first principles" every time, you end up with a humongous fucking surface of new code -- which is bound to have a nasty bug or three. It comes down to choosing the best tools for the job.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
#3 - Use descriptive variable names
So true. Corollary to that: because a variable name is descriptive, don't make wanton assumptions about it.
#4 - you shouldn't be allowed to program anything new until you've been a maintenance programmer for a few years and seen the crap code that others puke into the world. Your crap code stinks too, BTW.
I'd modify this to say "always, always, always have a peer-review process". Junior devs are prevented from checking in crap because it gets caught by senior devs. The junior devs also learn quality habits from reviewing senior devs' code. Multiple reviewers is always a good thing. Review your design among the entire team before anyone writes a single line of code. Remember to keep security in mind when reviewing code. Use static analyzers when you're done with the "human" aspect of the review. Apply every imaginable quality bar to your code, and only check it in once it has passed scrutiny.
I'm supposed to program mistakes to avoid what?
I've not worked as a programmer for, hmm, maybe 15 years and all of this was known way back even before I "retired" from that line of work. Perhaps all these levels of abstraction upon abstraction make things harder to understand. Back in my days these "pitfalls" were obvious because we all (well, not all, but a lot) knew ASM and actually even used it regularly (even inline, *shudder*).
Someone above mentioned pointer typedefs and gave the example of typedef struct { int Blah; } FOO, *PFOO; (yes I left off the bit before the the opening brace deliberately.) and then suggesting that people don't know that void SomeFunction (const PFOO) {} doesn't behave as expected. Now this could, I suppose, be seen as a failure of the language. But, shit, any idiot who understands the underlying logic can see why that causes problems. Which goes back to my point of maybe all these modern levels of abstraction and getting away from the machine are, in some ways, detrimental.
Now, get off my lawn. Umm, except I don't have a lawn because I sprayed the growth inducing hormone RoundUp all over it, but that is beside the point. I think.
Always think of your code as some sort of API if you care about clean, maintainable code. This is a good talk about API and code design: http://www.youtube.com/watch?v=aAb7hSCtvGw/ from Josh Bloch. It's entertaining too.
On second thought, let's not go to Camelot. It is a silly place.
I still find myself using strcpy. Good thing I don't have a job.
All true. My personal favorites are larger, long running projects where all of the above is true and all kinds of undocumented business logic is embedded in the code making a rewrite unfeasable and you have to decide which part of the code is outright sloppy or bad, which parts are feasable and which parts aren't actually being used anymore. Top that off with the original developers being unavailable (either dead or fleeing) and you'd be painting a pretty accurate run-of-the-mill software enviroment.
---
"The chances of a demonic possession spreading are remote -- relax."
I hate it when I click on "Many More" to read more Slashdot stories, then click on a link in one of them, then return to Slashdot to see it all collapsed again.
Same when one expands the Full/Abbreviated/Hidden slider.
When's that gonna be fixed ?
I did went throught the list in TFA and while their "programming mistakes" list is sound, it's all over the place and often doesn't dig down to why should you do or not a certain thing.
So I decided to put down a list of, low level principles and concerns to consider when doing software. Given my own level of experience and the fact that I'm getting tired of maintining code by people who have never managed to cross the threshold from junior/medior software designer to senior designer, that is the target audience.
So here goes:
- When designing/coding software, assume that sooner or later it's going to be called-by/changed/extended by a junior developer. They cannot be relied on to recognize design structures or practices and will do things like passing bad parameters in, or incorrectly use it (for example, misusing a singleton). My solution to this is defensive design/coding: check for nulls at library entry points and fail-fast (avoid "junk-in junk-out" scenarios - those just make for data corruption and hard to track bugs), make sure things like singleton classes cannot be instanciated normaly, avoid obscure constructs that must be used in a "right way" (i.e. functions that should be called in a certain order) and overall try and make your design so that the natural way of using it is also the correct way.
- When designing software, before employing a certain construct (for example a design pattern) ask yourself "What do I want to achieve with it?". Complex software structures are used instead of simple (and easier to understand) ones because they achieve certain objectives which outweight the increase in complexity - don't use it because it's fancy/fashionable/elegant/everybody-does-it: those are not proper reasons. The cost to maintain, support and extend code grows with code size and complexity and using fancy structures just because is a way to dig a deep hole for your colleagues and your future self. Consider that it's allways cheaper to "add it later if and when we need it" than "maintain code that is twice the size for 6 months". For example, what is achieved by defining an interface for which now (and in the foreseeable future) only one implementation exists?
- Design and code your software so that Responsabilities and Domain-knowledge are contained together in their own modules/classes. Avoid leakage of concerns (i.e. "we do it this way here because we know that the code we call in another module works in such and such way"). This makes it easier to find ALL the code responsible for doing a certain kind of thing and avoids the dreaded "I changed it in one place but forgot to change it in another place" problem. For example, don't mix your database access code (that knows all about SQL and tables and such) with your web-page generation code (which is experting in user interaction via HTML) since they are independent domains (you can have one without the other).
Being still employed by the company when the project goes overtime and over budget.
Experienced programmers should've found another employer at a higher salary before their incompetence is discovered....
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.
I see this one as a lack-of-experience problem. People have good intentions and want to build scalable, extensible, maintainable code. This is good. Unfortunately however, they're wrong. The apps they're building are small irregardless of the amount of thought they put into them, and they won't have to scale and extend the way they think they might - you don't need interfaces and impls and arbitrary inheritance for everything when the webapp is 4 screens of Spring WebFlow! Sure, if you're building something that warrants it, this is the way to go, but most of aren't building apps that big or flexible. It seems to take time to learn this, and to know when to apply the patterns and when to just build it.
As a smarter man than I once said, Make things as simple as possible, but no simpler. If you do that, your code will work, it'll be understandable by the next guy, and you'll have a fighting chance of meeting your deadlines.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}
WTF?
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Half of these are design mistakes
did you forget to take your meds?
Just add more code! That always makes it better. Closely followed by "It's unreliable/broken" "We've got to rewrite that old xxxx in m$'s new blah-ty-blah framework!".
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
I was never anywhere the server last night!
My two most common mistakes:
Crumb's Corollary: Never bring a knife to a bun fight.
Allowing too many options / features in the design. The classic example being unable to decide whether feature A or B is best, and ducking the issue by including them both
Assuming 5 working-days of effort can be achieved in a working week. Conveniently forgetting about all the office overheads such as "progress" meetings, timesheet administration, interrupted work, all the other concurrent projects. Even the most efficient, single-threaded operation needs half a working-day per week just for the trivia.
Following on from that, conveniently forgetting about annual leave commitments, national holidays and the possibility of sickness. If 5 working-days per week is impractical, 12 working-months in a year is downright negligent.
The tacit assumption that testing will inevitably be followed by reelase - rather than bug-fixing.
Holding the end-date constant while delaying the start, or presuming that all delays in the specification, design, approval stages can somehow be reclaimed during coding (how: by thining faster?)
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
The biggest programming mistakes I've had the displeasure of making, or discovering in others code, almost always centre around one of these two problems:
1. The code is over-engineered
2. The code was abstracted before there was even a need for the abstraction.
I remember when I was less experienced, how thrilled I'd be over code that was clever, solved many problems aside from the one I was trying to solve, and had some clear reusability built in. What a work of art, I thought.... until I eventually realised that much of the extra code I had written didn't get used, the abstracted code was never reused - or even if it was, I couldn't predict how it would be reused and the abstraction was clumsy at best, useless at worst.
It's sad when this happens - good intentions, but the end result is a lot of waste. I'm embarrassed to look over my earlier code which is like this.. I like to think I do it less now, but the temptation is always there... I'm going to need to do this later anyway... I can just abstract this bit here and reuse it some day in the future...
My advice now... Don't do it! Just wait until the reuse case comes along, or the new feature request comes along, and *then* do it. You'll know so much more about the problem domain then, or you might avoid days (weeks!) of wasted effort.
Java
If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself
I look at the problem like this;
I've solved a fair number of sudoku puzzles in my time. You build a mental set of rules and patterns you look for, and you repeatedly apply them to the remaining squares. On a really hard puzzle you'll often reach a point where you get stuck. You keep scanning for patterns in the remaining numbers but you just can't see the one clue that causes the rest of the solution to fall out.
But a computer program? Once you tell it how to find something, it never forgets to apply a rule. You may think you can keep following a small set of simple rules while building a complex software solution. But chances are pretty good that you'll miss something. If you can hand a task like memory management to a software solution, there's a good chance it will do a better job at tracking memory than you will.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
>> 'programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes.'"
Its not transforming into it, it's always been an art. And that has got nothing to do with whether its web programming or not.
The reason that this is even news to some people is that most managers fight hard to bury that fact, because the vast majority of them are one-trick ponies that incorrectly think that everything can and should be reduced into a plannable production line process, and that we developers are all simply non-creative, cheap and freely interchangeable commodity called a 'coder'.
Admitting programming is an art makes management have to admit that:
1) Not all programmers are the same therefore we have value, so need to be paid appropriately.
2) Its not a predictable process so you can't micro-manage us.
I hate it when some enterprising test engineer decides to add a constant value in place of the instrument reading to force a pass.
Then when you 'fix' this, the shit hits the fan cause you're the one who has 'broke it'. (Not that the DUT's are faulty)
Especially love it when it's on a testset for a train's break force tests...
Comment removed based on user account deletion
The above is true for any control flow. The only real problem with goto is over-zealous CS grads who don't know anything more than "goto is bad because someone said it is". Challenging experienced programmers on their use of goto is both arrogant and rude. If somebody wants to imply that I don't know what I'm doing they are most welcome to fuck off!
I was recently working on a horribly written .Net app that created and de-referenced tons of objects in its main loop. The net result was memory usage going from 200MB one second to 500MB another second. Based on how quickly over all system memory was cleared up, the .Net GC must kick in right away. I'm not talking about objects lingering around for minutes or even tens of seconds, I'm talking about just a few seconds.
If you're going to gripe about using a language that uses a GC, then it's perfectly valid to gripe about ANY abstraction you use between you and the computer to program. Like any tool, it can be incorrectly used.
The Right Tool for the Right Job sometimes is low level.
There, FTFY... oh wait
Never code anything important between 1PM and 3PM (or whatever is your most sleepy time of the day based on your circadian rhythm).
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
It's not the code that's the problem! it's the choice of Windows + Java + Tomcat + SQL Server.
Talk about AWESOME.
(How about a Java application where a block of simple, everyday fixed classes were written in Groovy? See; nothing changes. New toys used to make the same old mistakes.)
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
This one bugs the hell out of me:
:= assignments, but instead to a SELECT DECODE FROM dual.
In PL/SQL, when people for some bizarre reason avoid using IF/THEN/ELSE and normal
Why?! Dear Lord why?
It's harder to read. It's slower. It's against normal practises. It's an utterly unecessary use of SELECT.
So why do they do it? And why do they insist - when I point out their stupidity - that it's "just developer preference" and "there's no performance hit"?
HELP ME!
Don't get me started on preventing programming mistakes. If I'd address the most common programming mistakes that I've ran into in the wild and write an article about each of those mistakes at a time, I would end up with a whole book on the matter and would probably call it "Growing Better Software".
I find the given top 12 list of mistakes a bit weak- I'd be able to avoid all of these and yet write horrible code. My personal recommendation for a top 12 of programming mistakes to avoid would be:
1. Failing to check function parameters before using them: null pointers, limits, lengths, etc. This will make your program unstable and/or unpredictable.
2. Spending too little time thinking about and designing the data structure of the application. This will make you get stuck when maintaining/extending your application.
3. Following every market hype - When the marketing bubble bursts, you'll have to start over again.
4. Designing user interfaces without actually involving users - You'll be surprised how easy it is to confuse users.
5. Infinitely deeply nested if/else statements - This will make code absolutely unreadable.
6. No documentation whatsoever - Who's going to maintain your code after you change jobs?
7. Ignoring existing, universally accepted standards - so you'll cause interoperability issues or be doomed to either reinvent the wheel.
8. Hard-coded values/magic numbers - as a result, any change must be made in code rather than allowing power users to configure their own system.
9. Littering code with global variables - this implies statefulness of code, making it pretty near impossible to predict how a function will behave next time it is called.
10. Being unaware of the "Big O" order of your algorithms, causing code to be unnecessarily inefficient.
11. Strong platform dependency: This can shorten the lifetime of your application to whenever the next platform upgrade takes place, or keep you stuck at the current version of the current platform forever.
12. Thinking you can figure out everything by yourself - In learning by doing, experience can only follow from making mistakes. By getting yourself a mentor or an education, you can actually learn from the mistakes that thousands have made before you.
13. Stopping at 12.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
It's also been my experience that if you see code with Hungarian warts on it, that is a warning that the code you're looking at is going to be poorly designed, poorly written and awful to maintain. Without exception this has been the case in every code base I've ever encountered. There may be a good project out there, but that's a pretty bad track record.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
"Now, please, give me the list of "common mistakes" made by surgeons and aircraft engineers, and compare them with this list of amateurish crap." - by Alex Belits (437) * on Tuesday December 07, @05:57AM (#34471506) Homepage
Back in 1996-1997, I had a programming contract with a MAJOR "eisenhower military industrial complex" company (who shall remain nameless).
Each day during work, I had to go report to a major in the military who was my supervisor right after lunch at noon or thereabouts, to go over code I was writing for them.
In doing so to get to his office, I would have to pass through an aircraft hanger (underground no less & connected to a major airforce base in the south eastern US) where they were making both troop transports, bombers, and jet-fighters, etc..
At the far end of the hanger was a sign that read this:
"DO YOUR BEST WORK, BECAUSE OUR YOUNG MEN & WOMEN'S LIVES RIDE ON IT"
That got to me, as I had a family member currently in the service.
So, one day, I happened to be walking through it with the major at my side who was my supervisor.
First pass through, He noticed that I looked at that sign then... and I did so, again, on the way back when he & I passed back through it to get back to his offices from where I was working.
He, upon noticing I kept staring in the direction of that sign each time we went thru said hanger, asked:
"What do you keep looking at over there in that direction?"
I replied "That sign. I have a younger brother in the armed forces (who is now currently a major himself no less a decade later now) and that sign 'gets to me'"
To which he replied "Ok, 'off the record'?"
I said "Sure, ok..."
To which he stated "Kid, I don't want to 'burst your bubble' but that sign? Is bullshit!"
To which I said "What do you mean?"
To which he finally stated "The reason WHY we have this contract is, we are the 'lowest bidder' & those planes?? They are built like shit!"
To which I asked "Why do you say that?"
He closed it with "Ok - each arch in the airframe is SUPPOSED to have 10 rivets - we only put in 7 - just to save money & make contract budget + to profit!" (or something FAR less than what it was supposed to be by the intended design, etc.)
(This made me also realize that big business does this for profit, and hell with peoples' lives... even those of those who defend us).
Sure, the planes were going to get "torn up" & shot at anyhow, but to make them shabbier than intended, violating the engineering team's init. designs, doesn't help with them being able to TAKE such abuse either... FAR from it, imo @ least!
How would you all like to know this & see it happen, and know that YOUR brother OR sister in the military was riding on aircraft that were built far less structurally sound than they should have been according to their intended design... especially when said planes would be getting into fights in the air?
APK
P.S.=> That's my story in regards to "mistakes" (intentional ones in the NAME OF PROFIT, hell with lives) being made in warfare aircraft of all kinds being made. I hope I didn't offend anyone with it, but there it is! Enjoy... apk
Programming without carefully selecting the solution. I maintain a small measurement control system and before even making the smallest extension i will read and think about the different possibilities in question before typing the first line of code. Then i will try to isolate the new code so that a possibly wrong decision at that stage can be cured quickly.
So lets condense it to: Think hard and try to make the right decision and still assume it will be wrong.
A special corollary of this is to give a malus to all solutions which needlessly bind you a specific implementation.
try maintaining code written by an architect
currently i have a couple of bugs to fix on a system which, functionality wise isnt all that incredibly exciting, however the system was written entirely in a one man sprint by a design-happy architect. The end result is so complex it took him over four hours to explain just the easy half of the project..
People, what a bunch of bastards
Ignoring team dynamics
If you get a software lead that is a primadonna, thinking he knows absolutely everything without listening to anyone including the project lead, customers or his own developers (I've been there), the project is doomed to fail. Doesn't matter what it is, when the team works poorly, the output is crap.
My advice to everyone is if you have a team member that is more of an obstacle than an asset, and everything turns into an argument, then get rid of him as fast as you can.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.
Taking over projects fitting those descriptions is never a good idea. They are nothing but pain, it's impossible to resolve the problems with the app and the code unless you opt for a complete rewrite. If, however, you go that route the remaining developers will be pissed off because they wrote the crappy code and you are basically saying that their ugly baby is ... well ... UGLY! What's worse, you are saying it out loud for everybody including the PHBs to hear. Eventually you end up being frustrated, your PHB either caves in to complaints about you and puts you in your place or you get laid off. Unless, of course, you anticipate this and quit before he gets the chance. There is no substitute for writing code properly and designing and planning your application properly no matter how insignificant the application seems to be because you will never know which piece of shit app will take off and scale into something much, much bigger. Myself, I learned this from a friendly lecture I was given by my boss after I handed in my first project on my very first job. He made me rewrite the thing entirely claiming it was better that I learned the value of things like database abstraction and MVC separation right away. He was right.
Only to idiots, are orders laws.
-- Henning von Tresckow
YES !! It was originally that way. An ART form. Managers FINALLY figured out how to cram programming into a 'form' (cookie cutter), and used all the early idiotic "Design Methods" to corral programmers & designers into lower paying, easily replaceable "jobs". The "systems programmers" at CNA (early 1980s) would wear flannel shirts while everyone else got sent home if not wearing a suit. That kind of power could not go unpunished. (I.E.: we helped in our own demise.)
Or when BAD programmers, think they are good, and label other programmers as BAD. Which one are you?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
coding is a skilled craft, not engineering.. YOur example of bus driving starts ok, but the better comparison is a musician. You can learn the notes on a piano in a few days, but becoming a skilled pianist requires tens of thousands of hours of work. However, knowing music theory doesn't have a lot to do with it (it helps put things in a context, and understand what was written and why, but the actual mechanics of playing don't depend much on theoretical knowledge..)
This is quite different from engineering, where one needs theoretical knowledge to predict what will happen in the future with whatever is being engineered.
Compare a skilled stonemason (traditional craft) with an engineer building a bridge out of stone. Assume further that both are attempting to do something that isn't a copy of what's been done before. Both need some knowledge of material properties, but the stone mason will not be able to *reliably* predict what will happen with the new structure, except if the new structure is very similar to the existing ones. The engineer needs to estimate future loads and uses and perhaps come up with a completely new design with a completely different shape. IT's true that the craftsman does things that can properly be termed engineering, but I think the primary difference is that engineering has a quantitative basis while the craftsman does it on "gut feel" and cannot necessarily articulate the reason why they thing it will succeed or fail. (also bear in mind that many people who are in "craft" occupations, today, are doing engineering.. someone welding up race car frames probably has a good working knowledge of metal properties, etc.)
Use static analyzers when you're done with the "human" aspect of the review.
Use static analyzers before, during and after the "human" aspect of the review.
FTFY.
Number one: ignoring users.
In my dream world, every programmer would be required to spend one day a week working on the help desk, just to get a chance to see what is important to the actual people who use the software.
http://www.geoffreylandis.com
are very important. I work in the embedded field, and it can be quite a pain in the ass to throughly test something without having a set of unit tests. It helps to have a mindset of encapsulating modules or groups of work, and abstract out the platform (at build time) if possible. Then have a set of unit tests that exercise the code that can run on your desktop machine. Doing this lends well to code responsible for doing calculations, that is often bug ridden if not unit tested.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
Just wanted to point out that this doesn't apply in all languages. When dealing with languages where int i; does initialize to a known value, it's unnecessary (though not wrong) to do int i=0;. For example, most languages that aren't C or C++. If you're coding in Java, you know that if you do int i; it will be initialized to 0 for you.
Where you want to advise someone in one direction,
but then on the very next line you warn them not to go too far?
It makes the entire message a little watered down. They're all good points, in various scenarios, but the lesson I learned out of that was to do something in between both of the extremes... which is what I'm doing now. Huh, and here I just thought I was lazy.
I constantly come across many programmers writing code like this in their data layers (c#):
int userId = Int32.Parse(reader["UserID"].ToString())
Even though it is blatantly obvious that UserID is an non-nullable integer primary key.
I guess they don't understand that you can just cast the value to the data type:
int userId = (int) reader["UserID"];
One or two of these wouldn't be so bad, but I see them by the hundreds in many different applications. Converting everything to a string just so it can be parsed back into it's native datatype is a ridiculous use of resources.
I've even seen this with DateTime variables, which is dangerous because you could be dealing with culture info in such a way that you get MM-DD-YYYY one direction and DD-MM-YYYY in the other if you're not careful.
Please - I beg you - understand your data's native type! And don't waste time checking for DBNull unless the field is actually nullable!
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
No it does not. In some languages this will set i to 0 only for the first call of the procedure/subroutine/whatever, not when you call it again. Then i might retain it's exit value.
The only way to be sure is:
int i;
i=0;
I certainly have sympathy for you; I've taken over many code bases which were maintenance nightmares.
But I have to take exception (no pun intended) with your above statement. What you took over was not OOP in any way.
OO is not "do all the same crap but do it using copious amounts of inheritance."
I've seen people do what you describe---using an insane mount of classes---and it's abominable, but please don't pin that on OO. The whole point of OO is to minimize the need for looking through code, by making each class simple and opaque with a well-defined contract, so it can be treated like a black box as much as possible.
Most people who venture into OO just do all sharing of data and/or functionality via inheritance. I blame most CS curricula for this, as CS has taught for many decades that languages are all the same and just impose a few different syntax rules on what should be the same logic. Thus, most CS students see inheritance just another syntactic tool, and they are eager to make excessive use of it so they can feel like they're doing things the "Java way" (or .Net way, etc.).
And to try to be a little on topic: the article is quite correct that Java's new question-mark gimmick (the implicit null check) is one of the worst things to happen to software reliability in the last ten years.
The Internet is full. Go away.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
This is a pet peeve of mine. It's very bad advice to throw in meaningless initializations. If a variable has no meaningful value, you want tools like valgrind to be able to recognize this and catch code that tries to use this value. If you set it to 0, but then don't mean that variable to be read without being set to something else first, you've done yourself a disservice.
I told the boss "I don't write perfect code, and that's why we have testers." That day I was fired. A week later the test lead was laid off.
6 months later the company lost the contract and the manager was laid off...
Best Slashdot Co
I could write articles like this in my sleep. It is vague and schizophrenic. Don't use frameworks that take care of common functionality, but don't reinvent the wheel. Ok? Use syntax that doesn't exist yet. Even better! Now write code that is long enough to get the job done, but not too long. Why didn't I think about that?! Waste of time
UI designed by programmer.
Yes: I'm looking at you, FOSS.
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself.
And output formatting. printf is for wussies. Also, networking; if you can't whip up your own application-tailored TCP stack, then you should go back to playing with VB. And GUI toolkits? TOOLKITS?!? What are you doing, building a footstool? Hell, no! Manly programmers don't use toolkits, they use the library of macros they built while apprenticing to Knuth.
You're completely right. All this mamby-pamby resource management crap is for Kindergartners and Excel users. Real Programmers flip bits with soldering irons, and we like it this way.
Dewey, what part of this looks like authorities should be involved?
Did you just use "irregardless"???
There is one mistake made by experienced (C++) programmers that really bugs me: fear of decisions. Every time this programmer needs to design something, he tries really hard to not place any constraints on the design until it becomes absolutely impossible to create an implementation without doing so. He separates interface from implementation. Then he separates the implementation from the real implementation by some indirect pattern like pimpl. (Heaven forbid that the API user would ever have to recompile!) He places no constraints on parameter values and spends months ensuring that the code handles each one, somehow, even for parameter values that clearly indicate that the caller royally screwed up. He makes all code reusable, even if nobody will ever do so. He writes all his code in templates, just in case the API user might want to write his own string class. He invents his own scripting language (with freeform syntax and comments and God knows what other features) and writes configuration files in it, just so the user could configure every possible variable in the program and to do it in the most ingenuous and convoluted manner.
To top it off, he then takes all of the above and puts it in a library. Never mind that he has never tried to use it with anything but the one little app he is currently writing. Never mind that the library is so bloated that linking to it would triple the memory footprint of OpenOffice. Never mind that nobody in the right mind would even consider using it. But it's OPEN SOURCE, man, so it must be GOOD!
My first job I came across /*Why did I do this?*/ above two pages (when printed out) of uncommented code. Code that started with
if(pow(2,(typeof(int)somenumber){while(something){for{...two pages of stuff}}}
He was, it turned out, checking to see if bits in an int (a 16 bit int) were set in order to control a machine. The machine's physical layout allowed 24 objects, but when the operators set it up for that it went berserk, because the 16 bit int was wrapping...
And no comments explaining what (and more importantly why) he was doing.
Best Slashdot Co
What are the mistakes I should not avoid?
If you use malloc() and free() you throw determinacy out of the window too. Is malloc() going to be a very fast tree search quickly returning an allocation of the right size? Is it going to be a slow tree search through fragmented memory returning an allocation? Is it going to require a system call (and is that going to be mmap() or brk()? Depends on your OS / malloc() implementation)? Is it going to be able to allocate from a thread-local pool or is it going to have to acquire a mutex and (potentially) stall other threads?
In hard realtime systems, dynamic memory allocation is not allowed for exactly these reasons. On most modern systems, the cost of handling a page fault is significantly more than the cost of scanning the nursery in a generational garbage collector, so you may not even get better performance from manual memory management, which requires you to be quite conservative about deallocation.
Good programming is about choosing the right level of abstraction for the problem at hand. Some programs require you to be close to the metal, others are best served by a very high level of abstraction, reducing the amount of code that you right (and, typically therefore, the number of bugs).
Good programmers are lazy, they like to solve a problem once and then forget about it. Saying that you would never use a particular tool is the sign of a terrible programmer - can you imagine a carpenter making the same claim? (I never use a hammer! Real carpenters always use a nail gun!)
I am TheRaven on Soylent News
I wish I could mod this up. There are two types of programmers, those that can take criticism and those who can't. The truly bad programmers don't want to hear it, and don't want to change anything. The other type are willing to listen, but cannot improve on their own; they need oversight to make them productive.
It also does not help when a large number of managers who are hired cannot do, more or less understand how, the work that needs to get done. Usually they don't want to get involved because they are busy in meetings being "productive".
The US should be the leader in IT, instead we want to ignore it because for a management, to get involved is too much like work. Everyone just wants to be paper pusher and makes life for programmers just hell because you can never get solid decisions on anything. If I had to start my career again, I would not get involved in IT; there are too many people who just have no idea what they are their doing and just pass the buck.
UI designed by programmer.
Yes: I'm looking at you, FOSS.
Or my favourite...UI's designed by graphic designers. I used to work with a fantastic designer. He had a real talent for creating visually appealing designs for our web apps that were simple and could be elegantly built with CSS but he insisted on putting menus and buttons in non-standard locations. The result was users had to relearn every interface and hunt for buttons. If we simply had OK, and Close buttons at the bottom right of dialogs, and the menus near the top right our programs would have been easier for new users.
When we migrated to C++ a while back, my biggest gripe became the number of projects, library, et.al. that weren't documented. I won't name the very popular library, but when I contacted the developers (I was still new with C++ at the time), they told me to "read the headers." Your code is not documentation, no matter how well you comment your functions. There's a subculture out there that I don't get that has the mindset that "it was hard to write, it should be hard to use" (and that's almost a direct quote from a library author). I don't know if it's job security, elitism, nepotism, or what. But, with some projects there's a cold disregard (borderline hostility) towards the people who will actually be using the product.
I swear to God...I swear to God! That is NOT how you treat your human!
Forget FOSS. Try Enterprise software. I've never seen more consistently bad and unusable software than anything designed for the "enterprise".
You are in a maze of twisty little passages, all alike.
I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application)
So something like a typical Java library then?
You are in a maze of twisty little passages, all alike.
or he has no idea what programming is. I can guarantee a lot of programmers are not doing "engineering" and most aren't doing "science", but as a whole programming software has a lot in common with those fields.
One of my favorite professors, I had him for calculus, physics, and programming, used to say to solve some of the problems in the classes he taught being creative would be helpful. Sometimes a problem had to be looked at in a different way, coming from a different angle.
Falcon
Should there be a Law?
As a programming noob with only a few years experience I would confess to being an expert coder. But since I've been working I've learnt a lot about software development in the real world...
If youre a programmer - write the spec (as good as you can) and make sure it's accepted by the client. Then build the application and think about what flaws you can add (or not code for) in such a way that it doesn't violate the specification but would potentially cause problems for the end users (like not trapping errors on users inputs). Then you can work out what you can charge to repair it (with the fixed version already saved in your projects) - "Oh this will be 1/2 a day programming, so will cost you £500". Assuimg they just spent more than that on the program, they are going to pay for the fix too!
If your're a client and don't know how to program, make sure you get an EXPERT (someone with a track record) that you CAN trust that is independent of the software company (or the IT department if done internally). They should look out for the pitfalls like with user input and interaction and make sure the different quotes are realistic. The problem is that the client can't normally see or access the code, so will never know how many lines it is, or what the quality of it may be. More you go with a specific company, the more they have you by the knackers.
TFA links to 7 programming languages on the rise, print version.
"I'm going to write this whole thing in Python or Ruby" simply because it's the latest "cool" language.
TFA above has this piece: "There seems to be two sorts of people who love Python [7]: those who hate brackets, and scientists. The former helped create the language by building a version of Perl [8] that is easier to read and not as chock-full of opening and closing brackets as a C descendant."
You should choose the language based on what will best do the job, not based on what's popular today, and you should choose one language for the entire project before you start writing the first line of code.
But what if a project is large and different sections are best written in different languages? With modularity a project can be broken down into different modules then the appropriate language can be used for each module.
Falcon
Should there be a Law?
We've come a long way from when hackers tried reduce the size of programs, however we've lost a lot along the way. Hell, to be a hacker as those in MIT's Tech Model Railroad Club was to be along the best programmers. Now a hacker is someone who's looked at a criminal.
Better checking for null in one common place and let the process fail gracefully than to check for nulls in the multitude of places that call this function.
That's a hacker routine, reducing the number of lines a program takes up. However that's not "fast and loose" programming.
Falcon
Should there be a Law?
Even before you start coding, if the estimate of the effort required is grossly short, you're screwed before you began.
Of course, if everyone produced accurate estimates, the VP would say, "We can't afford to engineer _that_!!", and you'd all be sent packing.
So, everyone turns in overly optimistic estimates to get the folks in charge to say "Yes" to the project, and then you suffer 80-hour weeks until nobody can hide the truth anymore, and heads start rolling anyway.
Which is why I love this line of work so dang much...
f we simply had OK, and Close buttons at the bottom right of dialogs, and the menus near the top right our programs would have been easier for new users.
If you use Windows but not all Linux distros or OSX is laid out the same. Heck, they can even be customized to work the way the users wants them, within certain areas. I use OS X and Ubuntu now but when I used Windows I even rearranged it's layout.
Falcon
Should there be a Law?
Just wanted to point out that this doesn't apply in all languages. When dealing with languages where int i; does initialize to a known value, it's unnecessary (though not wrong) to do int i=0;. For example, most languages that aren't C or C++. If you're coding in Java, you know that if you do int i; it will be initialized to 0 for you.
What you are saying is of course factually correct. However, I disagree with the conclusion that just because a language does something you shouldn't also try to make you intentions as clear as possible.
Any developer worth his salt will program in a variety of languages over his career, with each language having its own semantics, conventions, and quirks. In my opinion, becoming a great developer is about cultivating a certain mindset. A great developer develops bulletproof habits, hard-won conventions learned across all programming languages.
In Java you don't have to initialize variables because the language defines semantics for that situation. It's technically not wrong, and a developer who chooses to recognize this and not initialize their variables is a not necessarily a lazy or bad developer, but it would raise my eyebrow. This leads to developing a bad habit which will bite you when you go to another language with different semantics, and your newly-declared int gets set to whatever trash value was lying around on the stack. It's all about the mindset.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Yeah. And of course compilers nowadays give warnings about it, and initializing a variable hides those.
Thank you, Firefox, for blocking them.
The comments here on Slashdot are far, far more useful than the original article, which I found to be rather trite and derivative ("don't do X. don't do ~X").
What are Mr. Peter Wayner's credentials? Sounds like he hasn't touched a single line of code in his life--even the examples won't compile and don't do the same thing that he says they do.
Try the the above "business logic is embedded in the code" when you're working for a company that is trying to sell a system to another customer. The developers then complain that Project X for customerX should do things the same way as Project Y for customerY did it. When you patiently explain that that's not how customerX do things, the development team then look at you as if you're an idiot. When your customers are government agencies, then you know there is a world of pain ahead for you and the development arm of the company you work for.
I think I've seen one: it was some kind of eDocument management extension for MS Word. It replaced styles among other Word controls, without any hotkeys for the replacements. Users had to click everything.
try maintaining code written by an architect
Isn't that some sort of racism? There are good architects, and there are bad architects.
Programmers, who want to characterize themselves as artists or craftsmen, are just too lazy to put in the engineering time. (Although, they do end up spending more time patching, fixing, and refactoring.) They don't want to document their requirements assumptions, provide adequate design documentation for reuse by other parties, be measured against their peers, and capture lessons learned by others. They tend to point to heavy-handed software management (another seriously delusional bunch) techniques as proof that the aforementioned doesn't work. The software industry as a whole needs a serious wake-up call, which will probably come from the rising amount of litigation, spawned by poor practices. The beauty of art is subjective, but software correctness is subject to scientific measurement.
Time is one of the best teachers. Better than peer review, better than cleaning code. Write your own code then come back and look at it in 3 or 4 years. It becomes pretty obvious how clean the code is, how easy it is to follow or how well it is documented. If you go to college, in the last 3 months you should be required to review, document, and modify software you have written over the past 4 years. I am afraid at the pace crap is thrown at you in school, most would not have time to appreciate the lesson it would teach them.
vi +
As long as you follow PMS Programming standards you are fine. Most depends on you situation, most places don't have the budget to do things the "Best Way"
I love that and have been saying it for years. "All things in moderation, including moderation itself
Falcon
Should there be a Law?
Furthermore, by not initializing variables, you are creating a special case for certain values. You are saying, in effect, "I will initialize variables to the correct value, unless that correct value happens to be [0|''|null]".
But I'd also argue that initialization doesn't have to occur at declaration. Constructors/factories/initializer methods are perfectly valid places for initialization.
Last post!
Use static analyzers when you're done with the "human" aspect of the review. Apply every imaginable quality bar to your code, and only check it in once it has passed scrutiny.
Have to disagree with you there. Every standard that can be codified and automatically evaluated should be done before human evaluation. If it can't pass the automated stuff, why are you wasting my time evaluating code that must be changed prior to check-in anyways?
I'd modify this to say "always, always, always have a peer-review process". Junior devs are prevented from checking in crap because it gets caught by senior devs. The junior devs also learn quality habits from reviewing senior devs' code.
Though not the same when new programmers in school have asked on Slashdot how they can get experience or contribute to open source one bit of advise given is to pick an open source project then take one of the bugs listed as needing to be fixed. Then after a programmer has submitted some bug fixes they may be accepted as a contributor.
Falcon
Should there be a Law?
That's true actually.. the automated stuff should just be part of your post-build process, the guy writing the code gets immediate feedback on completing a build and fixes that crap before asking for a peer review.
You still need to run a build (and post-build verification) as part of a code review, to account for differences (if any) between your dev environments. Ideally there should not be any, but we know how that works. The most time-efficient way (on big projects) is to kick of the build so it can do it's thing, and then the post-build tools can do their thing, while you're reading code.
They need it because it has got electrolytes.
Electrolytes is what they crave.
It's good because it has electrolytes.
-
Did you just use "irregardless"???
Yes. I always liked The Far Side cartoons.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
my rule is: if in doubt, choose C. It's still in heavy use after almost forty years for a reason.
Now I'm working on the book Learn C on the Mac. As I said in another post most of what's taught in college now, and has been for years, is Windows. I need a refresher for C and C++, though I'm thinking of working on Objective C next, and because I'm using a Mac now I thought I'd try that book. Then I want to get a book on C programming on Linux, I have a Linux PC I want to set up as a server and I want to dual-boot my laptop.
You can justify it all you want from a code readability perspective, but the fact remains that it leads to really awkward coding practices, like indenting function bodies sixteen spaces just in case you need to add another nesting level.
I have trouble reading code that isn't indented and nested. Of course I don't read much code and if I did I might get better. Then again there's a lot to be said about readability.
It brings back memories of BASIC and line numbering every ten lines.
I first programmed use line numbers for every line, of course they were numbered 10, 20, 30. I was shocked the first tyme I saw a BASIC listing that was not numbered every line, I thought there was something wrong with the listing.
Falcon
Should there be a Law?
So mega-strongly disagree dude. Not saying you shouldn't do heavy lifting when necessary -- just that you should only do it when necessary. Don't re-invent the wheel every time. Frameworks exist that do work for you for a reason.
This is an interesting problem, I'm not a fan of GC for one particular reason: it only works for memory.
Garbage Collection is non-deterministic; if you open a file for writing in Java, allow the file to go out of scope without closing it then your program has now become non-deterministic, if you try to open the file again then it may or may not work depending on if the object has been GC-ed yet. There are also the user facing problems that programs with GC inevitably have higher peak memory usage (look at all the people that bitch about Firefox if you think memory usage isn't important) and are subject to uncontrolled slow downs (even with incremental non-pausing GC, if you are cranking 100% of all CPUs then the GC will cause user detectable lag — I know, I've been that user more times then I care to remember).
It comes down to valuing determinism (predictability and correctness) over convenience. If I could get a GC-ed language with deterministic object destruction and cheap collection cycles then I'd be all over that but current languages just don't suit my taste.
Requirements != Expectations
Govt must constitute a panel to rewrite US Constitution and Quran
While it's true that you really shouldn't be managing the pointers and memory allocations yourself due to the chance of introducing nasty bugs there is quite a lot to be said for knowing HOW to do so.
Not a sentence!
i think you mean discrimination, last time i checked architects arent a race.
also, this guy is a good architect, and that is the entire problem, he is so caught up in architectural purity and abstractions (and it all makes sense too) that his code has gotten so complex that it is near-impossible to understand without weeks of specific training
People, what a bunch of bastards
Oh, I'd never claim otherwise! It's just that there are precious few times when I've ever actually needed to do that stuff myself for reasons beyond "because the language won't do it for me".
Dewey, what part of this looks like authorities should be involved?
Garbage collection is for little boys.
So, only men create memory leaks?
My #1 mistake to avoid is simply "Not understanding the layer beneath the layer you are programming in." It's nearly impossible to code something right if you don't understand at least the layer immediately beneath the one you are programming in, so you can understand how to use it properly to get your work done, and don't try to (inefficiently) re-implement stuff that is already handled in the layer below.
You see? You see? Your stupid minds! Stupid! Stupid!
So all the millions of changes you make to get the code to pass scrutiny are not properly version controlled; and all the work you do in the meantime is possibly lost if something painful happens to it before it's gets to a "safe to check in" stage? Bollocks to that. Check in frequently to somewhere, just not your stable branch.
Lack of experience is certainly one way it can happen. In other cases, what was once a small simple app finds itself used well beyond it's design life and outside it's design parameters. Somewhere in there it needed a re-factoring at least and probably a re-design to fit it's new larger role, but it gets nixed since it's "good enough for now". Lather, rinse, repeat and suddenly it's a horrible mess.
In still other cases, expectations out of line with reality cause the problem. The app is supposedly going to be HUGE, running on a farm of thousands of servers with a million users each of which will create hundreds of pages. A year later, the 4 page app with 12 users running on the re-purposed desktop machine looks awfully over-designed.
It's even harder to get the OK to pare a program down to an appropriate scale. The natural evolution then is that more and more additions bypass large segments of it until it becomes the little program struggling to get out of the big pile of baggage all around it.
Not re-using code.
Govt must constitute a panel to rewrite US Constitution and Quran
Use static analyzers when you're done with the "human" aspect of the review
No do it before, you will save everyone time
Jehovah be praised, Oracle was not selected
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself.
If you are a programmer, CODE IN ASSEMBL.... no sorry CODE IN MACHINE CODE!
they won't have to scale and extend the way they think they might
Wow, talk about short sighted.
Good design is important for maintainability and scalability, yes. But it's *FAR MORE* important for testability.
Abstract classes, interfaces, etc, encourage loose coupling between code, and *that* leads to code that's unit testable. It *also* happens to produce code that's generally modular, extensible, and easily refactored. But that's just a pleasant side-effect.
In short, simple is good. Simplistic is not.
When you work it all the way down, most code issues are about the money. Companies sell code to make money. They want to pay as little as possible to produce it. And make as much as possible from it. Bad coders, ignorant coders, lack of testers, bad testers, ignorant managers, lack of processes -- all of it. Bad coders have jobs because companies only want to pay so little that only bad coders take the money. Ignorant coders of course are paid little. Testers cost money -- so hire as few as possible or have the bad ignorant coders test their own code. Hire/keep potted plants as managers because they are cheap. Take the money and run. Ultimately this is the root cause of it all. And it will never change. This is the way it was 30 years ago. This is the way it is today. This is the way it will be 30 years from now.