“No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry. Bad software, or bad anything, happens because making things is hard, making good things doubly so.”
Lazy programmers write bad code.
– If’s require elses.
– Error handling needs to be designed and written.
– Short cut programmers write bad code.
You mean ctrl-c and ctrl-v aren’t citizens of “Good Design”?
Heretic!
(I totally agree. I see someone use copy/paste while coding and my immediate reaction is a strong desire to club them over the head.)
No one who uses your code cares, at all, how many dnagling if’s you have or how brilliant your error handling is or how many shortcuts you took. They don’t care if you wrote bad code or good code. They only care if they like your product. Nothng of what you’ve mentioned has naything to do with how people react to your product.
I’m sorry but reality is that is exactly why your customers will be suing you, what you’re writing is shelfware. The three most, nay the only things that matter in software are performance, performance and performance. You don’t get it by doing a crappy job on the code. How your product is written is how it performs is how people react to your product. It’s all connected in the grand cycle of development.
Performance is far from everything. Things like useability and features are far more important in many programs. If a program is a pain to use and doesn’t have the features I need at the quality I expect I don’t care how fast it is. You can have the most beautiful code in the world and still produce a program no one will want to use.
You are describing an application user interface of poor performance, all facets of the application must perform equally well, I stand by the rule.
Not just lazy programmers. Egotistical programmers who can’t admit they lack the mental ability to formulate good code on the fly. These are the people who will go off about how important logic and mathemtics are, but when asked to complete a complex task they fall sort.
Lazy programmers write bad code.
wrong. bad programmers write bad code. lazy programmers will write code which is difficult to maintain, but often does borderline miracules things. the woz would be a great example.
– If’s require elses.
wrong. ifs need elses only when they fit the logic of what you are trying to do. sometimes they need else ifs. sometimes they dont. if you believe every if needs an else, you are probably one of those coders who write bad code.
– Error handling needs to be designed and written.
partially wrong. virtually every modern language has a built in way to do error handling. rolling your own is redundant, and more prone to errors itself, therefor is a Bad Thing. you are only right if you are referring to older stuff.
– Short cut programmers write bad code.
this is a reiteration of your first point, and just as wrong. hackers could fall under “shortcut programmers”, and hackers are the only ones who innovate in the industry. they treat code as a language rather then a formula. sometimes it takes work to understand, but more often then not their code is insanely better then what i usually refer to as “drones”, who do everything the long way.
> the woz would be a great example
It would be difficult to characterize Wozniak as lazy. Between the two of you, you both manage to define who writes bad code baselessly and then disagree with each other about whose axioms are more worthless.
> partially wrong. virtually every modern language has
> a built in way to do error handling.
If you think having exceptions negates the need to design for the handling of errors, then I seriously doubt your development experience. Whatever means you have of dealing with erroneous behavior (return codes, continuations, flying zebras) you need to design around dealing with exceptional conditions. Where will conditions be propogated to? How will they be handled? What should really be done when you can’t secure a limited resource like memory or a graphics context?
If your idea of error handling is letting an exception just terminate your program, then your software is probably crap.
> hackers could fall under “shortcut programmers”, and
> hackers are the only ones who innovate in the
> industry.
Paul Graham called and said that he wanted his self-delusion back.
It would be difficult to characterize Wozniak as lazy. Between the two of you, you both manage to define who writes bad code baselessly and then disagree with each other about whose axioms are more worthless.
if he doesnt now, that was the reason he alwas gave for designing boards with very few chips, because sodering was a pain and he was lazy.
If your idea of error handling is letting an exception just terminate your program, then your software is probably crap.
there is a far cry between not catching exceptions, and designing and writing error handling. its already designed and written in most modern languages, all you need to do is use it.
Paul Graham called and said that he wanted his self-delusion back.
Paul Graham was one of the spearheads of the .com boom. Paul Graham was the guy who came up with the idea of using bayesian filtering for spam, which is pretty much the only thing that has remotely worked so far. Paul Graham is one of the innovators I was talking about.
“Lazy programmers write bad code.”
Then they’re not lazy enough. Really lazy programmers realize that bad code generates lots of headaches over a long period of time and tries to avoid that. 🙂
I agree with the rest.
Lazy programmers write bad code.
That’s wrong. Lazy programmers write:
* Simpler code, which therefore is more easily maintained
* Do not like complexity because they don’t want to think, which keeps things simple
* follow the DRY (don’t repeat yourself) principle, to keep things simple
Oh, and did I mention that simplicity is usually the most important aspect of software?
Lazy programmers write bad code.
That’s wrong. Lazy programmers write:
* Simpler code, which therefore is more easily maintained
* Do not like complexity because they don’t want to think, which keeps things simple
* follow the DRY (don’t repeat yourself) principle, to keep things simple
Oh, and did I mention that simplicity is usually the most important aspect of software?
There’s NO SUCH THING as SIMPLE software.
Only the TRUE path thru the code is simple.
The real work is in the ELSE CONDITIONS and the error handling. This is where the bad programmers fall down on their ass.
To simplify: If you’ve never coded an Exception in C# you should reconsider that management job at Denny’s.
print “Hello, World.”;
I’d add.
– a value returned is a value checked.
– great programming requires great discipline.
– there are no short cuts but a proper design will almost code itself.
Good code is EXPENSIVE as it’s DIFFICULT to write.
And as long as good code is so expensive, don’t expect commercial/home-oriented software to ever be “good”. This is true for both OSS and commercial software. If you really need perfect quality, I suggest you ask NASA and nuclear plants to give you some references of software houses that might will fix things for you, given a few million dollars. More here: http://www.livejournal.com/users/jbq/91727.html
Now now, Eugenia
This wasn’t what was meant with good code.
> Good code is EXPENSIVE as it’s DIFFICULT to write.
Bad code is way more expensive and difficult if you have to maintain or reuse it.
> Bad code is way more expensive and difficult if you have to maintain or reuse it.
Good code costs you money/time/resources at the time it is originally created: bad code may appear to be cheap at the beginning, but it’s much like a plague that starts out small, and the resources required to fix the problems as a result end up being much more than the cost of doing it properly the first time, and keeps on giving in that way.
If your product(s) start out notably bad, but are otherwise on time to market, your reputation is likely to be blown to hell, such that the seemingly low-cost of the initial implementation ends up being no bargain, because you may never be able to convince people after that that the product(s) in question are worth spending their time and money on in the future, while some other solution that may have taken longer initially to get to market can come in and swoop up potential customers.
The cliche of you never get a second chance to make a first impression applies too often.
I agree. See my longer comments above.
Bah! bad code is expensive, lawsuits, lost customers,poor reputation, bankruptcy, dreams crushed.
It’s real easy to do good code right if you’ve got the skill, discipline and focus. If it’s too difficult then maybe a career change should be considered before too much damage is done. Project management may be a better fit. Not everybody has what it takes to be a programmer no matter what the latest fad language groupies decree.
The article suggests up front that sucking software is the result of low skill on the part of programmers and designers. Computer software is a weird market, and it breeds major violations of this idea. I can think of three major types, two perpetrated or caused mainly by Microsoft.
One is that software that annoys and bedevils the user is created in order to sell upgrades later, or to segment the market by selling a low-quality version of the same software. Examples of this include every version of Windows. “This version is REALLY secure! REALLY!”
The second example is that, since Microsoft is directly or indirectly competing with just about every programmer on the planet, they inflict constant sorrows on us to keep us busy. Read “Fire and Motion” by Joel Spolsky for the general principle. Does anyone really believe that Microsoft just couldn’t fix IE6 for five years?
A third cause, unrelated to Microsoft, is that PHB types decide they need to Step In And Decide Something, and their decision sucks. Again, I suggest reading “Two Worlds” by Joel. This happens all the time. Whenever you’re using a piece of otherwise great software, and you run into some feature of the software that makes you scream “WHAT THE HELL, WHY WHY WHY” that’s probably the result of a bungling manager. It really happens. I’ve seen it.
Marketing kicking stuff out the door way too soon has to be the lead cause, very insightful of you to point that out. Not too many bad programmers last long enough on the job to do any where near the damage of bad marketing.
Good Code takes programmers that care. To many coders think that anything they develop should be fawned over by the masses. How many times have you heard “if you don’t like it – learn to program and do it yourself”. No other industry puts up with such bullshit ego attitude. Dentists, Farmers, Airline pilots, and thousands of other professions all have skills that programmers don’t – yet do they tell everyone to “learn how to do it themselves”?. If you’re going to do something, do it well, or not at all. That’s a truism no matter what the task.
“Benevolent”? Malevolent?
From Google’s ‘define [term]’ searches:
Definitions of benevolent on the Web:
intending or showing kindness; “a benevolent society”
charitable: showing or motivated by sympathy and understanding and generosity; “was charitable in his opinions of others”; “kindly criticism”; “a kindly act”; “sympathetic words”; “a large-hearted mentor”
generous in providing aid to others
beneficent: generous in assistance to the poor; “a benevolent contributor”; “eleemosynary relief”; “philanthropic contributions”
wordnet.princeton.edu/perl/webwn
the performance index of social man; the capacity to obtain happiness through the happiness of others vs egoistic happiness obtained at the expense of others by sociopaths.
http://www.corebooksweb.com/definitions.htm
Definitions of malevolent on the Web:
wishing or appearing to wish evil to others; arising from intense ill will or hatred; “a gossipy malevolent old woman”; “failure made him malevolent toward those who were successful”
malefic: having or exerting a malignant influence; “malevolent stars”; “a malefic force”
wordnet.princeton.edu/perl/webwn
A malevolent spirit is one that wishes to do harm.
laurelparanromal.tripod.com/id13.html
On another note: the reply preview doesn’t work in Konqueror
Without looking up definitions, I would say:
Benevolent = kindly, giving
Malevolent = Evil, cruel
…is easy to write, when you remember the rules.
Always remember to have a running dialogue with your customers.
When you don’t you’ll end up with a screwed up system like the one, the danish police got. Completely unusable and a good laugh in the rest of the industry.
This article is GOLD.
Woot… how did that post get modded down?
Unless somebody has a thing against me?
I modded you back up, since folks obviously don’t read the “are you sure you want to mod that post down” info.
NOTE: This feature is to report comments that are offensive, inflammatory, off topic, or otherwise in violation of the OSNews forum rules detailed on this page.
Please do not use this feature to vote down comments that you merely disagree with, or even ones that contain factual errors or misinformation. Rather, use the reply feature and enlighten us all with your opinion or correct facts
Please read the rules people.
The clear specification, you have got to work from a clear spec. Can’t hit it if you don’t know what the target is. Not too many programmers are very good at reading the customers mind. Clairvoyance while a desirable trait is rarely seen on a resume.
I would contend that people have written bad code on purpose.
Have a look at this if you don’t believe me: http://perversiontracker.com/archives/000438.html
I would draw, perhaps selfishly, attention to: http://ghostlords.com/mole/
*LOOOOOOOOOOOOOOOOL*
The best link ever posted!
I believe certain developers on the Mac platform have to much spare time, or are just mentally retarded…
The best one was the ‘seamon’ remark
I believe certain developers on the Mac platform have to much spare time
Believe me, writing iWhackEm did not take me very long.
The best one was the ‘seamon’ remark
Thanks. Because that wasn’t annoying enough back when I was in middle school.
why are there nothing but mac apps in the perversion tracker thingie?
Bad mac software is the focus of that site, I’m afraid. They did once review IE 6, but only because it couldn’t render their page at all correctly.
Just remember it in case you ever have access to a mac. Some of the stuff there is really hilarious.
Computer systems are a huge stress factor in my life. They suck pretty badly overall. I think this is why:
* Generally, the problem is not bad code but rather the lack of overall design. There are too many technologies and designs patched together in contemporary software systems.
* We need more well documented interoperable standards and less outdated proprietary software. Software should be designed so it can easily be adapted to the constantly evolving platforms (old cruft can then be thrown out easier.) Software must follow standards.
* Software makers must pay more attention to usability expertise. Software needs to be more intuitive. Abstractions must be solid so they don’t constantly leak and bother users.
Exactly!
Without the right tools, a good requirements spec, unit tests, acceptance tests, usability tests, smoke tests, a daily or continuous build, revision control, a change control plan, defect tracking software, code reviews, well-defined milestones, and a reasonable budget and timeline, I’m sure that writing good software would be very difficult.
Without the right tools, a good requirements spec, unit tests, acceptance tests, usability tests, smoke tests, a daily or continuous build, revision control, a change control plan, defect tracking software, code reviews, well-defined milestones, and a reasonable budget and timeline, I’m sure that writing good software would be very difficult.
It is indeed. My company has treated me (personally) extremely well. The biggest stress I have has been due to schedules that Development has to meet but has no input into. For example:
– I’ve added features days before official GM, and sent out products and updates with no testing AT ALL beyond a quick run through on my development machine.
– It’s no joke to say that I spend more time on exotic new UI elements some suit envisions than on the functionality they control.
– I’ve had a salesman promise a product he’d never seen to a big account, say he’d have it for them in a month, then call and tell us the good news. This is where our schedules usually come from.
Of the list above, we do have decent tools, revision control, we do continuous builds, and Code Reviews (when debugging something somebody else wrote.) So far we’ve been very lucky with our products being reasonably stable once they hit market (never mind who this is or what we make, but if you’ve been in your local electronic retailer in the last few years, etc, you’ve probably seen it.)
Welcome to the real world!
You can have all that, and the code can still be badly written for historically reason. (spaghetti code)
All that will help you to have a pretty solid codebase but not necesseraly good code.
Good code is not expensive or difficult to write. Good code is time consuming to write. Writing software against every possible known bug to man is possible. But is it practical? Designing the most optimal and accurate algorithm, data structure or interface is possible. But is it practical?
The response differs from person to person. A business that needs to meet a deadline will most likely respond in the negative. A research team designing nuclear software will tell you they have no other choice.
Things get worse, because programmers are generally lazy by nature. They won’t be programmers if they weren’t.
“Good code is not expensive or difficult to write.”
time = money
Saying something “sucks” doesn’t help much though. Most commercial software sucks as well. But a commercial developer hears people saying their software sucks and they think about the money they might lose. So in that sense maybe it can work to publicly rant. An open source developer it may only frustrate by the lack of specific or constructive comments, esp. when the critics blame the “mentality” of open source developers.
There are better ways to understand usability and improve usability. Like have some actual data and specific suggestions, and/or code it yourself if you can. Instead of only focusing on “educating” the software designers, we should focus on educating the users as well.
The pervasive attitude in software engineering is “I’ll just hack this together”. This is the mental root cause of bad software. It is especially prevalent in OSS, where hacks are cool, but it is the dominant attitude in the commercial world, too.
I’ve done it. You’ve done it. And the software sucks because of it.
Yep.
I’m guilty. I’ve been guilty, and as long as I’m working for “the man” I’m stuck in an environment where I’ll continue to -have- to be guilty just to keep on target with schedules.
Quality means very little to most people, so long as it can work.
While I personally cannot stand that attitude, it’s the prevailing one in the IT industry and corporate world. No one builds anything to last. Planned obsolescense, upgrade versions, cyclic design, never-ending profit centers by forced upgrades.
No manager, CIO, owner, etc. actually WANTS to fix it. They loose their money if they do. It’s horrible. No one has any moral character or ethical behavior. Good software could be written, and cheaply. It’s a matter of people exacerbating the problem for profit.
Hey, what are you doing, reading and posting on here, when you should be working on the BeOS Java port!
Let me see: you aren’t getting paid for the port, and you only have anxious users waiting for it, but they aren’t paying for it, and haven’t set a fixed deadline (beyond “ASAP”) so, does that mean you won’t cut corners?
The meaning of hack in the FOSS world can have a different meaning. It can mean the work done by a hacker, a hacker being one respected by his peers for his work (according to ESR, to be a “hacker” another “hacker” must refer to you as a “hacker”, a sign of respect).
Now, the noun, a hack, is something that extends the believed possible behaviour of something. Which is indeed cool, and rarely considered something permanent.
I think a lot of the problem lies in both sides trying to push for too much new stuff too fast. We need to sit back and say “ok, how can we make this better instead of cooler.” But that’s expensive for the commercial world, and it doesn’t please 90% of the users in the FOSS world (except maybe for Apache/MySQL/PHP/Python and other projects where users depend on the dependability a great deal).
The reality is that software development is a creative activity whos difficulty depends not only on the complexity of the problem domain, but also on the skills and experience of the programmer(s). Anytime people are involved, you are dealing with a bell curve of maturity and ability. Not everyone is in the 90th percentile. Half the programmers suck (at least more that the other half). When you indiscriminantly put programmers together into teams, you either amplify bad things or neutralize good ones – it is hard to win.
So is all hope lost? For those who are interested in improving their professional skills, no. And the rest don’t matter because they probably aren’t reading this comment thread anyway. There are organizations out there that are trying to improve the quality of software. The Software Engineering Institute (SEI) at Carnegie Mellon University comes to mind – sei.cmu.edu. The Software Capability Maturity Model and the work on personal and team software processes is interesting. Then again, on the other side of the spectrum, the agile development world has interesting things to offer.
Good programmers need to learn more than languages and frameworks – a little professional knowledge goes a long way. But the software development profession is young compared to others. In many ways, it is a chaotic, personality-driven domain. With time, best practices, ethics and community self-regulation will carve out a lowest-common denominator that doesn’t suck as hard. These are interesting times.
Just speaking from my experience, the problems are usually that programmers are rushed to get an application out the door. That causes the programmers to find shortcuts in order to meet that deadline. That then cuts the time for the analyst to hammer at the code and ensure that it’s working properly.
bad software results from (1) bad management, (2) bad developers.
in my experience, too many “developers” get jobs without proper qualifications – often they are hobbyist geeks who think they can code – sure they can code, but not design. some of the horrors i have seen …
i have worked at a nuclear power plant – and they coded everything in fortran 77 – nothing newer because they lacked the oomph to look into alternatives. the error-prone language led – yes, to errors. then some bright spark did what all bright sparks do – contract out the work – and the contractors had no background in physics, maths or chemistry – and they coded in unmaintainable C – with the gravitational constant g==0.
in my experience – the vast majority of bad software is as a result of clueless management.
oh my god everyone is always bitching about something aren’t they!
bitching bitching and more bitching
I swear the software geek community has more whinners than any other tech community
No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry.
Viruses?
The key word here is “benevolent”.
Actually, well written virus’s are very good software. The quality of ‘good’ has nothing to do with the morality of the programs output, it has to do with the efficiency and reliability that it does it (including human-machine interaction efficiency and reliability).
Successful worms are extremely good programs in that sense.
Now that, after years of “brainwashing” by irresponsible software companies, everybody is used to buggy (if not crappy) software, most companies do not care about delivering reliable products anymore. Most users will not know if the run-time errors they encounter come from the applications, their hardware or their operating system anyway…
It is just about time to market and eye-candy GUIs… Engineers must feel like craftsmen working in factories.
Ding ding ding, what do we have for him Jonny?!
I still think people are too hard on software. This talk of “using the tool instead of working” is stupid. Ever met a carpenter who “does his work and doesn’t think about the tool?” Did he have 10 fingers, no. Oh, this isn’t dangerous work you say? Neither is carpentry, you’re probably more likely to die as a semi-truck driver!
The tool must receive some thought, from the user too. Otherwise, why can’t the user do it without the tool? At some point he gets used to the tool, but still. The more powerful it is (read: the more useful it is), the more a small mistake can screw things up royally. And if a program can predict every mistake possible, well it should be able to do the work without interaction!
Successful software is not the result of following good engineering practices. Successful software results from paying attention to what people want, not what you think they need. Good coding and ddesign practices help you, but your customers have no reason to care. They judge you by your deliverable, and they don’t care how you got there.
Commercial software has the advantage of the obvious feedback loop provided by sales. Not enough sales? Poof, you’re gone. No one will care if you wrote good code or bad code. Commercial vendors don’t have the luxury of blaming their unpopular products on their customers.
FOSS coders, of course, have no real feedback loop with their customers, and can continue blithely working on software that the world ignores.
I think one big advantage of FOSS is just the contrary: very often you can e-mail the authors and tell them “THAT doesn’t work for me”. They could fix it or not, but communication IS possible. It’s more and more difficult as the project is bigger: projects like KDE, Gnome, big commertial distributions like Fedora, SUSE… are less likely to listen to you. So… Think about software giants like Microsoft.
I’m not very sure sales are a good way of knowing if something works well or how to improve it. Sadly, too often marketing is more powerful that quality. Not always the best product is the more successful.
Equally for FOSS and commertial software, communication is ALWAYS important
Non-programmers complain about sucky code and ego maniac programmers will call other programmers not fit for the job. Yeah, there is some bad code out there, but we should be thankful for the programs we have. Most programmers aren’t trying to write bugs on purpose.
The problem with software development of any kind is the environment. In a changing environment, software is put to the test. Planning what can happen and what does happen can be totally different. I was on one job where we had users come in a test a peiice of software. They used it in ways that didn’t dawn on any of us. Programmers will never think exactly like regular users. Also, the environment can be anything. A downed server, and overloaded server, a hung os, a corrupt file, etc.
So quit your crying and find something more productive to do. 😉
Software dev is very hard. Writing good code is very hard. In my software dev class I found that out first hand. I found out because of my desire to finish and because no one in my team was of any use that I was taking horrible shortcuts and not using any of the benefits of OOP. It was a rather huge wakeup call for me. There are tiny things in the process of writing good code that are quite hard to keep track off or keep in line…your teammates attitudes…their coding style, etc etc…it is not just code writing but it is communication amongst the team and the environment as well that will dictate how good code is written.
I read that Nasa has like 1 bug per 100k lines of code or something like that. There is a reason why because every line of code they right, they make sure no bug has been added and they prob produce 5 lines of production code a day.
Software that home users use dont demand insanely high quality like that to keep prices down.
You should read Brooke’s book. I think you’ll find his team suggestions fall in line as a solution to your team problems.
In his about page:
Scott was a program manager at Microsoft Corporation for many years (1994-2003). He worked on Internet Explorer 1.0 thru 5.0, …
Am I the only one who finds it ironic that this guy is takling about software quality?
> Am I the only one who finds it ironic that this guy is takling about software quality?
Probably.
Maintaining such a beast (based on quite a lot of legacy code, IIRC) is not exactly an easy job, you know. IE is obviously far from perfect, but I am pretty sure it could have been *much* worse.
Yea, they could have spent a year on it and then had to start from scratch
.
It wasn’t that bad, but it certainly wasn’t at the level of usability it could have been. I think most of the IE complaints fall with the time after he left, 5.5/6.0. Have they fixed that address bar bug yet, where it clears what you just typed to put in the current address?
It’s pretty ironic yeah
But the same could be said about other persons and other projects.
I’m sure several developers has been frustrated with IE.
XP SP3 Preview Package a Fake
Microsoft Says ‘Maybe’ to OpenDocument
Microsoft Windows Vista Build 5231 Review
Interview: Bill Gates
and now this, all within 3 days.
i just had to code a project in java, although there are lots of libraries and helper classes, the language itself is too simple in that half the time you’re wrestling with the capabilities of the libraries as opposed to focusing on solving the problem. they need higher level languages, like 10 GL.
here’s an example, you want to create a webpage, you can construct code from a text editor, or you can use an environment such as dreamweaver that will give you what you need with drag and drop capability.
another example is a content management system. you pick the template, you pick what features you want and you get a full blown system with database, layout, etc in minutes.
i know there are some uml tools that allow you to model problems and then have that translate to skeleton code, but i’m talking about more enhanced code.
i guess we perhaps need ligher level libraries that do a very specific task. simplify my code size, put more things in libraries.
This guy reads too much Douglas Adams, two paragraphs in and he’s made the “doubly” reference and a reference to a man at a dinner.
Ok, now where he’s wrong:
“Creators, often sensitive about their work, may respond by rejecting the very people they were supposed to be designing for, starting the ugly downward spiral of resentment and passive aggressiveness between creators and consumers, which can end only with one result: software that sucks.”
The instantiator in this instance is clearly the user, the creator is simply reacting. The blame clearly lies with the ungrateful individual who with no care insulted the benevolent creator. Unless, of course, the user exchanged something valuable for said service, in which cause he wasn’t receiving what he was promised; then it’s the creators fault for promising what he wasn’t delivering. Or, more likely, marketing’s fault.
SOFTWARE ENGINEERING GLOSSARY or DEFINING COMPUTER TERMS FROM A MARKETING POINT OF VIEW
ALL NEW — The software is not compatible with previous versions.
ADVANCED DESIGN — Upper management doesn t understand it.
BREAKTHROUGH — It nearly booted on the first try.
NEW — It comes in different colors from the previous version.
DESIGN SIMPLICITY — It was developed on a shoe-string budget.
EXCLUSIVE — We re the only ones who have the documentation.
FIELD TESTED — Manufacturing doesn t have a test system.
FOOLPROOF OPERATION — All parameters are hard coded.
FUTURISTIC — It only runs on the next-generation supercomputer.
HIGH ACCURACY — All the directories compare.
IT S HERE AT LAST — We ve released a 26-week project in 48 weeks.
MAINTENANCE FREE — It s impossible to fix.
MEETS QUALITY STANDARDS — It compiles without errors.
PERFORMANCE PROVEN — It works through beta test.
REVOLUTIONARY — The disk drives go round and round.
SATISFACTION GUARANTEED — We ll send you another copy if it fails.
STOCK ITEM — We shipped it once before, and we can do it again, probably.
UNMATCHED — It s almost as good as the competition.
UNPRECEDENTED PERFORMANCE — Nothing ever ran this slow before.
YEARS OF DEVELOPMENT — We finally got one to work.
Someone here posted about Dreamweaver and requirement of better languages than Java and C++. I agree to a certain point but you cannot blame it all on the language. Whenever you approach a programming project I think that one should see the whole picture first, and break it into several components and then identify the tools required for writing the components. If you use an IDE then great your life will be a lot easier.
After identifying the components of the project then you will need to look for the APIs that you will use and Java has a crapload of those already in the Standard Kit.
It is all about following the OOP rules strictly, by learning the knitty gritty of the language, by knowing how the compiler for that language would work, tradeoffs and so on. We as programmers have to think constantly of how to balance the whole situation out. I hope that makes sense what i am trying to say.
Since software is a manmade construct of something that is absolutely abstract and artificial, it is not going to be perfect. And add to that fact that not everyone is a great programmer and of course you will get bad software code all around. Software is not easy to write and develop.
I’d argue that an IDE, verse a non-integrated development environment, makes absolutely no difference and can end up being a hindrance as much as a help. But, using all the tools available too you, that is what you do need.
I’d say language makes little difference. The end-decision is going to be based more on what libraries are available in a given language. Don’t get me wrong, I’d much rather write something in Python over C; but I think the benefit the language gives you is fairly small. In c, you fight with memory issues that are hard to find. In Python, you fight with bugs that only happen at certain run-times (bugs which would be caught by a compiler in a strongly typed language).
I think quality control is important in every language you use, and it’s going to cost significant time at the end.
I can write something a lot faster in Python than c, but I’m still gonna need to fully test and improve the python code for performance when I’m done anyway.
i don’t think divide and conquer necessarily solves the problem. i’m talking about higher level problems. you’re so focused on OOP and the intracacies of OOP that you forget the real problem that you’re trying to solve. let’s say you want to write a document management/workflow engine. you could probably find several libraries/components to help you get to your end goal. but how much glue code must you write to utilize all these disparate parts?? and how much is missing in terms functionality that you have to build yourself?
how long does it take?
WE NEED 10th GENERATION LANGUAGES (10 GL)
Cocoa is not bad, i think interface builder makes it more like a 5 GL but not a 10 GL. I wrote a text editor in about 20 minutes. the text field with a scroll pane that handles glyphs, fonts, and spell checking was available immediately. drag and drop. interface builder allows you connect things without writing a lick of code.
the only problem is now i want to add line numbers and syntax highlighting. i must code my own package from the ground up.
the base cocoa language only gives you functionality like data structures, very simple gui components. we need more components, pre-fabricated and available.
we’re focusing too much on the nuances of each language that we’re unable to do big things very quickly and easily. that’s almost like job security.
it is the language that is the problem. just like verbal language has not necessarily evolved. for very complex problems, it’s sometimes hard to express things easily in say English. if we improved our languages, both programming and speaking, we’d be able to evolve to the next level as humans. mathematics is an evolved language. computer science is an evolved language, however, we’re still programming with technology from 20 years ago, OOP isn’t new. functions, classes, inheritence, it’s all the same as it ever was. we need more.
First off, I would like to say that it is insanely difficult to write “good code” in a corporate environment. typically, you have one shot at doing something the Right Way. After that, it is QAd, bugs are fixed, and the chance at a rewrite is next to nothing, unless you manage to convince your manager the world will come to an end if he doesnt let you fix it properly.
As for tools, I would say that a good IDE can make a significant difference. Also, a good IDE is rare, and usually quite expensive. With a good IDE (i.e. real time syntax checking, good customizable code templating/generation, refactoring tools, full featured debugger, compiler/integrated deployment tools) both your productivity and code quality will increase. Nothing can help with logic issues, but not having to deal with more mundane problems will free up your mind, letting you concentrate on the stuff that matters. Time for a manditory IDE of Choice plug, after using intelliJs IDEa for two years, i can say that i never have syntax errors, can rapidly generate “plumbing” classes and methods with a few keystrokes, and can quickly and easily refactor the entire codebase.
last but not least, it is very rarely “lazy programmers”, and more often “moronic management” that is the cause of bad code. i cant count the amount of times when something has been sold before it was finished, and massive amounts of work had to be done in a rediculesly short amount of time to deliver what we were legally obligated to deliver. this is rather normal. you tell them “this is bad, it needs to be fixed.” they tell you “it offers visible improvement to the clients, and it will take time out of the already tight project plan for things which will offer visible improvements and allow us to sell more copies” you say “this is bad, and we will pay for it later” they ignore you. five months down the line, all hell breaks loose, and the same team that warned management of the problem pulls 18 hour days desperately trying to patch it up so the company doesnt get sued. does that make them lazy? if anything, programmers are the only ones in a software house actually trying to put out something of quality.
users have no clue what goes into software, and what motivates commercial software development. students have no idea whatsoever of what its like to actually work in the industry. and yet both are being quite vocal in this thread, and extremely insulting. if anyone wants to know why programmers are often hostile to users, just look at some of the attitudes expressed here by people who (by their definition) have no clue what they are talking about.
I think articles like this make software suck.
All the idiot coders who need to realize this, the advice will wash off of. A lot of intermediate coders will take it to heart and dumb down their UI to the help of no one (GNOME). And anyone making good code will go on being their innovative selves and make code thats malleable enough and good enough so that if there is a need or want by some niche, someone else can come along and reshape the app to scratch that itch.
This is one of the better articles of this vein that I’ve read, but I’m altogether sick and done with this much overaught brand of UI centric thinking. Your UI can be no better than your underlying data model, no matter what. If you want better apps, write a better core system. Give developers and users better ways to script and modify your program. There’s a couple cases where people build really good programs and staple shitty UI’s on top, but for the most part I’d wager that crap UI is merely symptomatic of an already shite program.
OSS is not going to win SHIT by having prettier desktops and by out-friendlying MS/Apple.. MS has already won if we’ve decided to try to beat them at their own games. We’re goign to win by technocratic superiority, innovation and ultimately through trickle down. Give the people setting up systems more reason to install, the masses will adapt as they are required. What is most important, give developers more reason to become a part of the community. OSS is still building inertia, an inertia which revolves entirely around technical innovation.
OSS is not going to win SHIT by having prettier desktops and by out-friendlying MS/Apple.. MS has already won if we’ve decided to try to beat them at their own games. We’re goign to win by technocratic superiority, innovation and ultimately through trickle down. Give the people setting up systems more reason to install, the masses will adapt as they are required. What is most important, give developers more reason to become a part of the community. OSS is still building inertia, an inertia which revolves entirely around technical innovation.
not even going to BOTHER with the first part.
we already have technological superiority. i believe you are comparing linux to windows, which is probably one of the least interesting operating systems in use at the moment. if you want interesting, look at solaris. hell, look at plan9. windows isnt even on the map.
we have already won, the goal of oss is to write good software, and we have a great environment at this point in time, so great its really shaking things up for the other guys. the masses are completely and totally irrelivent. the only people who believe that the purpose of linux is to defeat microsoft in some epic battle between good and evil are fanbois.
once again, just so everyone gets it. the grand, overall goal of oss has NOTHING to do with microsoft, the masses, or anything other then writing good software. individual projects may have their own goals, but pretty much anything that is any good is written with the purpose of being a something that doesnt suck, rather then being an alternative to something.
…and I will tell you that the best code I ever wrote was for DEC because we had rules to follow. Coding standards, review processes in place, documentation throughout the life cycle, etc.
Every where else I have been they have tried to do it. Not with a ton of success. But these new trends… I just don’t know. I guess I am old fashioned where I believe 90% of the code is written in the requirements and the functional specification before the actual coding ever begins. By that, I mean the requirements have to be good, the functional design has to be good, THEN the basic functional test plan should be in place and THEN begin with the design specifications.
But these days it goes like this: You have 2 months to do X Y Z. Now get to it and DO IT RIGHT! Well, the battle is already lost at this point. Software engineers are no longer allowed to “engineer”. That’s why we are all becoming “programmers” and “developers”.
🙁
And when I say “90% of the code is already written” I meant it figuratively. It is done on paper or in your head because if you have all the data and the processes defined well, that is more than half the battle.
> …and I will tell you that the best code I ever wrote was for DEC because we had rules to follow. Coding standards, review processes in place, documentation throughout the life cycle, etc.
That is funny, because I just thought of DEC yesterday when reading this thread
You did not wrote the best code ever because you followed rule X or Y; you wrote the best code ever because everyone at Digital (including the managers) cared about, *and was proud of*, the quality of their products (and as a direct result, you used the right tools to obtain quality).
Yes… and because of that processes and procedures were followed/enforced.
Let me give you an example: 2 years ago I and a several others were asked to come up with a design and based on requirements (this was not at DEC). We designed it, then provided them with estimates for man hours and also cautioned them that just throwing people at it would not get it done faster, yadda yadda.
They did not like our answer and trimmed their requirements. We like-wise spent another few weeks coming back to them with the revised estimate of (roughly here) 10 months from start to user test (not QA – a sort of Beta version). They said “we’ll go with that but you only have 6 months!”
I mean what is that?!?! Talk about cutting corners here and there. And frankly, developers are notoriously optimistic about their estimates (forgetting about the daily interruptions and such).
I don’t know. I mean, I understand that it is important to get products out the door… new and improved! Make more $$$… but it seems like they would rather send something out buggy than send it out done right.
The old Rule #1 of product development was: There is never enough time to do it right, but there is always enough time to do it over.
And now, with accelerated release schedules and people working on more than one product at the same time, there is rarely enough time to do it over. Just fix the bugs.
So the new Rule #1 is: ./configure, make, make install, release.
Btw… I guess I don’t disagree with you.
Software perfection is limited by the level of perfection of the underlying hardware.
In the words of ‘Yes’:
“Maybe we’ll change
Offered the chance
To finally unlearn our lessons
And alter our stance.
…
Machine, machine Messiah.
Take me into the fire
Hold me, machine Messiah
And show me
The strength of your singular eye.”
😉
No one makes bad software on purpose
Real Player
next please
Currently, MS dominates the general public market in the areas of desktop computing. Unless, we get the very platform stabilized, and sucky PC architecture thrown out the door, we won’t have a stable software or should I say that it is very hard to do.
It’s like trying to build a house on top of mud soil.
🙁
Very good article. This is exactly the experience I had when creating software and watching people use it then.
I’m shocked by all these comments here that take external things like schedules, hardware, system software or laziness as excuses for not producing good software. It seems most people are not even trying to create good software 🙁
I encounter this most often with database programmers, who don’t have a clue in the world how their program is going to be used and don’t care. They write programs they can sell to a buyer; not programs that assist the end user. The concept of actually testing their work with real users never enters their head. I can’t tell you how many databases I’ve worked with that needed changes, sometimes major ones, that will never be made. Even our own in-house database programmer is clueless. He writes what HE thinks will work for us, but he would never consider asking us what really works. What’s worse is that he sometimes independently makes changes and sets program defaults that cannot possibly make any difference to him, but that make things more difficult for the users, and we would have to pay him to get them corrected. Which will never happen due to budgetary concerns. I’m not even a programmer, and I could write spreadsheets that are more useful than some of the databases I’ve worked with.
I don’t know who is more to blame; the programmers themselves or the incompetents who approve the expenditure for substandard work without any real-world testing.
“No one makes bad software on purpose.” As I programmer I resent this remark. After having to deal with stupid end users I know for a fact that I and other people have seriously considered (and others have created) software with the purpose of frustrating those same stupid users.
I fully intend on making a piece of software that will have people tearing out their hair. Of course, it’s a puzzle game, but the point still stands. You’re generalizing! : )