Alan Cox on Writing Better Software

Andy Gimblett writes "Alan Cox recently gave a talk in which he discussed some current and emerging techniques for producing higher quality software. Some of these will be familiar to Slashdot readers, such as validation tools, type checking, etc, but others seem heavily influenced by his recent MBA. In particular, he has a lot to say about Quality Assurance in the software world, and the kinds of things we should be doing (and some people are doing) to make better software. Story and lots of quotes at Ping Wales, and video at IT Wales."

Comments

Quality

[mfh]

he has a lot to say about Quality Assurance in the software world

Quality Assurance in 4 easy steps!

Dear Managers,

1. Listen
2. Close your mouth
3. Plan everything around #1
4. Profit!!! (notice there is no line with ??? because you listened!)

Re:Quality

[Anonymous Coward]

And what then when the customer wants some hard evidence about what has been done? What then? What will you provide to them? How does your irrational hatred of managers actually assure quality in concrete steps?

Re:Quality

[mfh]

And what then when the customer wants some hard evidence about what has been done? What then? What will you provide to them? How does your irrational hatred of managers actually assure quality in concrete steps?

A good manager does all the detail work and keeps track of everything. My post was about what they haven't been doing much of lately.

I don't hate managers, and to suspect that I might by reading my previous post means you failed to understand it.

Quality in business comes from many different people in any given project. Software quality can be adversely affected by morale, and you guessed it -- programmers have some of the lowest morales in the business world today; they are often not respected by management, they have the highest workloads, and they have no time for social lives.

If managers listened, and remained silent or inquisitive instead of arbitrary or antagonistic, software quality would be up.

Re:Quality

[acvh]

"no time for social lives"? like they would know what to do if they did?

but seriously, good managers manage. Bad managers threaten, cajole, bribe or whine. software is either a product, which means that management is monitoring to be sure the product is what they can sell; or software is a tool, in which case the manager must ensure that the tool works.

either way, successful software is a combination of good programming and good management.

Re:Quality

[Anonymous Coward]

Managing people to be happy and productive is not the only quality assurance activity you can do.

I ask you again, how does your four-part list concretely assure software quality? The human issue is just a really small part of the software quality. You have tight schedules, inane processes, nonexistent budgets, requirements from some other galaxy, need I go on?

How does for example listening to people automagically track the number of defects? Or make sure there's a responsible person for certain code modules? Or make sure the test cases are written, run and kept up-to-date?

The problem is not so simple as you put it. Yes, listening to people will help but it's not the whole solution nor the end-all to this dilemma.

If someone is arbitrary or antagonistic, speak up and give constructive feedback, tell them to stop being such. If you are reprimanded for that, why work in such a place?

It's fashionable to bash managers, but how many of you will not speak out about things which are wrong when you have the chance, then complain about it being so? If your managers don't listen when you do that, find another job with better managers.

Re:Quality

[angel'o'sphere]

The human issue is just a really small part of the software quality.
Trust me. All problems in software engineering are human issues.
It helps nothing if a guy in the team is a hero or super hero or the brightest expert if the human factros are a mess.
All problems in software projects are simple:
1) lack of understanding -- people do not understand the problem domain
2) lack of insight -- people do not realize they suffer from (1)
3) lack of problem aware ness -- people do not realize that there ARE problems and that they have to SOLVE them
4) blaming other people -- as soon as it gets obvious that (1) to (3) is happening, a solution is not searched but a guy to shift the blame on

This are the core problems. All so called Software Process or Software Engineering tools and habits only soften those problems. A issue tracking tool, e.g. makes it harder to shift blame. As the author of the issue, the assigner and the asignee are known. Same for version control.

As soon as the simplest tools and the simplest habbits get established, people start working together. Working together or not working together. Thats the big point.

How good a certain guy at certain technology is, thats less important. That guy can learn or can be placed at a different work area. If you have such a guy you made your first mistake anyway allready. That again was a human issue (he tricked you in believing he is good, or you misjudged). So cope with it buy educating him or fix it by replacing him.

It's fashionable to bash managers And rightfull so!
For a software project you need no managers! At least not a manager in the traditional sense. A managers job is to get the staffing and the budget done right. Furher he has to be able to understand the development speed/quality of the team and communicate the teams results to the budget owners or customers. Most managers don't do that but make technical descissions about stuff they have no clue about! E.G. my latest project we used a JDO engine (of a so called market leader lol, well the simple piece of software costed Euro 500). We had hughe problems in certain areas of the software and spend about Euro 50.000 in internal development costs in working around those problems.
The team wanted to switch to Hibernate. The manager descided: NO! This is in spite the fact that we made a thouroughfull investigation about costs and benefits and showed we start saving money after 3 weeks and would have speeded up the development process by spending less time in DB mapping etc.
Thats just a simple example. So, we had a human issue again! The coders failed to communicate! The manager failed to understand!
The project was close to run overtime, because of that issue. It was over budget because of that issue.

Nevertheless Alan Cox is right in his analysis. Better coding habits and better strategies and better tools and better languages of course have an impact. The limit however are allways the humans.

angel'o'sphere

Re:Quality

[bert.cl]

Quality in business comes from many different people in any given project.

While this might be true in some (a lot of) cases, I would argue that QUality in business comes from right decisions. A manager that makes "the" right decision doesn't need to listen to his staff. (It's probably always better to do so, but still, you can't force him).

However, if a manager doesn't know a lot about the subject he has to decide on, chances of taking a (close to) optimal decision decrease. That's why managers should listen to their programmers. imho

Note: I use "the" right decision, because there isn't always a "keep everyone happy" solution.

Re:Quality

[Tony-A]

either way, successful software is a combination of good programming and good management.

From somewhere log ago I read something that there is about an 85% overlap in the skill set required for good management and good programming. Both have to make do with conflicting goals and limited resources. Bad management and bad programming is a bad combination. Bad management and bad anything is bad, but seems that the situation is much worse with programming because programmers can instinctively pass sound judgement on managers and managemet style. This doesn't mean what a manager would expect. It's more like the color is red or blue.

Management listen?
The blunt reality is that if management had any intention of listening, it would be doing it themselves. In fact, one of the places where pair programming works is to team a manager with a programmer. However, even then finding an ear to bend will happen only in those few moments when neither of you have anything better to do. Sorry.

Re:Quality

[skandalfo]

And what then when the customer wants some hard evidence about what has been done? What then? What will you provide to them?

Provide them with unfettered access to the project CVS :)

Re:Quality

[ahdeoz]

How does the manager determine a product is what they can see or ensure that the tool works? They don't. They have other people, doing market research or testing determine that. Manager is just another word for boss which goes all the way back to the days of pharoah. When people are working willingly, the manager is a superflous position.

Re:Quality

[penglust]

What you say is mostly true. Managers often get on my nerves too. Especially at crunch time. I also know a few developers that actually expect the code they write will never fail.

What ever the case, good management will know when to get involved and when not to. There are always signs of problems. As an example: Many years ago I worked at a company that was second marketing several different Unix machines under their own name. We did a lot of work to make them as compatable as possible to give customers a real choise. A whole group of tests were thrown together to try and test this. At any time over 80 percent produced some kind of failure messages on all or some of the different platforms. This was in the late 80's and 2 consultants were brought in to look at the test and failures. They were supposed to fix the tests where needed and report on real problems. 3 or 4 months later, on a saturday, I was trying to use the tests to validate some compatability changes I had made. They all passed. A couple of months before nothing had passed. I expected some success but not complete by a long shot. Every test I needed had simply been commented out in the latest snapshot of the tests. They had done nothing at all. When confronted they had no excuse but "we are still identifing tests that fail". They were gone about 2 hours later.

Point being, I think most quality failures are from both managment and development being secretive, self serving and practicing a lot of CYA. I guess these are the reasons why I like OSS. Secretive and CYA has a very hard time occuring and self serving comes about because the programmer gets reconized for both managing and developing on a project far above industry standard quality levels.

If you want an example of managment gone bad take a look at ISO 9000 time sinks.

Re:Quality

[SillyNickName4me]

> How good a certain guy at certain technology is, thats less important. That guy can learn or can be placed at a different work area. If you have such a guy you made your first mistake anyway allready. That again was a human issue (he tricked you in believing he is good, or you misjudged). So cope with it buy educating him or fix it by replacing him.

Most succesfull software products are directly or indirectly the result of such a programmer.

The mistake you are making there is treating software as a mass produced product, it is not ibn most cases. The only thing mass produced about it is copies.

For the rest I think you have a good story there.

Re:Quality

[SillyNickName4me]

Hmm.. replied to the wrong post there, sorry.

Re:Quality

[jc42]

1. Listen
2. Close your mouth ...

One problem with this: By listening with your mouth closed, you run a very real risk of misunderstanding what you're hearing. Without feedback to verify that you're understanding, you are highly likely to do things completely wrong.

Funny example: A few years ago, I was implementing an interactive web site, and we had a nice test server machine in the lab. In one discussion with The Mgt, I casually mentioned that for testing, I thought we needed to run another server.

I didn't hear any response, so I went ahead and cloned the apache server that we were using, and fired it up on a different port. 10 minutes work, and we proceeded to test.

A while later, I discovered just in time that the managers had heard me say that we needed a second server machine, and were ordering another one. After a bit of discussion, I realized that to them, a server is a piece of hardware, while to us software guys, it is a piece of software.

I managed to explain to them that, no, we didn't need a new machine. I'd already set up a second web server on the old machine, and it was working fine. There was still time to cancel the hardware order.

But still, they had done a bunch of unnecessary work, and had almost spent a good sum of money unnecessarily, all because they had listened carefully without asking questions. If they had asked what hardware the new server needed, I'd have realized quickly that there was a misunderstanding, and we could all have saved a bit of time.

Listening without interacting, and acting on your understanding of what you heard, can lead to a lot of serious problems.

Re:Quality

[fyngyrz]

Quality Assurance in 6 Easy Steps:

1. Fire the managers
2. Fire the beancounters
   (steps 1 and 2 may be reversed if required)
3. Fire anyone who even mentions the word "committee"
4. Keep labs open 24/365. Apply metered, but 100% flexible, work hour rules for programmers (ie, "You have to work 40 hours/week, but it doesn't matter which 40 hours.)
5. Provide superb comfort and amenities to programmers
6. Create significant bonus program tied directly to number of problems found in each programmer's code per release cycle. Zero problems, max bonus, more problems, less or no bonus. Stir to taste.

Enjoy good results.

Re:Quality

[2old2rockNroll]

What ever the case, good management will know when to get involved and when not to.

I guess that depends on the company. In our SW department, it's generally those who *can't* that apply for and get promoted to line management. We have one project lead right now who has applied for the assistant dept. manager position, and the programmers who work for him are urging him on (and out of their way).

We have another project lead who is building a little empire and wasting a lot of resources in busy-work. His project produces reams of documentation for every minor release. The only problem is that it's mostly garbage. If the real situation and code changes, the documents don't change to match the reality. Management is cluelessly happy and constantly giving awards to the project.

In my experience, software line management is completely out of touch with what is going on because the people who would be best in that position won't take that position - they know how to build software, and that's what they want to do.

Re:Quality

[Mark of THE CITY]

The closest I've been to this was doing software engineering for defense avionics for the Navy, back in the 1980s. Since Ada compilers weren't ready for prime time, we kept working in the "interim" (in the sense that Steve Jobs was "interim" CEO at Apple) language CMS-2. The target computer had memory protection (read, write, execute) flags on every page, which were set, IIRC, from tables generated by the linker.

Now, CMS-2 was glaringly constrained in two areas I remember: no recursive calls and no dynamic memory allocation. But we never had the problem of the program running off into never-never land, i.e. of trying to execute data, because you'd get a memory exception. Going from that to C was a big step backwards.

If we in software want to be treated as legitimate engineers, we need to move past hackerdom.

Re:Quality

[Anonymous Coward]

I was with you until step 6. All this does is cause your dev people to actively hate their QA people and give the QA people a reason to create a gazillion pendantic bug reports in the search for cash. Unless you have a whole lot of really well-adjusted folks, not to mention super-human bug scrub people, 6 is going to lead to disaster.

Re:Quality

[fyngyrz]

I never suggested that QA people be rewarded for finding bugs. I indicated that programmers should be rewarded for not producing them, as evidenced by a lack of reported problems per release cycle. That's something completely different than rewarding QA people.

QA people are a dime a dozen (just like managers.) Further, on any application with a reasonable degree of complexity, users will find things the QA people never even imagined. That's a given. What is not accepted widely, though it should be, is that the producer of the software has the obligation to squash the bug yesterday and get the fix to the end user immediately afterwards.

In contrast to QA people (and managers), focused, high output, high quality programmers are extremely rare and deserve motivation and reward (and by the way, I own a software company with quite a few programmers. We have great, relicable and ultra powerful software - you don't even get one guess as to why. :)

Anyway, you should limit your anti-rewardable bug reports from your end users. Only reproducable or at the very least, findable, bugs should count.

Re:Quality

[abb3w]

The hazard of 100% flexibility is you maintaining adequate communications between them. If you can add one person each who work a nice "regular" schedule... but one working on a 21 hour/8 day week, and the other on a 28 hour/six day week, it helps communications immensely between the 24 hour/7 day humans. (I speak from experience, and would ADORE another job that lets me go 28/6 again.)

Re:Quality

[fyngyrz]

But we never had the problem of the program running off into never-never land, i.e. of trying to execute data, because you'd get a memory exception. Going from that to C was a big step backwards.

With regard to c - which we use exclusively, by the way, in a huge application - one of the first things that needs to be done is to wrap the memory allocations with a powerful tacky-footstep region combined with procedure signing so that if a program over- or under-runs the boundaries of an allocation, you can see it happen, and you know what procedure did it. You can do this within the executable, but you also need a hook so that if the program loses its mind or stops with an exception, you can analyze the regions with a third party process and see who ran off over what with whom. Easily done. Named memory allocations, named memory groups, unfreed pointer warnings, multiple allocations for the same target pointer without an intervening deallocation (you do this by indirect pointer use.)

Large program development needs to be done with all of this stuff turned on, and the release compile can turn it all, or at least most of it, off. That's what we do. Works great. C certainly has limitations in this area, but they're not insurmountable.

Re:Quality

[penglust]

Been there, done that. I could not agree more. But I have had a number of good managers in the past. Did a stint as manager myself at one time. I backed off because, like you, I just plain like to be productive and I think like an engineer. This may it difficult to deal with those above me.

My direct manager right now is acutally one of the best I have seen. The other 3 or 4 layers above are lost and clueless most of the time. Their buzz word at the moment is ISO 9000.

I think your comments bring up another issue. F**k up move up is often not just a saying. I have made friends and lost friends in the past for my opinions but if one of my fellow programmers is just plain incompetent, lazy, or an ass hole then they need to go. I don;t encorage moving them to get them out of my hair. I have done this before and somehow I always ended up having to deal with them again.

There is also the type that are just biding their engineering time till they can become a manager. I have generally found these guys to be less than worthless. They are usually garanteed to make the worst managers.

These are the criteria I usually find good in a manager and tried to use as one:

1. Have a good broad software background. If working at the kernel level (including driver) have a basic understanding of hardware

2. Understand how software impacts the potential customers and their needs. Books have been written on this, most of them wrong.

3. Know your employees and their stengths and weaknesses. Use this to build a team that can and will perform.

4. Trust the team but keep track of everything anyways.

5. Process is a must but it should be pretty lightweight. Make it enforcable and do not waiver in ensuring the necessary pieces occur.

6. Insulate your engineers from most of the stuff above. Not all, just most of it. Usually controlling the flow will suffice (often this involves rumor squashing).

OK enough for now.

Re:Quality

[fyngyrz]

You do need good communications. We used to use a custom todo system and a message board, these days a wiki has replaced the MB, and the custom todo system has been integrated with the wiki.

The todo system allows people to add (signed) tasks to other people's lists, it shows you what tasks have been completed by others, allows "chucking" of tasks (but you have to explain why) and every finished (or chucked) task is dropped on everyone elses list where it must be ack'ed before it will go away. You can embed comments and so forth, tasks can be ghosted and made to appear at known recycle intervals, nested within each other, aging and priority are supported, hot issue flagging, and so on. The actual todo system is (again, these days, didn't used to be) actually embedded in the wiki, so there is lots of opportunity to expound on something as needed.

We've had extremely good luck with setting clear goals and isolating tasks to clear domains; that also helps keep the level or required communications down to a dull roar.

Re:Quality

[Anonymous Coward]

Sorry, I misunderstood your intent. I agree that if the dev folks see their bonus drop with every confirmed bug report they would be highly motivated to produce better code.

Do you employ this system in your company? If you're willing, I'd like to hear about a couple of details. For example, is bug "disposition" a factor? I.E., are 5 easy bugs worse than one difficult one?

As for the QA folks and managers, I'd say that average ones are a dime a dozen but really good ones are nearly impossible to find. Especially in QA since a lot of those folks are just using QA as a stop on the way to a dev job. Not that this is bad, it's great for developers to have QA experience (and support experience for that matter), but it means that you get very few people that make a serious study of QA. Despite my own methods and tests I sleep a lot better if a top-notch QA person has signed off on my code.

Re:Quality

[2old2rockNroll]

5. Process is a must but it should be pretty lightweight. Make it enforcable and do not waiver in ensuring the necessary pieces occur.

6. Insulate your engineers from most of the stuff above. Not all, just most of it. Usually controlling the flow will suffice (often this involves rumor squashing).

Agreed, that would be good management. Too bad most managers don't see it that way. They generally go out of their way to find more work for engineers instead of facilitating the work required.

Re:Quality

[fyngyrz]

Yes, precisely the approach I outlined above is in place here and has been for some years now.

No, there is no distinction between an easy bug and a hard bug. For one thing, there is little, if any, correlation between the annoyance caused to the end users and the difficulty of resolution for the programmer. An easily found missed token can cause more obvious and annoying problems than conceptual errors in a convoluted procedure that will take a week to understand (again.) Or vice-versa. A bug is a bug, and they cost equally.

To us, bugs are things found where the program doesn't behave as it was designed or advertised to, and which are determined to be problems within the software (Example: Microsoft's rotation of a font glyph backwards under RISC (Alpha, MIPS, PPC) NT as compared to Intel NT in their matrixed font bitmap renderer doesn't count as a bug - we have to put in code to compensate, of course, but this is clearly Microsoft's bug, not ours, and our programmers are not penalized for missing such a thing - why would you expect, or test for, such a thing??? If you can't assume the OS does what it is supposed to do, you'll never ship product - the permutations of what you would need to test become incomprehensible.)

When registered users report "bad" or "unexpected" program behaviours, that's when they become "a bug" in the sense of the bonus program.

If bugs are caught before they go out the door - by anyone, beta testers, QA, the programmer, me - anyone here or anywhere pre-sale - that doesn't count against the programmer either.

The programmers are highly motiviated to test their own stuff, and I try to see to it that they have flexible and powerful tools and concepts to do so.

We also profit-share and my company has helped substantially in purchasing homes for all the programmers. I own the business outright; there is no stock, there is no debt, and there are no co-owners. So we do things my way.

I believe there is absolutely no substitute for motivation. So far, it's working out quite well for me. And my employees, too. :)

Re:Quality

[Anonymous Coward]

Sounds like you made the bigger error. To most of the world a 'server' is a physical machine. If you want to use 'server' in a software context, most people are only going to understand what you mean if you say 'server software.' Your post only illustrates the fact that developers cause a substantial part of the disconnect between themselves and management. Clarifying questions are great, but using jargon is asking for misunderstanding (and 'server' is still jargon despite it being 2004 (currently working with non-technical management on a couple of projects)).

Then again, despite the fact that I send clarifying email to my bosses, I always seem to be asked to do the impossible as project deadlines roll by and every party involved had a different idea of what the deadline actually meant. This just happened yesterday, actually. In the future, I am going to phrase intermediate goals as "x outcome WILL be attained" and "y/z/a/b/c outcomes WILL NOT be attained." Even better, have three sections to each status report: what has been done so far, what will be done on the goal date, and what will still need to be done after the goal date. It adds to the developer workload slightly, but if they are the only people with the technical qualifications to write these things, what choice does anyone have?

Re:Quality

[Anonymous Coward]

> When people are working willingly, the manager is a superflous position.

So you have no customers, or you just let them send all your demands to you directly, huh? I like having a project manager figure out what's important to who so I don't have to listen to all the damn justifications.

I like having an HR manager so I don't have to resort to fisticuffs to resolve disputes.

I like having a department manager so I don't have to justify my existence to the CEO every day.

Re:Quality

[wuice]

Wish I could mod this as "Funny."

Re:Quality

[wuice]

QA people are a dime a dozen (just like managers.)

And programmers.

Re:Quality

[Profane MuthaFucka]

I think the managers made the bigger error. Think about it: his bosses decided to order a server based on the word of an underling. Too bad he didn't say "I think that this project would succeed if the team had their own personal F-15 fighter to blow off steam in." The robot managers would have just gone out and bought one, I suppose.

To put it another way, who is the boss, and why are they taking purchase orders from someone who is not the boss?

Re:Quality

[jc42]

Sounds like you made the bigger error. ... Your post only illustrates the fact that developers cause a substantial part of the disconnect between themselves and management.

Well, I can see why you'd read it that way. But I don't think this is really accurate. One reason is that I'd merely mentioned the idea of a second server, as a "throwaway" comment. Nobody reacted, so I mentally shrugged, and Just Did It.

Another reason that I didn't mention was that the project had earlier had a relevant problem: The management had decreed that we were to use a specific web server (which shall remain nameless here). This shows that they were aware that a web server is software. But the group was unable to make the server work properly. It's config GUI was just too ornate, and we couldn't get it right. One day I nabbed a copy of apache, compiled and configged it, and 20 minutes later we had a functioning web server that never failed us. So again, a "web server" was a piece of software that I'd installed on the machine. The managers was well aware of this, and eventually went with apache (though not happily). So there was no reason to suspect any difference in terminology within the team. We regularly used "the web server" to mean the copy of apache running on our test machine.

Given that this was (mostly) a software-development project, there was every reason to believe that we had a common understanding of our common terms. The misunderstanding over whether "web server" was software or hardware came as a surprise to most of us.

If anything, this is mostly an example of how a misunderstanding can arise without anyone suspecting. Then someone does something that just doesn't make sense, until you realize that there's a difference in how some people understand a bit of jargon.

And recall that the original comment here was suggesting that managers should listen with mouth shut. I was giving an example where that failed. Actually, it didn't quite fail, because someone opened their mouth soon enough, and I corrected the misunderstanding. But it's still a useful example of why you should at least talk a little, to make sure that you are really talking the same language.

Re:Quality

[Mark of THE CITY]

My point exactly -- you have to accomodate yourself to the tool. I didn't mention that, on the system I was working on, memory (core; yes, in the 1980s, core) was tight, 384 Kbytes.

Re:Quality

[mewphobia]

Thank you mfh, after years of pondering I finally know what the ???'s stand for!

Since we're all geeks, I'll make it easy for us;
"???" = "Plan everything around #1"

Re:Quality

[Anonymous Coward]

That does indeed sound like a good system, and working environment for that matter. Thanks for sharing the details. :)

Re:Quality

[Anonymous Coward]

That's a cute fantasy world you have there. Unfortunately, I don't see what it has to do with quality assurance. It's a programmer's fantasy land, but that's not the same thing.

You don't even mention testers, or QA, or any of the suggestions Alan Cox had, or anything like that. Do you think that by providing "superb comfort" the programmers will automatically start writing zero bugs into their code?

Re:Quality

[fyngyrz]

Well, my little "fantasy world" does all right by me and mine, which is all it really has to do. You might want to read the rest of the comments in the subthread to see what I did, or didn't, mention, though.

Believe me, it's no skin off my back if you have a crummy work environment. In fact, if you work for a competitor, quite the opposite. Great! :)

Now: You want a comment on Alan Cox? Fine:

I quote his opening remark: "All Software Sucks."

My comment: I rather suspect that when he gets back out in the real world and tries to comingle his newly minted MBA with real programmers, someone will jam it right up his spreadsheet for him.

Me on Alan's claim to fame, being a Red Hat dude:

I run Red Hat linux on quite a few machines, as it turns out. I stopped upgrading with v9, as I wasn't inclined to revisit the startup pains I'd had with 6 and 9 with Fedora. v9 (never mind v6, which was just awful) is broken in more places than I can count, though I've fixed many of them since installation, or someone else has fixed them and I found the fix. If my company's software was in the state that red hat 9 was when it shipped, we wouldn't have shipped - period.

So what we have here is a guy who was part and parcel of a fairly crummy software distribution, now off to college, learning some bright and shiny new things, and he is getting up on a podium and telling everyone how to write software. Well, good for him. Luckily, I don't have to pay attention. After RTFA, with the emphasis on the F, I know I don't have to pay attention. :)

I stopped by the slashdot blog because I am far more interested in what the people here have to say than I am Mr. almost-MBA Cox.

That about cover it for you?

Re:Quality

[Anonymous Coward]

Believe me, it's no skin off my back if you have a crummy work environment. In fact, if you work for a competitor, quite the opposite. Great! :)

You're still missing the point. It's great if you work in a nice work environment. I know lots of people who have great work environments who still turn out bad code. Being in a good work environment is not a guarantee of product quality.

...Alan's claim to fame, being a Red Hat dude:

I didn't know he worked for Redhat. It's certainly not his "claim to fame". He's first and foremost a Linux kernel hacker -- if you didn't know that already, you can tell from the talk.

You can badmouth Redhat all you want, but he's a kernel guy, and the kernel is pretty solid. (If you're trying for guilt-by-association -- "he's on Redhat's payroll so he's responsible for all the bugs in Redhat" -- don't bother.)

...Mr. almost-MBA Cox.

Now it sounds like you're more upset at him for going to school than anything else. Note that none of the comments he made were of the form "in business school..." -- they were of the form "while working on the kernel...".

Any comments you have about work environment are OT -- this article is about quality assurance, not work environment. (Rants about Redhat, doubly so.) But if you can't think of anything to say about QA, go ahead and bring up Redhat 6, personal attacks on Alan's education, and tangential discussions. Cheers!

Re:Quality

[Phragmen-Lindelof]

Step 2 might or might not make sense. A QA person who really knows statistics and will point out problems even when "higher ups" do not want to be told can be rare and valuable if the environment is right. I know a QA person at Boeing who did this (and was laid off as soon as possible, which was a couple of years since she was not the most junior person in QA); her suggestions were generally ignored (since politics at Boeing is much more important than quality). Step 6 sounds like "make sure no problems are found" rather than "write good code". We have a graduate student who help write IIS. His experience was that programmers at MS had huge egos and would usually not accept criticism. Step 6 would just encourage people to hide their errors better.

There is nothing in this post which encourages teamwork and code verification. It is completely contrary to Cox's comments about writing good code. Modding this up is just silly.

Re:Quality

[Phragmen-Lindelof]

Bad "QA people are a dime a dozen". Good QA people who actually know something are not so common.

I know a number of PhDs (generally university faculty) in electrical engineering, industrial engineering, psychology, sociology, and other areas who use statistics in "cookbook ways" and know almost nothing about experimental design and other areas of statistics. These people design experiments and, after the fact, try to see if they have learned anything (i.e. can they draw any statistical inferences). They usually find that if they have a big enough sample (far larger than is necessary) and a cookbook approach to statistics, they can reach some conclusions.

I also know that aircraft companies (and others) hire people who took the "five steps to learning QA" and "QA buzzwords" programs and claim to know QA; these people are often a joke. (These you can fire. Keep and listen to the good ones.)

"I indicated that programmers should be rewarded for not producing them, as evidenced by a lack of reported problems per release cycle."
MS produced software which had lots of security holes which were not discovered for a long time. Your suggestion would reward people like this. Why not reward people for writing good code that is tested and verified? (Did you read the article?)

Re:Quality

[Phragmen-Lindelof]

I suspect that your method works because of who you are and might fail if someone else took over and used your procedures.

Re:Quality

[fyngyrz]

Well, I really can't say yea or nay to that. I have my fingers into everything that goes on, sure enough. And some things are just luck. But I can at least say this: This method can work.

Re:Quality

[fyngyrz]

Being in a good work environment is not a guarantee of product quality

I never said it was. If you go back and read, you'll see that there is a strong feedback mechanism in place - which is not about general amenities. Aside from the facts that decent programmers can usually do decent work, and decent pay and amenities make them interested in keeping a job that provides same - feedback that directly rewards, and therefore encourages, quality and reliability is nothing to turn your nose up at.

As for the rest, this feels more like a troll than a comment. I don't care about his schooling or lack of same; I'm outright offended by his claim that all software sucks. Apparently, all his software sucks - he knows his own software, and his says all software sucks, so I guess that's a critical part of his sample - but we don't generally produce software that sucks, and I know a lot of other people that produce software that doesn't suck. If you think you detected ruffled feathers, you're quite right - but it wasn't about schooling, it was about clueless hyperbole that I expect from 12 year olds, not from "Wales' most famous Red Hat employee and one of the most influential voices in the IT world."

This clown goes on to denegrate reusable software with a house-of-cards style stack of chained reasoning that belongs in a pulpit, not a technical assessment. He as much as says that if it is re-usable, it is bad. What a stack of nonsense.

Thanks for the cheers. :)

Re:Quality

[fyngyrz]

Why not reward people for writing good code that is tested and verified?

We do. We test like mad. We apply suites of test images to functions (this is graphics software.) We apply canned animated timelines that beat the h*ll out of area selection mechanisms and filters and so on. We stress functions with test calls. We require acceptable input ranges to be documented, then we test through the range, and outside the range. We use custom memory management that catches all manner of things. In short, we try very hard to do it as right as we can manage.

But one thing we do not do, and I maintain nobody can do because of the permutations and combinations required - and that is claim that we "verify" our software. Oh, we try, all right. But we know - not guess, but know - that somewhere, someday, some user is going to combine some factors in a way no one anticipated and break us, break the OS, cause us to break the OS, cause the OS to break us, break both, etc. When that happens, we try to fix it as effectively and expeditiously as possible.

My objective is, and always has been, to try to cover the ground in the most effective manner before the software goes out the door. My attempt here is to provide a mechanism that directly addresses the problem of "whipped-out" software by motivating the programmers - the people who are crafting the logic, the data structures, the very heart of the issue - to try and cover their butts so that they do indeed get that bonus at the end of the cycle.

So far, it is the most effective thing I have seen used.

And yes, I read the article. There is so much worthless, nay, even harmful, content in it - "all software sucks", "reusable objects are bad", "the art of writing large bad programs", "the moment a project is behind deadline, quality assurance tends to go out the window", "The world has moved on since the design of languages like Fortran and C"...

...that I am not very interested in the rest of what he has to say. There could be some real gems in there. But I think I'll dig for them elsewhere, like here. Lots of very sharp people running about on slashdot, they offer some very interesting insights. Most of them don't make an utter fool of themselves in the process, as Mr. Cox does.

Re:Quality

[Anonymous Coward]

With regard to c

"C".

Re:Quality

[Anonymous Coward]

I like having an HR manager so I don't have to resort to fisticuffs to resolve disputes.

Hooo, that is like saying the police resolve disputes - I have never seen HR make a problem go away, they are there to cover the company legally, they don't care what is right or wrong, only what course of action exposes less liability.

HR is a joke - "Let's hand out posters with meaningless platitutes on them! That will motivate the lesser associates!" "Let's make a rule that they have to call each other "associates" but they have to call the upper management "yes, massa" (legal nixed the second part of that great idea, brought to us, btw, by our own Wendy - Junior HR Associate"

Another hilarious function they serve is to provide creative, manufactured rationalizations why the lower monkeys can't have any of the perks afforded to upper management - you can't have a blackberry because that is a management tool (but wait you want me to be the first and last line of defense for maintaining 24/7 100% uptime for your precious fucking website ("webpresence") ?

Fuck HR - you must be a manager to say that because any employee knows that no bureaucratic department (accting, legal, HR, facilities, Networking, management, etc) in an organization cares about solving problems or making life better for the monkeys - they know that they are required whether a profit is made or not and whether they help employees or not will generally not affect their job.

Re:Quality

[Phragmen-Lindelof]

My feeling was that you have much higher standards than one might have guessed from your initial posts. I agree with your comments on the difficulty of code verification. It reminds me of interval analysis in which a computer program returns a guess (the "answer") and an interval in which it is mathematically certain the correct answer resides. Interval analysis is not yet a useful tool (at least to obtain mathematical proofs) but it is an interesting idea. I am not an expert on code verification but I believe it is important to make one's best attempt to verify the code; this sounds like the procedure at your company.

Re:Quality

[Anonymous Coward]

7. Quickly go out of business because the coders have no relationships with those mythical creatures known as "customers". These creatures are rumored to work in daylight hours, and are known to value such frivolous things as good user interfaces, system documentation, and technical support.

There is a reason management exists, and you're it.

Re:Quality

[fyngyrz]

That's pretty funny, really. So - you use your programmers to do technical support? Man, that is really scary! Do you ever get anything productive done?

As for the rest - UI, documentation - you really have no idea what you're talking about. We have absolutely amazing docs - tons of reference data, many tutorials in the docs, more online outside the docs... our UI is fast and powerful, much more so (of both) than other applications in the approximate same application space (nothing is exactly in the same space - our stuff is somewhat unusual in that regard. That's because we've been doing this longer than most others, happily cruising along making graphics and CAD software since about 1983.)

But hey, don't let the facts stop you. Please favor me with more of your wisdom. :)

Unit testing?

[JohnGrahamCumming]

It's quite surprising to me that there's no mention here of unit testing, or any sort of automated testing where the engineers who wrote the code actually write tests.

It should, by now, be clear that "code that doesn't have tests, doesn't work", and that if XP has done anything for us, it's to focus on writing tests. I've seen this in action and it works.

John.

Re:Unit testing?

[Anonymous Coward]

here here. as a coder i tend to get things working as they should be, but the user comes along and does something completely different. i've found that the key lies in trying to break the code, and when you get it so that it doesn't break, you're halfway there. i try to code for at least a 'mars rover' level of reliability.

Re:Unit testing?

[bloggins02]

Unit testing is essential, but it's not a panacea. In particular, beware of two pitfalls:

1) "The unit tests passed, so it works." This assumption is flawed on several levels. First, and most fundamentally, even if all unit tests pass, there is still the issue of whether your software works as a whole. Software often has "emergent logic" and UI scenarios that are difficult or impossible to test (after all, that's not what unit testing is for, but some people seem to think it is).

Second, just because a test passes, doesn't always mean the API works. This is especially important if you didn't write the tests yourself. Just because a unit test CLAIMS it tests X, doesn't mean it does. Is the test complete? Any false positives? Is the test just a skeleton that was intended to be implemented later but never was? I've had all these bite me in the past.

2) "That particular test has NEVER passed, so there's something wrong with the test. We just ignore it now." Bzzzt! Wrong! There's a REASON it never passed. It's either not implemented properly, just a stub that fails waiting for someone to write an implementation, or maybe you just think the feature it tests actually works. Look closer. The test might be trying to tell you something.

If you are careful with unit tests, they can be very rewarding and useful (especially for regression testing, where they are invaluable), but put too much confidence in them or depend on them to do the kind of overall testing they were never designed to do, and you will fail long before your first test does.

Re:Unit testing?

[cerberusss]

What people should realize, is that it can cost quite a bit of effort to build a unittest. I.e. if you write some code that reads several rows from a database and as a result writes a bunch of rows in another table, you need to run scripts before and after your unittest. It's of course all doable, it's just that it's sometimes more work than writing the method itself.

Re:Unit testing?

[Unkle]

But that's really the reason it's not done all that often. Developers think that the unit test will be a waste of time. The problem is, nobody codes perfectly. Finding a bug during unit testing is much better than finding it in design validation testing. Indeed, on many projects I have worked on, issues that could have been found with adequate unit testing were not found until after release.

Unfortunately, when schedules get tight, it's things like unit testing (and testing in general) that get cut. The more emphasis we get on the importance of QA the better our industry will be.

Re:Unit testing?

[Anonymous Coward]

Study Mock objects

Re:Unit testing?

[Anonymous Coward]

It should be clear to any programmer that lots of code works despite not having any tests. I for one have written dozens of small 1-page apps and many of them Just Work.

You don't do your methodology any favours by making blatantly untrue statements to support it.

Re:Unit testing?

[Anonymous Coward]

Anyone ever notice DO-254 (That pesky avionics software development guideline) never mentions unit testing? There's a reason for that.

A solid requirements based development process and requirements based testing/verification process is the key to large high quality software. In my opinion, formalized unit testing tends to hide errant system level behavior. Sure, it aids an individual developer in understanding their code works as they intended, and should stay a vital part of low level development. But I've come to realize, it just doesn't help to reduce big errors in system level design.

Re:Unit testing?

[OP_Boot]

the engineers who wrote the code actually write tests

Do NOT get the engineer who wrote the code to also write the test.

It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work.

Get someone else to do it and get a valuable fresh insight.

Re:Unit testing?

[Anonymous Coward]

It's quite surprising to me that there's no mention here of unit testing, or any sort of automated testing where the engineers who wrote the code actually write tests.

It's better if you get different people to write the tests. Otherwise the engineers might subconsciously make assumptions in their unit tests that real-world use might not.

Re:Unit testing?

[mark_lybarger]

you only need to validate the functionality in the method itself is working. from your sig it seems you're using java. junit with an embedded axion database allows for extremely easy testing of a method that uses a database connection for its work. of course, you have to setup your test by creating a table, and inserting any base data. getting that basic framework is as simple as writing the method itself. you'll probably double your time in writing the actual method. i'd think the return on that investment is "priceless".

Re:Unit testing?

[deranged unix nut]

Unit testing doesn't find bugs, it just ensures that you didn't regress the obvious or break something that your previously fixed.

With end user applications, on average, a couple hours of active ad-hoc testing and test case development per week finds 95% more bugs than hundreds to thousands of automated unit tests will.

For an API, unit testing might be more effective, but APIs are much simpler to test than full end user applications.

Re:Unit testing?

[RAMMS EIN]

Unit tests are no more than glorified sanity checks.

The advantage of unit tests is that, once written, they can be used again and again, which is useful for verifying that a change to the unit did not break its previously tested behavior.

The disadvantage of unit tests is that they can themselves contain bugs. It's good to know your program passed the tests, but were the tests good? Did you really test what you thought you were testing? Was what you thought you tested actually the right thing? Did you not omit any cases? The answer to the last question is almost invariably "yes". So how can you be sure that your tests were complete?

I often think that unit tests are not worth the time it takes to write them. Better review one another's code - you not only catch errors that way, but also weaknesses like bad style, subobtimal algorithms, etc.

At the end of the day, the KISS principle is the single greatest enemy of bugs.

Re:Unit testing?

[rumblin'rabbit]

I disagree.

First, it is not necessary for unit tests to be absolutely complete to be useful. Anything that finds a hitherto-undiscovered flaw is valuable - extremely valuable.

Second, that there are bugs in a unit test is not, in practise, that big of a deal. At worst it means is you haven't tested a unit as thoroughly as you think you have. Unfortunate, but not a disaster. Perhaps two people should write their own units tests for a single module, and then compare the bugs they found in the module. An interesting experiment I think.

My experience with unit testing is that it greatly speeds up the development process. Trying to get a half dozen classes all up and working simultaneously is an arduous task that can take god-knows-how-long. Trying to get one class up and working through unit tests is generally straightforward and predictable.

And the quality of the component goes up. Waaaaaay up. It is rare when I write a unit test and don't catch at least one bug, thus easily paying for itself.

It is not a case of unit testing versus reviewing. It should be a case of unit testing and reviewing.

Re:Unit testing?

[angel'o'sphere]

It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work.

Right and wrong.
If you write the test first, its far easyer to let the coder who wrote the test also write the implementation.
Writing the test mainly means transforming the business requirements into a client (test) programm for a non existing API. By that you specify the API you need.

However if you like to do a lot of white box testing, you usually do like you propose and have two teams, one for coding one for testing.

If you want you can extend it to 3 teams. Coding, compiling/linking, testing. None of them sees what the other teams do except for input and output. The testers never see the code, the coders never the test (but the results), and if you indeed have the compile team in the middle, the coders also don't see the compiler and linker errors. Thats called "Clean Room Development". BTW. calling a reverse engineering or coding after specification a "clean room implementation" is WRONG.

How do the coders ensure their code compiles? Via reviews and inspections. Or they get told that a source did not compile. Result of such a process is a hughe amount of little source pieces which are very robust and a hughe (regression) test suit ensuring that small pieces stay working and that integrated systems work.

angel'o'sphere

Re:Unit testing?

[arafel]

Really, you want the tests written by people who *didn't* write the code.

Re:Unit testing?

[cthlptlk]

It's not quite the same, but "scripting debugging" and unit testing are close enough to accomplish the same ends. What is looking comparing variables in a debugger to expected values? Unit testing is basically just automating that process.

Re:Unit testing?

[Anonymous Coward]

Yes Unit testing is essential for large projects.

(Quick scripts or small one-person programs that don't evolve much may get by without it.)

This is also an alternative to using (statically) typed languages. (I used to use SmallTalk, which does not require typing.) If the system is substantial, the code *must* be exercised at least to the point of code coverage by unit tests, so type errors will be almost always be caught.

In that case the overhead of maintaining typing assertions in every freakin' method is less compelling w.r.t. the benefit.

Re:Unit testing?

[12357bd]

Unit testing is not a panacea.

1 - Who test the tests? (fiability)
2 - Parts are tested, ok, what about the whole thing? (exponential complexity)
3 - Doesn't help when the design is flawed. (correctness).

Overall, unit testing is ok/valuable at a certain level of abstraction, tipically used in library dvelopment, not a panacea, just a good habitude.

There's no way to kill the complexity factor inherent in software development, there's no way to assure that a given design is the correct one.
Maybe when we start to do automated programming, but by now is just a form of writing.

Re:Unit testing?

[richieb]

A solid requirements based development process and requirements based testing/verification process is the key to large high quality software.

You tacitly assume that it is possible to get solid requirements. When writing avionics software, I'm sure you can, because the problem is well understood and we have good science/math to back it up (eg. GPS nav system).

But in most sofware projects it is impossible to create requirement ahead of time, mostly because the problem you are trying to solve is new and we don't understand it well enough yet.

Are there requirements for the web browser? Were they created before the code was written? WHat about requirements for MS Word?

Re:Unit testing?

[Surt]

That's definitely the ideal, but even if you don't have the resources to do that, forcing the engineer to think about ways his code could break is very helpful in increasing code quality.

Re:Unit testing?

[sjames]

Unit testing is essential, but it's not a panacea. In particular, beware of two pitfalls:

One more, does the unit test match the requirements? If the test passes incorrect (off spec) operation and fails correct operation (on spec) it's far worse than useless.

Re:Unit testing?

[Anonymous Coward]

Two things:
1) I have ALWAYS been taught, and agree, that the author of a block of code, prose, whatever should NEVER perform the testing(or review, correctness evaluation, etc.) Why? The author will tend to write tests that only test for the obvious, i.e. the functionality as intended, and tend to overlook unexpected inputs/results.

2) While it is true in some cases that the projects ARE new and requirements difficult to write, the vast majority of software projects today do involve re-inventing the wheel to a degree. i.e. MANY projects are not REALLY creating something new, but just doing it in a slightly different way, and in such cases it should be entirely possible to a minimum define a high level functional document before implementation. On the other hand, it IS true that ENTIRELY new projects will be subject midpoint changes either driven by delivery, or lack of understanding of existing or expected technoloogy which requires scaling back of implementation goals, etc.

Another case, a special case, is one in which working on an existing project closely with a customer, in the case which the customer is CONSTANTLY changing the requirements. I have been involved in several projects where for a period of two months the customer was calling at LEAST once a day to change the requirements of the project. Once I realized that this was going to be the case, I developed a modular(i.e. easily modifiable) framework and let the project rot until the customer wanted to test a version of it, which required about half an hour of time to modify the framework to operate as the customer desired. The drawback of this situation was that the framework was not as optimized as it could have been if the requirements were not constantly changing up until initial delivery.

Managers: A few of the managers that I have had to work for were of the type that pretty much ignored everything until there was a problem, and then promptly rand around like a chicken with their head cutoff. End results, a few employees got axed and the manager probably got a nice bonus check. (e.g. sitting on a project doing nothing until whoops have to design new hardware, add a new OS and functionality and deliver it in 3 mos.)

On the other hand I did work at a few places where the managers actually did do their job (or at least attempted too) and things went fairly smoothly. e.g. running intereference between developers and customers, limiting requirement changes(see above), and with upper level management attempting to do something stupid(i.e. the blind leading the lame), securing tools/software, etc. (Of course a few of these also did stupid things like deciding to entirely change how interfaces were handled about 3/4 of the way through an initial development, delaying a project by about 6mos. because some developer thought that he had a bright idea(TM). Actually it was using a SQL(!) database to define interface characteristics while everyone else was using XML or a similar type of interface definition language. Another good one was not to take an existing piece of hw, and mock up a quick case and prototype interface, just to rely on a paper proposal while every other company bidding had some sort of functional or non-functional prototype of at least cases.)

Re:Unit testing?

[Anonymous Coward]

In your criticism, you made a fundamental logic mistake. You criticized the original poster with the argument "The unit tests passed, so it works.", yet that is far from what he said, which was "code that doesn't have tests, doesn't work". Much different concepts.

Re:Unit testing?

[jc42]

you want the tests written by people who *didn't* write the code.

Correct in theory. But in practice, I always write a test suite while writing the main code. It's the fastest way to get the job done. When the inevitable change requirements come along, I have a regression test suite that helps make sure I haven't broken the earlier cases.

And, when it comes time for the QA people to write tests for my stuff, their tests are always a proper subset of mine. Over several decades of software development, I've yet to see a single case of the QA folks testing something that I'm not already testing.

This shouldn't be a surprise, since I know more about the code (and usually the task) than any of them do. This is because they're madly trying to come up to speed on the requirements, while juggling the testing of N other pieces of code, and not enough time to do the job right. I've been there ahead of them so of course I know more about it.

What usually happens is that the QA folks quickly realize this, and they start asking me for a copy of my test suite. I tell them I'd be happy to hand it over, if they'll also give me any new tests they devise. As a result, I tend to get along with the QA people better than most of the other developers.

Frankly, the QA people have a very difficult job, and all the worlds' wonderful management theories don't do much to help them. Sensible developers will short-circuit the task by cooperating with the testers.

Now if there were only some practical way to automate GUI tests. I've used a number of packages that claim to do this. I wonder if there are any that actually work for more than the most trivial cases? Short of an AI-enabled robot, it's hard to imagine how one might test responses to the things that humans actually do with keyboards, mice, trackpads, etc.

Re:Unit testing?

[civilizedINTENSITY]

In my Software Engineering class it was specified during lecture and showed up twice (in different ways) on the midterm that testing requires considerably more man-hours than coding. Its always supposed to take longer, to be "more work than writing the method itself". It needs to be done. We need to do it. "Just do it." And do it well.

Re:Unit testing?

[Anonymous Coward]

you (and many others) are confusing software requirements with design and implementation. if you can conceive it to write the code you *can* write some level of requirements. requirements are not the design of the system. a simple requirement can spawn many many many design decisions. however, in the end you want the software to meet the requirements, usually irrespective of the implementation that gets you there. what you find is that some design decisions are routinely made to meet a requirement, this does not make them the same.

Re:Unit testing?

[ahdeoz]

Truly. 95% of automated tests are built into things called compilers. Automated unit tests check a couple of things: field validation, and isBroken(). It's a good idea to leave some field validation out of your code base (especially from config files) and if you have many systems interacting, checking if one or more isBroken() with unit tests is a good way to help deployment or failover.

Re:Unit testing?

[liquiddark]

This type of testing, to be done properly, requires tool support, and it isn't properly done at a unit test level. A unit test tests the bare facts, like "Are you issuing the select or sproc as desired?" When you need this level of testing, as has been mentioned, mocks will suffice. When you need to see that the code is functioning alongside the database itself (more commonly called "systems" or "integration" testing), you should have a tool on hand that can re-create a particular configuration based on a pre-populated database (which can originally be done by a proper QA resource/functional expert). ld

Re:Unit testing?

[Tony-A]

I agree.

At the end of the day, the KISS principle is the single greatest enemy of bugs.
Gives 'em fewer places to hide.

Unit tests are no more than glorified sanity checks.
As a sanity check, should be useful, but any assumption that they mean much of anything makes me suspicious.
If by unit test, they mean an ene-to-end test of the unit in a live buggy system, then it has some good value, but it sounds too much like trying to use the fact that it works correctly in a carefully controlled environment to imply that it has to be somebody else's problem.

"Compounding the situation even further is the incentive for businesses to deny all knowledge and point fingers when software errors are uncovered. If there are several parties responsible for the maintenance of a piece of software, he said, it's in everybody's interests that the other person fixes the bug because the customer will assume that whoever fixes the bug was responsible for it."

The bugs caught by unit testing tend to be the simple trivial bugs. Boring.
The interesting bugs are when it takes two of them together for anybody to notice anything. I've even seen a triple. These are what you run into in integration and later in production after everything is supposedly tested and debugged. You can't find these with unit testing. Only in combination can you even see that it is a bug. Both of them.

If there is a bug in the spec, that is enough to ensure that any implementation is buggy. Buggy if it follows the spec. Buggy because it does not follow the spec. The spec being wrong cannot make any implementation right.

Re:Unit testing?

[arafel]

Along with a test suite which builds into it the assumptions you made (without being aware of them) while writing the main code. It's unavoidable.

It's probably also worth noting that I wasn't suggesting QA people write the tests, but other programmers. If you have two people writing two lumps of code, ideally they should write each other's test harnesses.

(I realise this isn't always practical. Hence the ideally.)

Re:Unit testing?

[pclminion]

Unit testing is no magic bullet.

The motivation to test derives from the observation that all code has bugs. You can't write useful code of any realistic complexity without writing at least a few bugs.

But the unit test driver is, itself, a program. And if the unit it is testing is somewhat complex, then the test program itself will be similarly complex. Thus, the probability of having bugs in the test driver is not negligible.

I have, on more than one occassion, committed code changes that I thought were thoroughly tested, only to discover that the test driver itself was doing something wrong.

So, should we write a test driver for the test driver? Naaah... The solution is code review.

Unit testing is nothing without code review.

Re:Unit testing?

[Anonymous Coward]

Either that or "code that doesn't have tests, doesn't work" is such an idiotic generalization that it's not even worth analyzing logically.

Re:Unit testing?

[WillWare]

Do NOT get the engineer who wrote the code to also write the test. It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work.

The test can be viewed as "our understanding of what this code should be doing", because the test is used to identify when the code is broken. It's a good idea to have the engineer write the test because other people can look at the test and say, "OK, this is how he understood what he was supposed to do." So the test is a public document which can be renegotiated by management, for instance, "oops, you forgot to test this case".

I think the situation you're worried about is where an engineer is keenly aware of some parts of a problem and mostly unaware of some others, so he writes tests for the stuff he knows, and ignores the stuff he doesn't. And of course his tests pass because he's not testing what's broken. That's why the test has to be a negotiated public document that other people get to critique. But there's no reason the engineer can't write the test. He just can't arbitrarily veto his managers about what needs testing.

Re:Unit testing?

[master_p]

Neither did I see 'programming by contract'.

Re:Unit testing?

[richieb]

you (and many others) are confusing software requirements with design and implementation. if you can conceive it to write the code you *can* write some level of requirements.

I'm not confusing the two. It just typically precise requirements do not exist. One way to write down requirements precisely is to write tests.

For example, let's say I need to write a code to compute the square root and the requirement is that the result is good to 5 decimal places and it's always computed in 5 milliseconds.

I can write a test to the function before writing the function. Running the test verifies that the code conforms to the requirement. Nothing about design here.

In Real Life (TM), requirements are rarely this precise. Sometimes you find things out when you build the system, sometime you find things out when your customer start using the system.

Certainly requirements determine how the system is to be built. There is difference between serving 10 users or 10,000. These types of requirements are much harder to test.

But I have seen cases where a system designed for one user had to be scaled to 10,000. And the scalibility requirement only came up after the success of sigle user version.

Re:Unit testing?

[richieb]

1) I have ALWAYS been taught, and agree, that the author of a block of code, prose, whatever should NEVER perform the testing(or review, correctness evaluation, etc.) Why? The author will tend to write tests that only test for the obvious, i.e. the functionality as intended, and tend to overlook unexpected inputs/results.

Actually there is nothing wrong with writing a test that tests the obvious functionality. It may seem stupid at first, but later as the system grows someone else will make the change that breaks the basic tests.

For example, when I write code that stores data in the database, I always write a stupid test that stores some data and the retrieves it. Few times these tests broke, because of some other changes later in the life of the project. Without the test we could have wasted hours or days trying to track down a stupid problem.

2) While it is true in some cases that the projects ARE new and requirements difficult to write, the vast majority of software projects today do involve re-inventing the wheel to a degree. i.e. MANY projects are not REALLY creating something new, but just doing it in a slightly different way, and in such cases it should be entirely possible to a minimum define a high level functional document before implementation.

Sure, a high level document that sketches out the top level requirements is needed. But it is useful only as a guide to design and implementation.

Tests can represent very precise requirements, which cannot really come from a high level document. And if you are telling me that I should be writing very detailed requirement doc that no one will read, I'd rather spent my time writing tests (which people can read too) which will verify that the system fulfills the requirements.

Re:Unit testing?

[Anonymous Coward]

Why not make one of the requirements be "expansion"? I understand your point, and I think it has validity. But requirements ARE essential (when used properly) when developing software. It helps keep things in check, the program on track, and gives developers restrictions. You need a workable piece of software before you can expand into the unknown. If you are saying: that because you are designing software that is unknown, you cannot classify requirements for it, I think you are conclusively wrong. "Unknown" software especially, demands requirements. If you assume, that "unknown" software starts with an idea, if you do not require this idea to be classified into a requirement, then where does this idea stop? I do agree that requirements shouldn't be the do all, end all... because software is complex, and it grows exponentially complex with the size of its code base. However, if you want to get a program out the door, I think requirements allow you to konw where that doorframe is, so you can step through it in the first place.

Re:Unit testing?

[fupeg]

But that's really the reason it's not done all that often.

That is just not true, at least in my experience. Proper unit testing is a significant up-front tax on development time. It's time that you have to account for at the beginning of any project and that makes it very unsavory. It looks bad on a project plan, either as seperate items or as huge amounts of time for coding even the simplest of things. That's why it gets cut. Most engineers that I've worked with would much rather be allotted more time for development with unit testing than less time for development without. Most write unit tests, even when not allotted time for it. They usually can't get the kind of coverage one would want and they tests are not included in any kind of organized suite. I have worked places where testing was mandatory, and the dev times were significantly longer. It's the classic software engineering equation : Quality is proportional to Time multiplied by Money. With Money decreasing (see recession, offshoring) and constant pressure on Time to decrease, of course Quality decreases as well. "Tools" can change the equation some by increasing the constant of proportionality, which is basically one of the "insights" of Cox...

Re:Unit testing?

[deranged unix nut]

I was talking about post-compiler unit tests, but you make a good point.

The compiler catches a lot of things...and the programmers usually fix those before they attempt to check-in their changes.

Once they check-in, build, and run the unit tests specifically written for their application or feature, in my experience 95% of those tests don't find any bugs after the initial set of test-development bugs are found and fixed.

Re:Unit testing?

[GileadGreene]

You need a workable piece of software before you can expand into the unknown.

More importantly, you need an adequate definition of what constitutes "workable". That definition is the requirements.

I think that the mistake that people make is that they assume requirements should be set in stone. That's not necessarily true. Ok, admittedly it'd be nice. But realistically it never happens. Requirements do evolve during the design/development process. What the requirements provide is an instantaneous snapshot of what everyone agrees the system is supposed to do when it is finished - they are the agreed upon criteria for a successful system.

Re:Unit testing?

[Phragmen-Lindelof]

How was problem discovered?
Is this attempted hack a "simple trivial bug" or an "interesting bug"?

Re:Unit testing?

[dubl-u]

But I've come to realize, it [unit testing] just doesn't help to reduce big errors in system level design.

That's like saying that street maps don't tell you what the continent looks like. It's technically true, but it seems to miss the point.

Unit tests are for testing relatively small chunks of work. If you want to be sure the pieces work together, you do testing at higher levels. I think both are necessary for a solid system.

Personally, I think of my high-level tests as executable requirements. Every time I check in code, a server makes sure that all our tests, both unit and end-to-end, run happily. That's a big step up from the traditional requirements phone book that most people don't use except as an aid to yelling at someone.

Re:Unit testing?

[dubl-u]

If you write some code that reads several rows from a database and as a result writes a bunch of rows in another table, you need to run scripts before and after your unittest.

When something is hard to do, one option is to try a different way of doing this.

In the case of database interaction, mocking things out is a good step. A unit test might only verify that your code produces the proper SQL and interprets mock ResultSet objects properly; it need not talk to a real database.

Also, you probably shouldn't be scattering SQL everywhere throughout your app. If you isolate the SQL to a mapping layer, it's pretty easy to test that the mapping layer works with the database; then all the rest of the unit tests can use a mock database interface. Not only is that easier to test, but it's much, much faster.

It's of course all doable, it's just that it's sometimes more work than writing the method itself.

True, but irrelevant. The time to compare it to is not just the amount of time it takes to write the code, but also the amount of time you spend debugging that code over its lifetime. I do test-driven development in an XP shop. Our bug rates in production are lower than one per developer-month, and I spend perhaps 10 minutes a week using the debugger.

In my experience, the time and stress saved by doing extensive testing is well worth the time we spend writing tests. As a bonus, we spend little time writing documentation; if you want to know what some object is supposed to do, the unit tests make it pretty clear.

Re:Unit testing?

[dubl-u]

Do NOT get the engineer who wrote the code to also write the test. It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work. Get someone else to do it and get a valuable fresh insight.

You're acting as if it's either/or. The proper answer is both.

Unit tests verify that the code does what the programmer says it should. If the programmer does test-driven development, the engineer is much less likely to do the kind of shoddy testing you're worried about. The problem is further lessened if you do pair programming.

But I also think it's important to have tests written by other people, ones written from the perspective of the people who say what the requirements are. Those not only verify that the system works, but that the engineers built the right system.

The great thing about unit tests is that programmers can adopt them on their own. There's no need for separate QA, managerial approval, extra meetings, or anything like that. You can just write them because it makes your work easier. And boy howdy, it does.

Re:Unit testing?

[Tony-A]

Good one.
Open Source, with a few eyeballs, simple trivial bug.
Closed Source, after it has been used in an exploit, without access to that source, would be an interesting bug.

Re:Unit testing?

[Anonymous Coward]

here here.

"Hear, hear!".

BTW, are your shift keys broken?

Re:Unit testing?

[Anonymous Coward]

"Anyone ever notice DO-254 (That pesky avionics software development guideline) never mentions unit testing?"

I would venture to guess that fewer than 1% of Slashdot readers had ever heard of DO-254 until they read your post. So, no, nobody here noticed that DO-254 never mentions unit testing.

2 words

[otisg]

unit tests

not a panacea, but it does go far.

Re:2 words

[ceeam]

That's nice thing when you do your project bottom-to-top, i.e. when you have some engine tossing around your data and stuff, and then write UI on top of it. (UI is not very unit-testing-friendly, is it?)

Unfortunately, IMHO, most of software is done as this - let's put pretty gadgets around, cool nice icons, and then we'll do the job in event handlers somehow. Here it all breaks loose.

Why it is done that way is easy to see - managers/supervisors are not interested in you doing smth behind-the-scenes for weeks/months without showing "cool stuff" to them.

Re:2 words

[Anonymous Coward]

UI can be unit tested -- start at the display component level, write a bot to simulate input through your OS (windows messages, X events) and run simulated back-end data outputs and front-end screen scrapes and data inputs. Catch exceptions and weed them out (or document work-arounds). Web apps are particularly easy to do, just build HTML get/post tests.

The UI unit test should focus on 2 things: does it crash, and does it transform the I/O it's supposed to handle in an unexpected way. Either one is an error that automated tools can find and fix, and they're both show-stoppers for end user testing. Usability testing is the proper domain of the end-user test cycle, but you can check to make sure the display is as-designed with a tool.

There's commercial stuff available if you want to test the UI attached to the application, but you really can roll your own component-level tests if you're so inclined. At some scale it will become infeasible to keep building one-off UI test programs (because yes, they are harder than most library testing) but by then you'll either be making enough money or out of business :).

Re:2 words

[Unkle]

I actually had a coworker marked down on his yearly review last year for wanting to write re-usable code. Our manager's (very VERY flawed) opinion was that, though it might be nice to have the re-usable code, just write it for this specific task because it's just easy and fast.

The kicker is, this year that same manager wants to re-use the code that my coworker was origionally going to write.

Re:2 words

[johannesg]

Ha, that's nothing. Long ago I used to work for a company that thought it was a good idea to NEVER reuse code because then you would reuse all the bugs as well. OTOH, they reasoned, if you wrote it from scratch you wouldn't be copying old bugs, thus this was a safer thing to do.

I'll leave the results as an exercise for the reader...

Re:2 words

[Unkle]

To quote another coworker: "You just can't fix stupid."

Re:2 words

[Anonymous Coward]

the answer to that is moron manager.

Remember the golden rule. If you see others getting screwed at work it's time to start looking to leave. Because the incompetence that is screwing the others WILL find it's way to you.

your Manager is incompetent.

Re:2 words

[sootman]

And for those who don't like exercise, I suggest Joel. Samples:

"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!... it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.

One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

Re:2 words

[sootman]

PS: don't miss the follow-up to that piece. Best line ever: "I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked."

Re:2 words

[Phragmen-Lindelof]

You have made a good argument why decades of solid Fortran code developed to do scientific work should be maintained and used rather than rewriten in C.
(OK, I will not say the same thing about COBOL.)

"free" ?

[mirko]

I see that the word "Free" doesn't appear in this story's synopsys.
How would Alan apply his quality methods to projects which member might never meet due to geographical contingencies ?

Re:"free" ?

[Luser5]

How would Alan apply his quality methods to projects which member might never meet due to geographical contingencies?

do you mean a broken internet connection?

Good code...

[TrollBridge]

...isn't just for end-users! If you anticipate that others will be working on future versions/releases of your software, good commenting can make the job SOOOOO much easier for the next codemonkey.

I'd say commenting is doubly important in OSS projects, as it involves many sets of eyes trying to comprehend what you coded.

Re:Good code...

[Dr. Evil]

Commenting must be 100% accurate else it is detrimental to understanding the code.

Sometimes code changes don't result in updated comments...

Once I find an inaccurate comment in somebody's code, I have to start rewriting or deleting all the comments because I can't trust them anymore.

Re:Good code...

[Anonymous Coward]

Agreed.

I myself was a big commenter until I realized that when I read others' code I never read the comments. Comments tend to state the obvious and not tell you what you really want to know. I think it is more important to write the code itself in the most transparent way --- meaning not using obscure language features, not being afraid to break slick but unreadable code lines into multiple, stupid-looking-but-obvious lines, etc.

Re:Good code...

[Megasphaera Elsdenii]

Mod parent comment (pun intended) up ... comments are evil. Code should
first and foremost be self-documenting, by the
choice of proper variable names and subroutine
names. Only comment things that are not obvious,
like tricks that are employed. The point is that
comments are not read nearly as much as names,
and get stale more quickly, rendering them useless.

Re:Good code...

[johannesg]

That, and good naming of variables / functions / classes. To clear up any possible confusion: that means that the name has some bearing on what the thing in question is doing for you...

Recently I had the misfortune to wade through a few hundred kilobytes of Java that was written by someone who thought he should 'abstract' everything as much as was humanly possible. Sounds good, right? Well... It turns you can do a lot of harm that way, too. I don't think he had a single function in there that _wasn't_ called something like SetProperty(), GetValue(), DoFunction(), etc. There was absolutely no way to guess what it was doing based on the name of the functions. Naming of classes and variables wasn't much better. After looking at it for a couple of hours I don't think I could have guessed what it was trying to do if I hadn't already known that beforehand.

So, next time you are writing software, feel free to get in touch with reality and name stuff after what it is supposed to be doing. Nice long names please, no abbreviations unless you go over 30 or 40 characters. Down with CmtPmt2Db(), down with SCUPD(), and down with GetPropertyValueInterfaceCaller()!

Because, be honest: those mean nothing, while CommitPaymentToDatabase(), ScreenUpdate(), and GetXLocation(), have intuitive meanings we all understand...

Re:Good code...

[GooberToo]

I hear this a lot, but what's really the problem here? Is it because the comments poorly aged or because a programmer didn't do his job? What's the cure? Stop commenting or make sure your coders are properly doing their job?

Re:Good code...

[gidds]

Comments tend to state the obvious and not tell you what you really want to know.

This is a reason to write better comments, not to avoid them completely!

Of course comments that are flippin' obvious, or wrong, do no good to anyone. But some sorts of comments can be incredibly helpful:

• Big-picture comments. Explaining what this function, method, class, file, or interface is doing; how it fits into the app or system; important design decisions. Also authorship and date information, if that's important.
• API comments. Describing the implicit (or explicit!) contract that a function, method, class or whatever has with its caller. When you should be calling this code, what the caller needs to have set up beforehand, what the code guarantees to do in return, any gotchas.
• Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.
• Here-be-dragons comments. Describing tricks, shortcuts and other hacks. Better to make the code clear and obvious, of course, but there are times when a clever technique or bit of magic is needed, and for those rare occasions, a few words of explanation can make things so much clearer -- and prevent someone ignorantly 'fixing' it later!

Of course, there's some overlap. But these are the sorts of things that can make code so much easier to read, and don't take much effort to maintain. The big-picture and API comments tend to be common practice in literate languages like Java (JavaDoc) and Perl (POD), but too many people don't follow it -- and even where those comments aren't extracted automatically, they can still be incredibly useful.

My rule of thumb is: Try to make the code itself obvious. And comment everything else!

Re:Good code...

[Anonymous Coward]

Recently I had the misfortune to wade through a few hundred kilobytes of Java that was written by someone who thought he should 'abstract' everything as much as was humanly possible. Sounds good, right? Well... It turns you can do a lot of harm that way, too. I don't think he had a single function in there that _wasn't_ called something like SetProperty(), GetValue(), DoFunction(), etc. There was absolutely no way to guess what it was doing based on the name of the functions. Naming of classes and variables wasn't much better. After looking at it for a couple of hours I don't think I could have guessed what it was trying to do if I hadn't already known that beforehand.

It sounds like the programmer was doing some sort of dynamic JavaBean stuff. Abstracting things out to the level you indicated makes sense in some cases, but you certainly don't want to expose this stuff at the API level.

That type of code can help when your building a framework to use for the rest of the application, or if you're trying to simplify things to the point where you can write an active code generator more easily. I'm going to venture a guess that this wasn't what was going on in your case.

Re:Good code...

[angel'o'sphere]

Commenting must be 100% accurate else it is detrimental to understanding the code.

Sometimes code changes don't result in updated comments...

Thats why we do not comment code :D

No thats not a joke. Besides comments for method parameters and one sentence description for the method and the class/interface containing it, we don't comment!

However we have strikt coding guidelines. Not more than two control structures per method (e.g. a for loop with a nested if).

We use refactorings a lot (e.g. extract method, rename method, extract class, rename class) to ensure the code is understandable by itself.

Of course there are exceptions. If you fiddle with bits or a loop has a strange ending condition a comment is used, or the condition is coded into a speaking variable or method name.

angel'o'sphere

Re:Good code...

[ZorroXXX]

As written in Refactoring by Martin Fowler:
Don't worry, we aren't saying that people shouldn't write comments. ... The reason that we mention comments here is that comments often are used as a deodorant. It's surprising how often you look at thickly commented code and notice that the comments are there because the code is bad.

The best type of code is that kind that does not need to be commented. In my oppinion there are three ways to write code:

1. Write unreadable code:

2. if (some_var == 0x4D) {
   do_whatever();
   }
   

3. Write unreadable code and comment it readable:

4. if (some_var == 0x4D) { // 0x4D means WHATEVER
   do_whatever();
   }
   

5. Write readable code:

6. enum {WHATEVER = 0x4D};
   ...
   if (some_var == WHATEVER) {
   do_whatever();
   }
   

One thing that annoys me tremendously is people that write comments on #endif even when the #ifdef is two lines above! What is the difference between

#ifdef NEED_WHATEVER
#include "whatever.h"
#endif // NEED_WHATEVER

and

i++; // increment i by one

? The comment adds no value and is just noice.

Re:Good code...

[ajs318]

You see, that's the point. There's no point being too clever -- you can use the programming language itself as a sort of "generality-of-purpose abstraction layer". After all, if a language is computationally complete then as a matter of definition, any task you might want to perform can be implemented using that language. There is no shame in writing a program to do just the thing it has to do. It's far better to be able to play one song all the way through from start to finish with no mistakes, than any number of fancy riffs and bits of verses.

Code that you've written once for one specific purpose can be picked apart and made to do something different later if you ever need to -- and you might not. Just keep the thought at the back of your mind that you may need to make something a little more general-purpose, so as to make sure you will be able to do it when the time comes. That will mean intelligent use of comments and choice of variable names. If you're following KISS principles anyway, it should be almost obvious what something is doing.

I once wrote a function to send a MIME-formatted e-mail with exactly two attachments, and did not feel even slightly guilty about it; because that was what it had to do. Sure, later I did need to be able to send three attachments, or just one; but it was much easier to extend something that had already proved itself sending two attachments, than to write something from the outset that could handle an arbitrary number of attachments. The bits that needed to be altered to use loops and arrays stood out much more clearly once I was seeing them hard-coded with separate statements and separate variables.

Extraneous generality of purpose is really just a form of cruft. It just makes your code harder to write {because you have to consider other things beyond the problem you were originally considering} and harder to test {because you have inevitably introduced more ways to break it}.

Re:Good code...

[Dan667]

You my friend may never retain a job with an attitude like that.

you see his code?
yea, i cannot make heads or tails of it, but it works really well. ok, better take him off the list

Re:Good code...

[16K Ram Pack]

Good errr.. comments.

I've seen huge comment blocks in code that explain a piece of code that is obvious even on first observation. It's just adding something you don't need.

You are right as well. Most people explain what a system does in terms of an analytical code breakdown, NOT what the purpose of the piece of code is.

The biggest one is the here-be-dragons. If you read one of my programs, you can occassionally find something with quite a large comment block, and in there, I'm often explaining in quite a lot of detail exactly WHY I had to write some quite offensive looking code that I did.

To me, it helps to pass on mindset of the code as you go as well. If people understand your thinking, the rest of what you do will flow from it.

Re:Good code...

[Anonymous Coward]

Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.

Even better: just make the "sections" a separate function and give them good names.

Re:Good code...

[gidds]

Well, yes... That's usually a better solution. But sometimes the separate sections are too closely related, too interdependent to be worth doing that. It's generally better to split stuff up, to reduce dependencies; but ultimately, it depends on what the code's doing and how it's organised -- you have to use your judgement instead of blindly following rules.

Also, often function names don't seem to be as meaningful as the author thought. How many 'processFile' functions have been written, and how much does that name tell you?

Oh, and another type of comment I missed out:

• Assumption comments. You know the sort of thing: "// Don't bother checking for <special case> because it will have been handled <above>". Not only do these stop someone else puzzling over why something 'obvious' has been left out, but in making your assumptions explicit, they sometimes show you where those assumptions are wrong, or where later code changes make them so.

Re:Good code...

[iabervon]

Comments are valuable at a relatively high level, where you describe what the code is supposed to do. The code itself documents what it actually does, but there's no way for a person reading it later to determine if it is doing what it is supposed to do without a comment that explains the intent. For example: "// Long divide in place, junking the data, but leaving the reminder" is very useful to the person who comes along later and doesn't know that the code actually wants this odd result, and wouldn't have a chance of figuring it out if the code didn't compute it correctly due to a bug.

Re:Good code...

[fyngyrz]

One thing that annoys me tremendously is people that write comments on #endif even when the #ifdef is two lines above!

The reason to mark a block end like that habitually - in other words, when you first lay down the ifdef and endif - and thus leave some things like your examples around (which is a reasonably harmless thing to do, you must admit) is because any block may expand, and you're smart to write the block thus:

#ifdef NEED_WHATEVER
#include "whatever.h"
#endif // NEED_WHATEVER

...because later it could easily look like:

#ifdef NEED_WHATEVER
#include "precursor_conditionals.h"
#include "whatever.h"
#include "this_other_thing.h"
#include "that_thing_i_forgot.h"
#include "later_revised_defines.h"
#ifdef BUG_NOT_FIXED_YET
#include "oops.h"
#endif // BUG_NOT_FIXED_YET
#include "next_os_level.h"
#include "128_bit_constants.h"
#include "egyptian_glyphs.h"
#include "oh_yeah_that.h"
#include "new_memory_allocator.h"
#endif // NEED_WHATEVER

...and similarly, there is no telling when you start coding something in the main code just how much thick codey goodness you will want to slip into that warm and wet set of braces. :)

This applies to any kind of block - defines, truth based control structures, looping, conceptual stepwise blocks, etc.

Re:Good code...

[Anonymous Coward]

What is the difference between

#ifdef NEED_WHATEVER
#include "whatever.h"
#endif // NEED_WHATEVER

and
i++; // increment i by one


Case A is a form of defensive programming: programming for maintainability.

If some future developer adds 60 lines between the #ifdef and the #endif, suddenly the comment becomes more useful -- the start of the block may be off the screen, but one can still (quickly) read what it's purpose had been.

You can try to persuade maintainers to conform with coding standards that say if a developer increases the "distance" between the start and end point by over N lines, then the code needs to have the comment added. Or you can just comment every end block, and use the opportunity to help document the code.

Which would you rather see at the bottom of your screen when trying to fix a time critical production bug? Note that only difference is in the comments.

}
$x++;
}
$y++;
}
return(z++);
}

or

} # end loop over sql query results
$x++;
} # end widget classification (default)
$y++;
} # end customer exists check (not found)
return($z++);
} # end count_unsatisfied_widget_owners()

I think the second example is more descriptive, don't you? (And yes, the variable names need work, I was trying to concoct a general example, not demonstrate good coding style. My browser doesn't want to let me enter tabs, either, so the formatting is off. Sorry.)

As for case B, the commented i++, it may or may not be a bad idea. It depends on the language at hand: if ++ always means "increment by one", then yes, it's a valueless comment.

If ++ is considered an operation that isn't obvious to a junior programmer, then it sholdn't be commented, it should be avoided. It should only be used if it provides a benefit to the program. If that benefit that is not obvious to a junior programmer (performance improvement, tricky side effects, better error handling, etc.), then the benefit of the choice is what should be commented.

As a ficticious example, one might write:

e.g. i++; // 10 times faster than i=i+1 on gcc 2.1

If ++ is a frequently overloaded operator that is used a lot throughout the program to compute, say, the successor element of a composite object, then it may well be helpful to be reminded that the usual behavior for the program is *NOT* being followed, and a normal increment is all that's being done. In either case, the wording of the comment is a poor choice, should be improved.
--
AC

Re:Good code...

[ZorroXXX]

> (which is a reasonably harmless thing to do, you must admit)

No it is not harmless. It adds noice to the source code which decreases the signal to noice ration and makes the code harder to read. That is an unforgivable sin. Code is written just once (or rather in the range 1 to 10 times taking editing into account) by one or a few persons. However code is easily read thousands of times by many many people. Having code that is easily readable is essensial and several orders of magnitude more important than writing the code.

>...because later it could easily look like:

There you hit the nail on the head. You shall not add add commets now that maybe perhaps might be usefull sometime in the future (see YAGNI or here ).

In your example the "// NEED_WHATEVER" comment is acceptable while "// BUG_NOT_FIXED_YET" is not. My personal perception of this is that with more than half a screen height between ifdef and endif, adding comments is ok. With only one line inbetween it is absolutely not.

Re:Good code...

[Dr. Evil]

While comments tend to get inaccurate quickly, I think you're right about high-level comments.

Lately when writing code by myself, I've been writing comments before the code... I mean temporally. Write some high-level steps. Find some commonalities in those steps, create functions which contain blobs of steps. I'll also create verbose decriptions of key variables.

Then I'll do a second pass, writing in loops to touch objects or do whatever, but instead of doing any dirtywork, the actions are all program stubs. Then I verify the logic is good.

I then create a set of tests which call on the functions, trying to test their premises and break them.

Then I start replacing the stubs with print-like statements of the code which will be replacing them, so that I can see in sequence what kind of actions will be run.

Then I run the tests again... adding to them if necessary

I then start replacing the print-like statements with live codes, the print-like statements being redirected into debugging output.

Finally, I'll write the "real" app, which draws upon all the routines in the proper form, following pretty close to the steps above. This goes really fast because the tests usually make great templates for the final app. The tests also act as supplimentary function documentation.

Lots of comments get deleted in the process, but a few describing the flow logic remain. They're generally good comments and can be mapped onto the original design documents (scraps of paper with flow diagrams and stuff).

Again, this is only when I'm the only coder. For most purposes, if I have somebody helping me, they get flustered when I try to spend time defining clear interfaces or provide stub functions for them to code against... "What is this? This isn't done? This doesn't do anything? I could write this cr*p! What is this "stub" sh!t! What do you mean I can't use a global variable to pass parameters to my function!". But I nor they are professional programmers, I just wind up doing a fair bit of scripting and coding in my job. I've only had one coworker who understood clearly defined interfaces... but then that was also because we didn't understand one another's programming languages or environments. I could pass them the interface rules and they had to code against them blindly. They were thrilled when they saw stub routines triggered by their code and vice-versa.

Re:Good code...

[fyngyrz]

The thing is, if you add the comments up front, while you're thinking about the block definition, rather than what you presume to be its future contents, then you (and others) don't have to worry about it again. It's been correct from the first few seconds it was written, and readability is significantly enhanced.

We have a similar rule for writing braced entities: Write the containment structure before you write the contained elements.

So writing this top to bottom, then filling in the parens and the braces...

if ()
{
}

...is correct, while writing this top to bottom...

if (conditions)
{
conditional code
}

...is not.

Anyway, you're certainly entitled to write code any way you want in your own world. Here, I would consider your approach both defective and destructive, and if you refused to comply with my company's requirement to document your blocks and write your structures in an organized manner, I'd simply fire you for cause. It's great to be the boss, sometimes. Everybody does it my way, and I give them lots of money in return. :)

Re:Good code...

[Anonymous Coward]

Surely a better way to handle these assumptions is to make them assertions in your code. That way you can test if your assumptions are correct.

There's nothing worse than trying to debug someone's code, looking at the comments for the function parameters and see "variable x will never be 0" and finding that it can be zero.
A least an assertion would cause the code to fail immediately (assuming the developer does any testing)

Don't even start me on the evilness of comments like

//this function take a char* and fills it with the value of the employee's name if the employee exists otherwise it does nothing. This function returns void
void gtEpNm(char* arg);

whereas:

void getEmployeeNameIfExists(char* buffer);

is a hell of a lot more readable

Re:Good code...

[gidds]

Well, yes, assertions are (almost) always a good idea. If you can test with an assertion, then great!

I was thinking more of things that couldn't be tested with an assertion; higher-level stuff more to do with thought processes and algorithms than with variables and conditions.

And in your example, I agree that the longer function and parameter names are much more readable. But I think that a comment is often useful too. For example, the name alone doesn't make clear what happens if the employee doesn't exist; does it write an empty string? Write nothing? Display an error? And so on. What format is the name in? Is the function thread-safe? Does it rely on an existing database connection? There are always things to consider that won't fit in a simple name, however long.

As I said: make as much clear in the code as you can, and comment everything else!

Alan Cox

[Anonymous Coward]

Who cares about what Alan Cox has to say? He's soooo 2.4

Re:Alan Cox

[Anonymous Coward]

Maybe Linus will come out with some patches for an -lt version of this talk.

I tried to Ping Wales...

[Anonymous Coward]

...but all I got was krill.

Code review and pair programming

[Frans Faase]

The most effective techniques for finding defects is still code review. It seems that one of the pair programming is a very good way of doing code review.

However the greatest problem with writing good software is still in the marketing. In order to sell/license software it needs to have features, and the lack of defect often does not count as "features".

Re:Code review and pair programming

[ZorbaTHut]

Funny, that. I recently started working at a company with mandatory code reviews. Here's a list of my recent experiences with it:

1) Checked in code. Spent fifteen minutes justifying design decisions. No changes made.

2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.

3) Checked in code. Defended my design against several more computationally expensive suggestions that were also more complicated. No changes made.

4) Listened to a friend gripe about having to spend a DAY AND A HALF repeating design reasons and fixing bugs introduced by his code reviewer "cleaning up" his code.

5) Received company-wide email about a build that flat-out didn't compile - apparently someone hadn't bothered compiling a patch, and had sent it to a code reviewer, who likewise hadn't bothered compiling it before authorizing it.

Now I'll admit that there are also a whole lot of "well, it only took five minutes, so it wasn't much of a waste" cases. But so far I haven't heard one person talking about how useful the mandatory code reviews are.

Maybe it's just an artifact of the kind of programmers working at this company, or the kind of code being worked on, but so far code reviews have been a net loss in my experience. I've taken to doing major changes in my own personal branch of the repository (which doesn't enforce the code-review requirement) and in a month or two I'll have 3000 lines of code for someone to look at - but at least I won't have nickel-and-dimed them to death with 120 100-line code reviews, 3/4 of which I will inevitably end up deleting entirely.

Note that I'm not saying "code reviews are bad" - what I am saying is that there's a time and a place for just about every technique, and there's also a time and a place where each technique is worse than useless. Pick your battles and pick your tools.

Re:Code review and pair programming

[Unkle]

Sounds like your company has a bad process. Having a formal code review after each check in is crazy. Reviewing code when a task is declared completed makes more sense, or even doing regularly scheduled reviews.

Our company has some loose rules (we're working on strengthening them) that state that checked in code must be unit tested. This is to prevent things like your #5. But we haven't gotten to code reviews yet. Being on the team that's working on our process, I'll remember your experiences when we get to code reviews.

Re:Code review and pair programming

[MHleads]

The most effective techniques for finding defects is still code review.

Bang on target, though I don't completely agree with pair progamming! In fact, start with peer review before doing unit testing. Reviews can locate a spectrum of problems from the obvious (for reviewers and not programmer!) bugs to the complicated bugs which can possibly affect other components of the system.

Re:Code review and pair programming

[Alan Cox]

If you are bug hunting then the code review needs to be an explanation of what the code does. "We get a foo, we have to decide if its in US or UK format so we compute both checksums and .. oh umm.. I'll come back later'

It's very different to things like design reviews. They have their place too. A lot of things Linus rejects are really design review things. Its not uncommon to get a "Yes this needs fixing but do it this way instead". It works well providing the person saying that has good judgement.

Bad code review, bad tools, bad compilers and bad managers are _all_ useless

Re:Code review and pair programming

[someme2]

[... Examples of how code reviews slowed down this guy's work without doing any good ...]

If this happens to you on a regular basis then you are probably a better-than-average developer. Which is just fine as long as we find a way to make your work more average. And code reviews seem to do the job.

Seriously, the productivity spread between developers (20 times as effective... adding more people... Thank you Mr. DeMarco) is what a lot of very strict process models and practices (such as code reviews) really attack - and it is a good thing, too. Because otherwise developer workforce does not scale well.

The productivity spread is the enemy of plans, predictions, estimations and bureaucracy. Bureaucracy is the most successful human scaling mechanism.

In other news: Big cooperations have difficulty exploiting the individual genius of low-level members of their workforce.

Re: Code review and pair programming

[gidds]

Sounds like you've had a rough deal -- or there are some real idiots in your workplace; even code reviews can't solve everything!

But I doubt they've been a total waste. For example, knowing their code is going to be reviewed soon makes some people write better code. And in explaining your design decisions, maybe your listener(s) learned something about design. (Or maybe you did!)

My own feeling is that code reviews can be a great way of sharing knowledge about the system, and about development generally, e.g. best practices; they can help to ensure that code doesn't just work but is maintainable; and they can often spot certain types of mistakes. But everyone needs to treat them as a useful and constructive time, otherwise it won't be...

Re:Code review and pair programming

[jeremyp]

My understanding of a code review is that you and the reviewer(s) get together and walk through the code line by line. If asll you're doing is checking the code in and at some later date somebody else is glancing over it to see if it is OK, you're doing it wrong.

Furthermore, having the code reviewer "fix" your code is wrong on so many levels e.g. if you do something badly, it should be your job to fix it, otherwise you'll never learn to do it properly. As in the case you mention the reviewer might have an incomplete understanding of the code and make it worse. It's also bad for your self esteem to have people redoing your work.

Re:Code review and pair programming

[angel'o'sphere]

This: 2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.

And This:

4) Listened to a friend gripe about having to spend a DAY AND A HALF repeating design reasons and fixing bugs introduced by his code reviewer "cleaning up" his code.

Indicate you are NOT doing CODE REVIEWS.

Obviously no one in your organization seems to know what a code review is!

A code review is either an inspection: the code reviewer does uses a check list stating the formal requirements your code needs to pass, or: a walk through, in that case the author describes his code/design to a formal review team. There are informal reviews as well, without a check list. But those are done after certain criterias are met. E.g. a subsystem has passed all required tests for the current iteration. THEN you do a review.

A review is usually done by a team, not by a single "paired" reviewer.

angel'o'sphere

Re:Code review and pair programming

[ZorbaTHut]

In the first case, it did in fact pass all the tests (and I went back and added more tests once it was fixed) - one of those "wow, that bug was so big I didn't imagine we'd ever have to test for it" dealies.

In the second case, writing formal tests wasn't particularly possible - it was a very complicated optimization problem, and it's mighty hard to write unit tests for code that doesn't have a designated "correct result". (I'm running into the same problem with my current codebase - I'm testing all the deterministic stuff I can, but in the end, the complicated testing is me looking at the output and saying "yup, yup, that looks good".)

Re:Code review and pair programming

[angel'o'sphere]

Probably you should write your tests then some levels higher :D

Usually we start with "inputs" simulating a user. Stubbing out classes where we access outside resources (like DBs).

Now you get an impression (test wise) how your whole code (as a block) behaves versus outside stimuli.

With a debugger you can trace into some deeper levels and figure input values. Supposing the higher level tests run fine you now have suitable ins and outs for the test cases on lower levels.

From that ground you can encircle the routines with more tests similar to those you have now.

Like this you at least get a regression suit. With a coverage tool you will find gaps in testing and likely get ideas how to tackle those.

angel'o'sphere

Re:Code review and pair programming

[Anonymous Coward]

I think you're blaming the problem you're experiencing on the technique instead of where it truly lies, on the sub-par code review process you have. I've seen both scenarios, code reviews that catch serious bugs, and code reviews that turn into endless debates about style, etc. In my projects, I always recommend code reviews, and our code reviews have rules. Basically, at the point they become counter-productive a rule is being violated. Like any other technique, code reviews must have proper process (rules) to be effective.

Re:Code review and pair programming

[Harri]

Funny, that. I recently started working at a company with mandatory code reviews. Here's a list of my recent experiences with it:

1) Checked in code. Spent fifteen minutes justifying design decisions. No changes made.

2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.

In my experience, although code reviews often suffer from the failings you illustrate, they're invaluable for two reasons that people don't often mention:

• There's one more person that has at least a passing familiarity with each piece of code.
• Each time a reviewer suggests a change, even if it's a ridiculous idea, it allows for a discussion of the principles involved. By the end of everything either the author or the reviewer will have learnt something. It may be frustrating to have to spend time explaining to junior developers things that seem obvious, but it's important if there's to be a new generation of senior developers that know what they're talking about.

Re:Code review and pair programming

[ZorbaTHut]

But there's the thing - I don't have a user. :) I'm just trying to process a large amount of data and get out other useful data, that, presumably, bears some close resemblance to patterns that are probably infeasible to detect exactly (although I'm going to do my best, heh.)

Test suites are *great* when you know what the output of your program is going to be. When you're not even 100% sure what output *format* you'll end up with, to say nothing of the actual output, they end up being a bit less useful.

(Which is not to say I don't have consistency checks scattered all over my code - in fact a few days ago one of the new ones triggered, and I discovered a bug in a very early bit of code that I couldn't have realistically found before. Took me two days to track down, sigh.)

Re:Code review and pair programming

[dubl-u]

The most effective techniques for finding defects is still code review. It seems that one of the pair programming is a very good way of doing code review.

Strongly agreed. Code reviews can be nice, but frequently the good suggestions come too late to be worth implementing. Pair programming gets you the feedback you need before you've gone too far down the wrong path.

Re:Code review and pair programming

[angel'o'sphere]

Then the data is your user :D

When you simulate a user you don#t do any special thing either, you write data files, thats all. And use a driver to load them and pass them into the system.

angel'o'sphere

Slashdotted

[DrJonesAC2]

Anyone have a mirror?

Re:Slashdotted

[DrJonesAC2]

Jerk! I'm at work! You trying to get me fired?!?!

Re:Slashdotted

[Anonymous Coward]

I'm sorry, I realize now that I spelled "ubetcha" wrong.

Re:slashdotted

[castlec]

i guess i should check dates and read the story first.... hahahaha

Re:slashdotted

[bo0ork]

The article that comes up isn't the one referenced in the post. It's dated December 15, 2003, fer crying out loud.

Re:Slashdotted

[Anonymous Coward]

MirrorDot has the mirrors here.

Re:slashdotted

[Anonymous Coward]

Mirrordot.

Re:Slashdotted

[Anonymous Coward]

MirrorDot is only MirrorDotting the first page. Which doesn't have the suggestons on it.

software dev

[antivoid]

I am a professional software developer, and I would like to argue that the top 5 most impportant things about good software is (in order of preference, most preferencial first):

1. Stability
2. Robustness and speed
3. Sufficient comments (one comment every 3 lines)
4. Passing large objects as constant references and not by value
5. Viewing your code in assembler afterwards and using a profiler to look for bottlenecks

Of course, the above mentioned things are not enough, but I believe it is a good place to start. Any other ideas?

Re:software dev

[110010001000]

Viewing your code in assembler? Comment every 3 lines? You must be kidding, or trolling.

The top 5 things are:
1) Meeting the requirements
2) Stability
3) Maintainability
4) Expandibility
5) Efficiency

Re:software dev

[Anonymous Coward]

You said "speed" at number 2. 4 and 5 just reiterate that. Are you a speed freak? Games coder, perhaps? :-)

Robustness is WAY more important than speed. Forget speed. Really. Forget it. Then forget it some more. I'm an assembler coder and I could do without the competition :D

Re:software dev

[Timesprout]

Surprising you dont seem to think good software should meet the users/customers requirements. That would be first on the list for me. Software must do what the user wants or it is a total failure as far as I am concerned. In general I would agree with your points. Code should be robust, testable, maintainable and reasonably performant. I prefer the source code to be documented well and autogenerate documenation from it rather than maintain duplicate documentation.

I am also a big fan of profiling code, and for server apps, proper load testing is and absolute must. It often only finds the low hanging fruit as performance bottle necks tend to be resource based eg the database is usually the 'culprit'. Profiling and code coverage/ code analysis are valuable tools though to identify critical paths and likely sources of problems and help developers gain a clearer picture of how the application actually works.

Re:software dev

[scampiandchips]

You forgot the most important one - it should meet the orginal user specification!

Re:software dev

[Bloater]

I cetainly don't agree with the one comment every three lines. I have a file that I'm particularly proud of implementing a physical memory allocator using a slight variation on the buddy list allocator. It has a block comment at the top of the file detailing the differences from this allocator and the standard buddy list allocator, as well as specifying the invariants. I have one comment within the actual code, marking that a loop termination condition needs checking properly then being put into it's own function/macro. The other comments are all just before each function (which have descriptive names) and mention how/when they should/may be used.

Okay, most of the functions are only 5/6 lines long, but the rule I use for commenting is each separate bit of logic has a comment if the function has non-obvious pre/post-conditions. If you need a comment explaining what some code is *for* or how it *works*, that code should probably be in it's own function (or even file). So the comments, generally, are not muxxed into your code.

I have known several *graduates* that write code like this:

if (a != 'x' && b == 0) { /* if a is not x, and b is zero */
b = 1; /* set b to one */
} else { /* otherwise */
a = 'x'; /* set a to x */
} /* end if */

Gaaahhhh!

Re:software dev

[Just Some Guy]

So am I. My thoughts:

1. A turned-off computer is stable. Stability means nothing unless the results are correct.
2. Robustness - isn't that the same as stability? Also, speed is nice if you can get it without sacrificing correctness, but the real solution to both problems at once is designing good algorithms. If you use methods appropriate to your situation, then the resulting code will be fast, correct, and concise.
3. Not gonna bother. Were you serious about that?
4. You're getting bogged with the implementation of one language.
5. You're getting bogged with the implementation of one language.

I write largish commerce websites - some of which you might've used yourself. I don't care at all about speed because I know that the fundamental algorithms are sound, and the slow parts (such as waiting for approval from a credit card processor) can't be touched anyway. Hand-tuned assembler may be important (albeit likely futile unless you're smarter than a modern optimizing compiler, and very very few people actually are) for your niche product, but in my systems knowing when and where to use an O(n) algorithm versus an O(log n) system with a higher coefficient is infinitely more productive.

Feel free to argue your points, but I doubt that anyone outside your particular coding group will agree with you.

Re:software dev

[eyegone]

As a business major, I only had to take one, very light, CS course. Along with learning how decode punched cards (in the late '80s!), we did have to write a few programs in Waterloo BASIC.

We were required to have a comment on every line. Trying to come up with meaningful comments for trivial lines of code was one of the most aggravating exercises in which I've ever participated.

Re:software dev

[Anonymous Coward]

should meet the current user specification :) which will no doubt be totally different to the original one.

Re:software dev

[antivoid]

Just thought I'd say:
The reason I need to look at code in assembler is that I am an embedded developer; not only in code speed important, but code size. Most serious embedded developers will agree with me.
I do, however also agree with you. For web development where you're using php/asp anyways effienciency isnt neccesary. Like all things in the world, what you need to do is measured by what problem you need to solve :)

Testing is good

[TreadOnUS]

But the real key is reducing the number of defects introduced into software. Testing only finds existing errors. If the number of errors are low from using good requirements, design and development practices then testing becomes less expensive and time consuming.

Re:Testing is good

[djmurdoch]

Testing only finds existing errors.

No, testing finds new errors. That's what test suites are for: to let you know when your change to X caused Y to break.

Re:Testing is good

[Anonymous Coward]

Ahh yes, sounds like an advocate of BDUF (Big Design Up-Front).

Let me clue you in. BDUF doesn't work. Never did. Everyplace I've ever worked that supposedly followed the standard SDLC didn't really. We would get through months of requirements, design, development, and then get into QA and find out the requirements were drastically wrong, and we'd have to change all the precious artifacts we had generated along the way.

Now, if we had followed a more agile methodology, we could have had something working to show the users within a couple of weeks, so they could have decided right away what they really wanted.

Designs can't be created in a vaccuum. They must evolve as the code and the users' understanding evolves.

Re:Testing is good

[TreadOnUS]

Nope, I am not an advocate for BDUF. Even Agile requires that you do some form of requirements development design and code practices. Agile is not, "we have an idea, let's go try it out." Most successful methodologies have many of the same requisites, the differences are in how they are executed. Agile is an iterative methodology with short cycle times, BDUF (waterfall) is not.

A methodolgy should be chosen based on a number of factors. There is no one good methodology for all projects.

BTW, Agile is also an methodology and it too could be a "standard" within a company.

Re:Testing is good

[TreadOnUS]

What you are describing is regression testing. Test suites are good for that because you can automate tests that essentially review existing code to make sure it was not affected. So yes, that form of testing finds "new" errors. But only new error in the code you have a regrssion test for. Now, consider this. A defect is "new" if you haven't seen it before. That doesn't mean it didn't exist for a long time, it only means you might not have caught it until now.

Testing comes in many forms including inpsections, walkthroughs and reviews. These forms of test can be executes on requirements, design and even test cases to find defects in those items.

Re:Testing is good

[Anonymous Coward]

Testing only finds existing errors.

Yes, testing doesn't go far enough. We need to find the errors that don't exist.

That's no mirror!!!

[BlackHawk-666]

That's our old friend goatse.cx

Testing and releasing software

[plcurechax]

My employer produces a large-ish software package, with 10 years of history and a small, 2-3 people, development team. Since I joined we have made massive strides in automating the build process, include some unit tests, and a few smoke tests in an automated process.

Well, the effort paid off. Before we supported one version of HP/UX, and one release of Linux, now we support HP/UX (still a pain), and 4 looking at going to 6 Linux version/distributions and it is less work to produce a release now than ever just a year ago.

Tools like automake, autoconfig, libtool, cvstrac and of course cvs have made my life bearable.

Re:Testing and releasing software

[_|()|\|]

now we support HP/UX (still a pain), and 4 looking at going to 6 Linux version/distributions

Automated building and testing really pay off when adding new platforms. We recently added IA64 Linux. We already supported IA32 Linux and IA64 HP-UX, so we had most of the C and assembler we needed. Great, we should have a new platform by Friday. Well, the automated tests we've accumulated over the last five years found bugs in places I never would have thought to look if I were testing by hand. Now we're adding OS X, and it's the same story: we already support PowerPC AIX, and a bunch of mostly SysV-ish platforms. There have been challenges, like educating people about the difference between dylibs and bundles, but it's manageable.

I develop some testing utilities in C that need to work on all of these platforms, so I deal with the same problems our developers and release engineers do. I'm not integrated with the home-grown build harness the release engineers use, so I've been getting friendly (or at least tolerably acquainted) with autoconf and friends. It's funny: we use Perforce, but I would trade it in a heartbeat for Mozilla's CVS tools. I'd also take Bugzilla over our home-grown bug database.

Re:Testing and releasing software

[Craig Ringer]

Tools like automake, autoconfig, libtool, cvstrac and of course cvs have made my life bearable.

Funny, because they seem to do their best to make my life hell...

I guess I've never seen what it's like without them.

slashdotted

[castlec]

thank god for google the story

Thought is was having a sabbatical?

[Viol8]

Is he back on full time linux development now?

"Alax Cox gave a talk"

Was it in Welsh? :)

Re:Thought is was having a sabbatical?

[Anonymous Coward]

Ha has finished his sabbatical year. He has been doing kernel work for some months already (like fixing the locking of the tty layer)

Pin Wales...

[Anonymous Coward]

We did, and now it has gone.

Come back Wales!

Text Of Article

[Anonymous Coward]

Launch of IT Wales Technical Computing Group- Thursday 23rd September 2004

IT Wales, working in partnership with Know How Wales, Knowledge Exploitation Centre and Cygnus Online, has unveiled plans for an exciting new programme of events specifically targeted at computing professionals from both business and academia.

During the launch breakfast, held in Sketty Hall Swansea, on Thursday 23rd September, Beti Williams, Director of IT Wales, outlined the aims and objectives for the group.

"The IT Wales Advanced Technical Computing Group will help to establish and promote Wales as a country with an international reputation for innovation and excellence in Computing and Information Communication Technologies. It will provide a platform for collaboration between computing professionals from business and academia, enabling them to drive forward the computing industry in Wales and stimulate awareness of the diverse applications of computing. The group will also be well placed to highlight the skills required to meet the future demands of the global computing industries."

Guest speaker Alan Cox, a graduate of the University of Wales Swansea and one of the most influential IT innovators in the world, offered the audience an entertaining and thought provoking insight into the current limitations and human failings of the software development process.

The full programme of events will commence in January 2005 and will link with organisations including the British Computer Society, Welsh E-Science Centre and Natural Computing Forum.

Details will be published through itwales.com and e-mailed directly to IT Wales business club members. For full video footage click on one of the links below

To register interest in receiving information from the Advanced Technical Computing Group e-mail details to info@itwales.com

Presentation:

Real Media File (31kbit, 7.5MB,
320x240res)

mpg video (120kbit, 25.5MB,
160x120res)

High quality DivX and 330kbit mpg files available here

DivX version also available in the business club members section

Questions:

Real Media File (31k, 3.3MB, 320x240 res)

mpg video (120kbit, 11.2MB, 160x120 res)

High quality DivX and 330kbit mpg files available here

DivX version also available in the business club members section

Ping Wales slashdotted already.

[genixia]

Well, they've had the idea of requiring authorization, so the effect is the same.

Anyone got a mirror?

Re:Ping Wales slashdotted already.

[headshrinker]

it's working again after I upped the server processes a bit :)

my first slashdotting, fun.

Gareth

Paths to quality

[Anonymous Coward]

The links seem dead so I will add my .02. The programmer's view of the software should not be confined to the source code control system. Programmers should know how to install and implement the software they design and code. Programmers should have some personal experience supporting the software they code. NOTHING highlights the weaknesses of your software faster than being forced to work a support line/forum, etc. Establish personal relationships with employees in the sales force and management. You will be able to be more influential in the company if you do this. Establish personal relationships with your customers. You can use them to push your agendas. Paying customers have some of the most pull with your company. Use this to your advantage.

Re:Paths to quality

[Anonymous Coward]

Yeah, it's not like programmers are overworked with impossible to meet deadlines and ever growing feature lists. They could easily use their lunch hour working the support desk since they all just live on a strict diet of coffeinated bewerages anyway.

Slashdotted

[Anonymous Coward]

It's slashdotted..

Btw He didn't write it in Welsh did he? Coz Wales officially doesn't exist http://news.bbc.co.uk/1/hi/wales/3715512.stm

A Welsh joke.

[Anonymous Coward]

2 farmers from Lampeter go to Market Day in Carmarthen and have a very successful day and sell all their cattle. They go for a posh lunch in Queen Street at lunchtime before going home.

The waitress walks over and asks, "Menu Sir?" to which they reply, "Bwyd cyntaf, menyw ar ôl"

Code validation tools...

[tcopeland]

...are nifty. They can catch all sorts of stuff and produce lovely reports - or, well, at least functional reports. And running them nightly - or hourly - helps to ensure the code won't get out of sorts.

PLUG: Need to check Java code? Try PMD!

Re:Code validation tools...

[Mr_Silver]

..are nifty. They can catch all sorts of stuff and produce lovely reports - or, well, at least functional reports. And running them nightly - or hourly - helps to ensure the code won't get out of sorts.

Looks really good although I can't program in Java to save my life. As dumb as it sounds, do you know of one for Visual Basic? Google doesn't turn up much but would make my life a hell of a lot easier.

Re:Code validation tools...

[tcopeland]

> do you know of one for Visual Basic?

Sorry, nope, don't know of one. Does Visual Studio include some stuff along those lines? I'm not sure...

Re:Code validation tools...

[coffeeisgood]

One code validation tool for Visual Basic is Compuware DevPartner. I used the evaluation version briefly (under VB 6) and liked it, though the full version was expensive. (I haven't looked at it lately, though.)

Unit testing first

[linuxislandsucks]

You do nto notice major differences until you do unit test first as part of the design process before doing OO code...

Because it is short cutting the design pahse by takign youd own less unworkable roads ti improves the design while decreasing tiem to complete the code..

That is why the phole complete process is called agile!!!

Unit testing after the design is not very effective except to catch where things break after a change

Re:Unit testing first

[johannesg]

Hye, cal lyour pear pro gramign budy! You rtypign skils a ren t up to scrtach wehny our alon e!

Man, if only there were unit tests for slashdot postings... Ah, wait, we have those (lameness filter!) and they don't help at all!

Re:Unit testing first

[Anonymous Coward]

Have you considered unit testing your spelling and typing? :)

Keeping prototypes just that

[mark1348]

You can't help but be frustrated when dealing with projects that were obviously "proof of concept" which then evolved directly into the actual "product". Hard to resist but just plain stupid. I wish more open source projects had strict standards.

Interfaces and contracting...

[LeonardShelby]

Reusable, reliable, quality software begins with the interface. If someone cannot tell what a routine or module does with just a quick read, then all is lost. They'll cease to believe what the documentation (if any) says, and go on to write it themselves.

The solution is better interface design. Clear, concise naming without ambiguity. And including the specification is absolutely necessary. With the contract included as part of the interface, there is even less chance for error and/or any ambiguity. Testing is aided because the rules for calling a routine are right there with the routine interface and comment.

Unfortunately, most programming languages refuse to support contracting in any form, and most developers don't see the benefits. Until this hurdle is breached, quality software will not be achieved.

Steve

--

Re:Interfaces and contracting...

[Anonymous Coward]

Ah, yes, the old "we'll never achieve quality software until my silver bullet is implemented" line, eh?

Quality software is achievable in any language through hard work and discipline. No tool will replace discipline, no matter how silvery and bullety it looks.

Re:Interfaces and contracting...

[LeonardShelby]

I'm not claiming silver bullet status. Far from it. I'm simply stating that software engineering requires contracting and better interface design techniques as part of its standard repetoire. Add these to the hard work and discipline you mention.

(Also note these are not tools, but techniques.)

Re:Interfaces and contracting...

[Tony-A]

Unfortunately, most programming languages refuse to support contracting in any form

Worse, they do not allow you to specify in which direction the information flows. There is no syntactic distinction between an output variable and an input variable. That's like installing a check valve with no indication of which direction.

I suspect that the answer lies in discovering that CALL must be a callable function and that systems must be capable of sufficient isolation that modules cannot interact interact except through defined interfaces. Much more likely to happen with interpreted languages, even with absolute machine efficiency is required. As an old-time Assembly programmer, I'm amazed as how lacking in high-level concepts the "high-level" languages are.

Re:Interfaces and contracting...

[Tony-A]

Quality software is achievable in any language through hard work and discipline. No tool will replace discipline, no matter how silvery and bullety it looks.

Correct. It is achievable in any language in finite time. Given adequate discipline it can be toggled into a machine in machine language. In finite time.

The above is technically correct but irrelevant for what is practicably attainable. It really boils down to matters of efficiency. Effecient use of all limited resources including discipline.
There are no silver bullets, but there are places where the current state of the art is woefully lacking. Handling interfaces now is worse than it was 30 years ago, because there are so many more of them now if for no other reason.

Re:Good sense...

[twoslice]

Sometimes it is just contemplating if it makes good sense. Sort of like "I wonder if it makes good sense to take an Internet browser that connects to the most insecure network on the planet, integrate it completely into the operating system and don't properly validate data that is recieved.

Mirrors Here - Pages and Videos

[Kinetic]

As always, mirrors of the pages and the movies are here: MirrorDot. Enjoy.

Re:Mirrors Here - Pages and Videos

[funcan]

It's only got the first page though - the interesting stuff (like the actual advice) is not mirrored. Did anybody grab a copy before it fell over?

Re:Mirrors Here - Pages and Videos

[Kinetic]

Yah, it is only the first page, but at least MirrorDot got the video files mirrored too (linked on the first page).

There are different types of code reviews...

[Richard Steiner]

We used to implement code reviews at my former workplace, but they were more "sanity checking" peer reviews than anything else. They didn't take very long, and it gave one or two other people a chance to see how understandable or generally logical the changes were.

That type of thing doesn't work as well for large changes, but we found that for small ones it sometimes can be a useful thing.

Re:There are different types of code reviews...

[TreadOnUS]

This type of sanity checking is especially useful for training junior programmers. It can be very instructive for a senior programmer to sit down with a junior progammer and go through their code together. The primary purpose of a review should be to have a second set of eyes on the code but it is very valuable for training and communication as well.

Re:There are different types of code reviews...

[Richard Steiner]

Yes, you're quite right.

That isn't why we implemented it at first (it was initially put in place because we had a few offshore contractors imposed on us and we wanted to do sanity checking of their code before we allowed it on the production system we supported), but we found that such code reviews could also be an excellent teaching tool when someone new came on board.

Great background information

[Mstrgeek]

Here is a source for more information dealing with Software Quality Assurance. I work on an IT help Desk for a state none- profit and quality has always been important to me hope you enjou this information it was a great help to me as an IT Pro.

http://itresearch.forbes.com/rlist/term/Software-Q uality-Assurance.html

Write the tests *first*

[wowbagger]

More importantly, write the tests FIRST. Then write the code, updating the tests for anything that is identified during the coding.

This has several important benefits:

1. You have to DEFINE what the module is to do so that you can write the tests. Granted, the first pass for the "tests" may simply return "failed" until something is written for the module, but at least you will have a chance to think about what you should be testing.
2. You actually DO write the tests, rather than blowing them off. If your manager says "Why aren't you working on $blarg?" you can say "I *am* working on $blarg" since the first step is writing the tests.
3. As you get funtionality working (as demonstrated by the tests passing) you can quickly determine if a later addition to the code breaks the working feature - and fix it while the change is still fresh in your mind (and hopefully BEFORE you commit your changes to the mainline code path (you ARE using a source code control system, aren't you?))
4. You can automate the testing of the system.

Re:Write the tests *first*

[gustgr]

What? Projecting the test cases before the software is written? If you plan to do some black-box testing this is acceptable, once you can plot the test cases based on the software formal specification. But I guess you know there are software testing approachs other than functional (black-box) testing. If you intend to do some structural testing (white box) it is impossible to write test cases before writing the software, once the testing requeriments are defined by analyzing the source code (that's why it is called white box testing).

Re:Write the tests *first*

[Lumpish Scholar]

If you intend to do some structural testing (white box) it is impossible to write test cases before writing the software ...

Three words: test-driven development.

Re:Write the tests *first*

[_|()|\|]

What? Projecting the test cases before the software is written?

It's an iterative process. You don't necessarily write a complete suite of tests for your interfaces before you start writing a single implementation. Someone in QA might think of a unit test as white box, but they tend to be black box from the perspective of the developer. You should be able to write a unit test before writing the unit.

The point of most unit tests is to verify an implementation's conformance to its interface. When you later change the implementation, you would likely invalidate a white-box test or, if it still happens to be valid, weaken its premise.

Re:Write the tests *first*

[fitten]

I do this a bit as well and have found it to be a good approach.

Re:Write the tests *first*

[angel'o'sphere]

If you intend to do some structural testing (white box) it is impossible to write test cases before writing the software, once the testing requeriments are defined by analyzing the source code (that's why it is called white box testing).

This is only partly correct. If you design your software via Use Cases and Scenarios or User Storiers, then the possible pathes are in gereat deals predefined. That means you can do black box tests with out any need of white box tests.
To check wether your black box test cover all the code you do a coverage analysis.

White Box tests finally have total different goal!

With doing black box tests, you do tests driven from the outside, usually according to some spec. What you most of the time don't know is wether the spec is closed (has no gaps, does not leave undefined inputs open) etc. The goal is to ensure all legal inputs work.
So you use inspections to spot places where all the black box tests likely won't reach into. E.G. the coverage tool will show you such lines of code. Now you make your white box tests to "cover" those lines as well. The goal then is to catch "illegal" inputs and to ensure the code does at least accept them gracefully.
The question what to do depends on your over all goals and risks. In business applicatins its usually "good enough" to have balck box tests which cover all lines of code.
In an avionic system, thats NOT enough. Here white box tests are much more important.
Finnaly, the way you test affects your system architecture. The way you ensure robustness affects your system performance. And so on ...
angel'o'sphere

Re:Write the tests *first*

[TheLink]

"More importantly, write the tests FIRST. Then write the code"

But write which tests first? There are so many possible. Usually there are more ways for something to malfunction than for it to function correctly.

How do you write a test to check that a banking application does not allow a customer to cancel other customer's cheques? How do you write a test to check that someone didn't allow sql injection? How do you write a test to ensure that a user account cannot do what it is not authorized to?

Since there are usually more ways to test something to check limits than to use it within the limits, your suggestion makes changes a lot more expensive. If you do the code first (and haven't finished writing the 10 tests for it) and people say "We don't like the way that works in practice", you haven't wasted time writing 10 tests. Whereas if you do it the other way round, they can only find out they don't like it after you've written the 10 tests AND the actual code.

Your suggestion probably works well for certain scenarios, but appears counterproductive for many others.

Re:Write the tests *first*

[hachete]

There are some more reasons:

1. You can be more confident when you begin refactoring mature code-bases. This for me is the clincher as code never stands still but the tests can be a constant. A permanent measure.

2. If it's an API, you have working examples to show people.

3. for years, I used informal, undocumented tests. Handing-over was always going to be bad. Now, hand-overs are a, uh, doddle.

4. Progress. Nothing like some concrete test results to show people. Most test suits show results as HTML. Put them on your intranet.

h.

Re:Write the tests *first*

[Surt]

"How do you write a test to check that a banking application does not allow a customer to cancel other customer's cheques? "

Umm, you call the cancel function with one customer's check and a different customer, and verify that it fails.

"How do you write a test to check that someone didn't allow sql injection?"

You enumerate the functions calling sql and attempt sql injection on all of them.

"How do you write a test to ensure that a user account cannot do what it is not authorized to?"

You make sure your design included an authorization component, and you test the invalid combinations of authorization. You make sure that the accessors of the system all have appropriate scope so that access to the data without passing through authorization is compile time impossible.

Re:Write the tests *first*

[wowbagger]

First, you confuse "unit testing" with "application testing". You are writing the tests for a *part* of the app, not the whole. So, to use your example, you are writing the tests for parsing a customer's auto-pay entries - not the whole app.

SO:

Your first unit test is a simple "return pass"

You run your test framework and verify everything works.

Commit the changes into the main line branch.

You then change your unit test to "return fail". Run test framework and verify it fails. (NOTE: You do all of this IN YOUR PERSONAL DEVEL BRANCH, not in the mainline code.)

Now, define the first tests for your function - test that it does what is is supposed to do. In this example you would define some simple, correct auto-pay setups and submit them to your module, and confirm the module returns the correct data. At this point, you are now FORCED to give some consideration as to what the inputs, outputs, and API will look like - one of the benefits of this approach.

You now start on the module, creating a stub routine that does nothing.

Run the tests - they should fail as you are not yet "doing what you are supposed to be doing".

Implement the module. If, during this part you discover you have to change the API you also change the tests as needed. Run the tests as you go.

Eventually, you will have a pass - your module is "doing what is is supposed to be doing". Now you add more test data - different valid transactions, and different invalid transactions. You modify the test to pass IF the valid operations pass AND IF the invalid operations are detected and correctly failed.

Run the tests. Watch them fail as your module barfs on the bad data.

Fix the module to deal with the bad data. Run tests. Repeat until tests pass.

Do code review on module. Sally spots a potential problem. Add test case to test. Verify tests fail. Fix problem. Repeat until module passes review.

Merge module and test with mainline code branch and re-run tests.

Now, you have a set of tests for your "auto-pay setup" module. Meanwhile, the others who are implementing the "generate statement", "send bills", and suchlike modules have done the same, so your test framework validates each module. The idea is to limit the scope of failures - you prove each module behaves itself, so the number of possible failures AT THE APP LEVEL is greatly reduced.

Now, George finds a case that causes you module to barf, and writes a bug in the bug tracking system (you *ARE* using a bug tracking system, aren't you?).

You add the bad case to the tests, verify they break, commit change.

You fix the module, and verify the fix. Commit change, mark bug as FIXED.

Your Q/A guys verify that the run before the fix is broken, the run after the fix is OK, and VERIFY the bug, OR they suggest other possible tests that break the system. If so, repeat the last three steps.

Sure, this is no "silver bullet" that will eliminate all bugs. What this DOES do is catch the bugs as quickly as possible, when they affect as little of the project as possible, and VERIFIES that they are indeed fixed and STAY fixed.

Re:Write the tests *first*

[ph1ll]

I'm all for automated unit testing (though it's by no means the only testing that needs to be done) and I like the idea of test first.

The thing is, I like to get the interfaces about right before I start writing the tests... and maybe a *little* code.

What I don't like about test driven development is that I always refactor my first draft of code and that means refactoring all my test classes - ie, twice as much work.

Far better to get a *very* basic class structure set out, then write the tests then fully implement the methods.

Does anybody else do this? Or am I just being lazy?

Re:Write the tests *first*

[iabervon]

You don't catch SQL injection issues with unit testing; you catch them with type checking. A SQL injection occurs when someone uses a string plus quotes as a partial SQL statement. There should be a different type for partial SQL statements, and the operation to make one for a string constant out of a string should escape the string appropriately. Alternatively, you could just use prepared statements exclusively and make your database happy as well as making SQL injections totally impossible (as the database will be done parsing the SQL when it looks at the user-supplied data).

The best reason to write the tests first, in my opinion, is that this will give you a good idea of whether the API is any good. Many of the APIs I've wanted to be different obviously couldn't have been tested in advance, because writing the test would have made it clear that the API was just too much of a pain to use. If writing 10 example uses for your API is enough work to worry about, your design is bad, and people are probably going to not like how it works. Change it before either finishing the tests or writing the code (or, ideally, telling anyone else about it).

Re:Write the tests *first*

[chromatic]

You're being lazy. Alternately, you're not being lazy enough.

I find that it's helpful to sketch out some idea of how the parts will fit together so I know where to start and when to stop, but I prefer to let the design emerge from writing the tests. It's really helpful to let the tests show you what it's like to use the API you're creating. If it's awful and awkward, there's a sign that you need to simplify it.

I also like to check for refactorings after each successful test-fail-code-pass cycle. It seems like more work in the short term, but the refactorings are usually much smaller than if I waited. It also makes my tests much less brittle to code changes.

Re:Write the tests *first*

[mav[LAG]]

If you're not sure how test-first development works Mark Pilgrim's chapter on the subject (and the following one too) is an excellent introduction for Python programmers. I personally don't think test-driven development is a catch-all but at least he shows it in action so you can decide whether you want to go this route.

Re:Write the tests *first*

[kin_korn_karn]

test-first development only works if you have clear, solidified requirements beforehand. I'm in a situation where I'm developing to the first half of the requirements while the second half are still being flushed out (no pun intended). There's no way I could write tests for business rules that don't exist, but I can write the backbone code (DAOs, UI stuff from UI spec, etc.)

Re:Write the tests *first*

[Surt]

Requirements come in many forms. For example, an interface is a requirement which for apps where reliability is important enough, ought to be tested.

If you can write the backbone code, surely you can imagine some of the common uses to which it might be put, and verify that it is at least functional for some of the base cases?

Re:Write the tests *first*

[kin_korn_karn]

At work, it's not my job to imagine how my software is going to be used. We use RUP (cringe), so that's a business analyst's job. If I were to go playing in their domain then I'd a) get slapped with the ruler for invading their space and b) probably get something wrong anyway, which I would have to fix, which would ultimately lead to a lack of productivity.

Re:Write the tests *first*

[Anonymous Coward]

> "How do you write a test to check that someone didn't allow sql injection?"

> You enumerate the functions calling sql and attempt sql injection on all of them.

This is what I see all the time, it's this iterative "code til the test light turns green" process. Oops, missed a case there, write a test, pass the test. Oops, missed another, patch and write the test. Nowhere is there some comprehensive strategy for security -- like data tainting, sandboxing, etc, because those are all dissmissed with a handwave and some catchy slogan like YAGNI. Regression tests are fine, instant feedback from tests is great, coding to meet the tests is hacking in the most pejorative sense of the term.

I have no use for methodology bandwagons. I will cherry-pick whatever's good about XP, and I'll give the condemnations of such an approach over the "holistic synergies" of XP with all the attention it merits: none.

Re:Write the tests *first*

[Surt]

Peronsally, I don't like anything from XP except the testing ideas, and those don't originate with XP.

The process I like best for 'test-first' is actually 'almost-test-first'. Instead of just sitting down and writing tests, the process is:

1) Design a system that solves the problem.
2) Figure out what entry points are to the system.
3) Implement the interfaces for the entry points so that the public contract is defined.
4) Now you start writing tests that verify the fulfillment of the public contract.
5) Implement the interfaces in a way that satisfies the tests.

Our current project has about 7500 tests. The system is what I would rate as middleing complex. I average about 3 sideffects caught by tests per major checkin. That's a lot of subtle stuff no qa person had to chase down, and a lot of developers who aren't irritated that someone else broke their stuff.

Re:Write the tests *first*

[GileadGreene]

More importantly, write the tests FIRST. Then write the code, updating the tests for anything that is identified during the coding.

Which fundamentally boils down to "write the requirements first". After all, what are tests if not an expression of what the software must do (i.e. requirements), albeit precisely expressed in terms of executable code rather than vague natural language "shall" statements. The mantra of "writing tests first" is just a cunning way to get developers to actually think about requirements before they code, and better yet provides a framework for thinking about the problem that actually leads to useful requirements instead of useless "shall"s. Your comment about "updating the tests for anything that is identified during the coding" equates to the iteration of requirements that one expects in any good development process.

Note that I'm not saying that the "write the tests first" approach is bad. It just amuses me that people somehow see it as being different than the requirements first approach that has been preached for years. Although the fact that they do see it as different is eprhaps a good indication that the "requirements first" crowd did a very poor job of actually explaining how and why to write requirements.

Re:Write the tests *first*

[dubl-u]

But write which tests first? There are so many possible. Usually there are more ways for something to malfunction than for it to function correctly.

You write a test first. Then you make it pass. Which test? Whichever the most important one is.

We don't like the way that works in practice", you haven't wasted time writing 10 tests. Whereas if you do it the other way round, they can only find out they don't like it after you've written the 10 tests AND the actual code.

This would imply that writing the test slows things down. In my experience, and that of most other people who do test-driven development, having tests speeds things up because you spend less time debugging.

Doing the tests first also helps make sure you're doing the right thing. Writing a test case requires you to be more clear about what you're doing, so that you are forced to clarify the requirements before you write the code.

Your suggestion probably works well for certain scenarios, but appears counterproductive for many others.

That's a plausible theory. But having tried it both ways, I think it's incorrect. The only real way for you to find out is to try it yourself. Pick up Kent Beck's Test-Driven Development: By Example and give it a go.

Re:Write the tests *first*

[Anonymous Coward]

Mod parent up.

What this really is (since write requirements first has failed continuously as well as other factors) is the following:
"Write the tests first" is shorthand for:
Since you will not get clear, specific requirements for a project and since you don't want to do documentation, write the tests first as
an automatable documentory statement of what you assume the requirements are.

Re:Write the tests *first*

[hachete]

Uh, does anyone truly, outside of NASA, write the requirements first? No one does that anymore. The requirements change so rapidly. Has no one heard of Evolutionary programming? Often, requirements stem from code being written...so I'm in violent agreement with you. It's just code that code is being is being used for design here.

There is one solid case where yo write the tests first: bug fixing. Find the bug, write the test for the bug, fix the bug.

h

Re:Write the tests *first*

[GileadGreene]

Uh... what do you write if you don't have any requirements? There are always requirements - otherwise there'd be no need to write anything. It's just a question of how firm and formalized those requirements are. Writing tests first (i.e. writing some initial requirements) is a first pass at defining what the code to be written must do. Sure, you can just keep that idea of the purpose of the code in your head as some vague, amorphous concept. But it's better to write it down somewhere, since it helps clarify your thinking.

Re:Write the tests *first*

[hachete]

Apologies. I was referring to the time-honoured "cascade" method of software dev. The one where *all* the requirements are written *before* embarking on software product dev. That makes my statement a little clearer. I've had several newbies say "oh, if you wrote all the requirements first then you wouldn't be in this mess". Ummm. This assumes that the client knows all the requirements first - quite often, they don't know the requirements until the first working draft has been done and suddenly they want x, y and z...

Yes, there is always some requirements at the start. Some requirements are almost a "statement of intent" and so the dance begins. The requirements zig-zag all over the place and the software development follows until something is built. And sure, these have to written somewhere because, yes, they do clarify your thinking. This I think is the standard way of working for most companies, whether or not they formalise these procedures.

A more refined version gets the programmer to find out the requirements that meet their client's needs the soonest. Some requirements are more essential than others. Of course, this changes over time, which is why programmers should liase with clients as often as possible, even though the y may not have completed the latest deliverable. The one weakness of this method is deciding on completeness. What state of functionality is complete enough? Probably not a big deal as I suppose the 80% rule must apply here as it always does.

I believe this methodology is called Evolutionary or Iterative development - http://www.phptr.com/articles/article.asp?p=102256
The place where I work is a firm believer in this and it's kept us going for the past 10 years.

h

Being on a chip

[AnuradhaRatnaweera]

Wonder if he also talked about being on a chip. ;-)

Depends on the language and context...

[Richard Steiner]

In the Fortran variant I was working in until a few years ago, local variable names were limited to five (5) characters, and many otherwise obvious functions were performed by a series of external subroutines with six-character names usually beginning with SY (for "System").

That meant that the code itself could be quite hard to follow without some sort of logical commentary accompanying it.

I tended to comment my code quite heavily in that context, since I'd already had experience with uncommented code in that context and knew how hard it could be to follow...

(Try reading Fortran that's all in column 7 and which is mainly composed of arithmetic IFs and CALL statements sometime and see how intuitive it is!)

When using more modern languages, I tend to comment less, sometimes a lot less. It usually comes down to a judgement call on my part as to whether or not I think the code would be easy for a newcomer to maintain...

Linus already covered this

[jaymzter]

"regression testing, what's that? If it compiles it works and if it boots it's perfect!" - Linus

'nuff said

Re:Linus already covered this

[globalar]

Not to sour the joke, but in any problem-domain booting is literally the first requirement and no-where near the last. You have to think about the whole runtime existence of your program.

It's like caring for a person's health throughout their life. You don't give a baby a checkup and then never look back. You can't just reboot the child - somethings have to work and you better have tested some of those core units. If problems come up, you better fix them now or have a good plan for later.

As the child grows, you lay off the majority of testing and start to the trust the code a little more. But, problems will still come up and threaten the overall health. Your kid/app will likely find itself in situations you never envisioned.

Re:Linus already covered this

[Anonymous Coward]

This is the -ac version of that.

Good practices

[vinukr]

These are some things i guess is necessary for good software
1) Reviews at all stages.(Reqs/design/dev)
2) While at development, u sure must know whats the most efficient way to code a design (which libraries are more suitable etc)
3) Unit testing and Integration testing (when the project is huge)

Some practices that managers can really use to take the pressure off the team
1) Try giving buffers to the team (seriously, it works)
2) Proper Code management (Lotsa rework and pressure come due to lack of this)
3) Proper tracking and status updates to the customers

Didn't know he used Gentoo...

[cs02rm0]

emerging techniques for producing higher quality software

Re:Didn't know he used Gentoo...

[mark_lybarger]

obviously you're not a gentooer, it says higher quality.

emerge
-- wait long long long time
emerge doesn't work.
check forums for help, check irc for help.
no answer quickly available, wasted 1 hour trying general system update.
lovely

Re:Didn't know he used Gentoo...

[boudie]

Well, at least you can be proud of the fact you have the skills to post to slashdot. Some people can't even do that. Try XP.

Re:Didn't know he used Gentoo...

[mark_lybarger]

it doesn't take skill to install software on a linux machine, it takes time, often wasted time trying to figgure out some solution you'll never remember in 3 days anyway.

Re:Didn't know he used Gentoo...

[boudie]

Guess it's been at least four days since you spelled figure. And pray tell, if it isn't skill, what is it?

Re:Didn't know he used Gentoo...

[mark_lybarger]

skill, skill to type configure, make, make install? yep that's skill for certain. it must take real skill to completely fuck up lots of other people's systems by messing up the sequence of configure, make and make install.

i'll keep the /etc updating maddness for another day.

Re:Didn't know he used Gentoo...

[boudie]

Generally speaking, the configure, make and make install is handled by emerge. If you would have gotten it to work, you would have found that out. Things such as configure options and USE flags are built into the ebuild. With etc-update you can choose what files to change or leave. It works quite well, once you read the docs.

Re:Didn't know he used Gentoo...

[mark_lybarger]

ok, etc-update. etc configurations should be "smart" enough that they can auto update files that portage installed, and leave for me to merge in files that i have touched. when i update xorg or kde, i have a ton of files to "etc-update" most of which aren't anything i have (or should haev) a freaking clue what they do.

i have emerge working, i have written some ebuilds in the past. my original point before all this fucking chit chat was that the software needs to be better. it needs to be higher quality. it's not high quality because it's buggy and breaks often.

it seems like the old hard core gentoo filosofy is still around these days. gentoo being a "hard code" distro all about being able to customize the distro and all the stuf that's getting built.
gentoo has many strenghts, a strong community and good documentation for the most part. but its weakness is that l33t crowd mentality that creeps up from time to time. there are bugs and genaral flaws in the system that need addressed.

MBA?

[Anonymous Coward]

So now we're taking software writing advice from PHBs now? :)

Re:MBA?

[Anonymous Coward]

And not just any PHB, a traitor! :)

Re:MBA?

[lxs]

Watch out for his next article:"Shiny Widgets And Flashy Animations - The Key To Better Software"

error-free software

[frankvl]

The only way to create error-free software is using a guaranteed error-free interface (I'm not talking Java, we should go much further), which has to be the base of the operating system to be actually error-free.
As a nice by-product, developing applications will be much easier.

Re:error-free software

[Anonymous Coward]

Okay, I'll bite. What is insightful about this?

Hows does being "the base of the operating system" ensure anything is "actually error-free" ?

What is/how does one have a "guaranteed error-free interface"?

How does that stop the code behind the interface being bug ridden?

Am i missing a programing language reference here?

I'm not trollin' but this makes about as much sense, to me, as the output of the star trek technobabble buzzword generator.

A somewhat confused glass box/white box QA engineer, with no account hence A/C.

Re:error-free software

[Anonymous Coward]

No, the grandparent is just in highschool. He doesn't know what he's talking about.

MDA?

[little1973]

At my company the management has started an MDA (Model Driven Architecture) project, because some developers presented it to them as the holy grail in software development. They use a GUI to make associations between classes and ASL for the code. They say that you are less likely to make a mistake because you code in a platform independent way (so, you do not have to pay attention to all the little details) and the translator is responsible to make the actual code.

Some of us more experienced developers do not think it is the holy grail. It looks like you can make as much mistake as in convetional languages. Also, development with a GUI (see at www.kc.com) is much more cumbersome.

Is there anyone who used MDA and ASL and has some experience about it?

Re:MDA?

[Anonymous Coward]

The main problem, as I see it, with modelling tools is that they just aren't rich or expressive enough to replace writing code, and they aren't terse enough to allow checking of the validity/legality of what you're designing.
I was involved with a project which used full round trip engineering with Rational Rose, and one of the main problems was that you could design classes quite quickly, but to check that it passed the unit tests, you would have to generate the code (with all the problems Rose had with that), compile it then run the tests. The version of Rose that we were using wasn't capable of generating the implementation of the classes you designed - only the skeleton was generated. Most of the work still had to be done by "writing code", but any small changes to the skeleton (such as realising that a parameter passed as a const reference needed to be passed as a non-const reference) needed to be passed back up the tool chain into Rose. The end result was a large increase in workload for all the developers, with minimal gain.

All these modelling tools are trying to replace programming languages with a visual model. You really have to decide if it's easier and more accurate to write, document, test and maintain "real code" or the model.

In the end we ditched Rose, and instead used pads of paper to do UML designs. Much cheaper and far more reliable!
We got a licence for Together ControlCenter which allows users to generate very rich class/sequence diagrams on-the-fly from the codebase, and we sometimes use that to get ad-hoc diagrams for meetings and the suchlike.

How are you getting on with the project? What specific problems are you having?

Sorry for the AC posting, but I'm buggered if I can remember my login :(

Re:MDA?

[dubl-u]

Some of us more experienced developers do not think it is the holy grail. It looks like you can make as much mistake as in convetional languages. Also, development with a GUI (see at www.kc.com) is much more cumbersome.

Personally, I think this is akin to VRML: it's an idea that seems simple and obvious but will turn out to be a huge waste of time and money.

I think that tools that help you visualize things are great, but I think the way to greater productivity is through the kind of automation provided by modern editors like IntelliJ IDEA. It may be that one day somebody will develop a visual programming environment that lets you be as productive as code, but I think it will take a radically different programming language and a different physical user interface. For now I think it makes as much sense as an all-visual version of Microsoft Word for novelists.

Re:Demo Scene

[Anonymous Coward]

Tight code? Have you been living under a rock since 2000? With one or two exceptions (read: Farbrausch) the rest of the scene can't see past the 3D engine (with hardware requirements that make Doom3 look like made for low end) and unoptimized DX9 or, in some cases, OpenGL code. Long are gone the times when PC coders knew what they were doing and wrote tight assembler inner loops. If you want to look at tight and optimized code look at Doom3 and Far Cry. It doesn't get better than that. Or even better, download some Amiga and C64 demos.

There was recently a fast coding compo in a party and the C64 guys were typing the hex codes directly, not even using an assembler. Talk about tight code! :)

Erlang Smorgreff

write it in Perl and be happy

[Anonymous Coward]

Perl is happy happy language. Code always turn out better.

Who cares of AC

[Anonymous Coward]

The guy should first learn to write code himself, then write an essay. Also, the guy just lost my respect when he tried a mini-golpe at the time of 2.4.9 VM change. He staied out of the kernel for 1+ years and I think noone missed him.

Best Practices for Software Development

[Isomorph]

Here is an eigenpoll about Best Practices for Software Development

The current list are

The Planing Game

Scrum Project Backlog

Continuous Integration

Test Driven Development

TDD & CI with Aegis

Onsite Customer

100% Test Coverage

Scrum Project Management Patte

Current Worst Problem

Layering

Collectiv Code Ownership

Simple Design

Use Cases

Big Visible Chart

Refactoring

Codeing Standards

CRC Cards

Pair Programming

Continuous Performance

And your can add new options yourself.

WHY, not what

[wowbagger]

The single best rule of comment is "Comment upon the WHY, not the WHAT".

Don't say:

double sum = 0.0; // zero sum
for (i = 0; i < len; ++i) // all samples
{
double signal = buf[i]; // get value
sum += signal*signal; // add signal^2 to sum
}
return sqrt(sum/len);


say:
// Compute RMS average of signal -
// compute the sum of the squares of all values,
// then compute the mean (sum/len), then the
// root of the sum - hence Root-Mean-Squared

double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);

In other words, tell me WHY this code added the square of the signal, not THAT it added the square of the signal.

Moreover:

1. Every directory of the project should have a purpose, and should contain a short README describing the purpose of the code in the directory.
2. Every file should have a header that describes the purpose of the file.
3. Every function should have a header describing the purpose of the function, as well as any inputs and outputs (including global, static, and class variables), any exceptions thrown, and any assumptions made.
4. Blocks of code within a (large) subroutine should have a descriptive block comment describing the overall goal of that block (e.g. "Now we walk the list of conversations and update the call stats").
5. Comments on a line of code shouldn't be needed normally - the code should speak for itself. Only pretty tricky things ("use a shift and add rather than a multiply as this saves 3 clock cycles") should need a comment at end of line.

If more folks would follow these rules it would be a HELL of a lot easier to follow their code.

NOTE: If you can say it in the code, do so - if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.

Remember - the code tells the COMPILER and the programmer what is going on, the comments tell the programmer WHY it is going on.

Re:WHY, not what

[Q Who]

if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.

This will impair the efficiency due to exception conformancy checks.

Besides, mandatory specification of thrown exceptions for each function is the Java way, which has already been admitted as a bad decision by Java designers.

Re:WHY, not what

[liquiddark]

Better yet, simply use a good name for the function and parameters ComputeRMSOfSignal(double signalComponents[]) ld

Re:WHY, not what

[Anonymous Coward]

Yeah, I was with you up to the 'moreover' section. Beyond that you delve into the realm of overkill. Some extra documentation in the code is a good thing, but having reems of text prior to every single file and every single function is just exhausting to maintain. Trust me, I've done it.

Re:WHY, not what

[jhoger]

I often put summary comments that say what the code is doing, not just why it is doing it.

Yeah each line in and of itself should be understandable to a programmer who understands the language. I wouldn't recommend a comment on every line (unless it's assembly code).

I tend to have blocks of 4-7 lines of code, and each gets a comment stating what that block of code does. It's a summary. By looking at 4 or 5 lines of comments on blocks you can tell what the whole routine is doing.

When doing maintenance programming, I usually care more about what the coder is trying to do than why. The why tends to be obvious from the name of the function, or what it does. If the why is totally non-obvious, it's usually because it is so complex that you really need to be reading a separate standard document, or a high level (usually high powered matH) design document.

So I guess I don't agree with you :-)

Does page 2 (with the actual advice) exist?

[solprovider]

The text version has a link for "Next" that points to the same text as the original page, but in a larger font. The /software directory only contains those 2 files.

Is this irony? An article about quality has only half of the article.

And it increases the Slashdot effect as everybody thinks they made a mistake and keeps clicking the "Next" link until finally realizing that the website is broken.

Re:Beware, redirects!!!

[Anonymous Coward]

Thank you, good sir.

MBA- Management

[nuggz]

Oh no, someone with an education in MANAGEMENT suggesting ways to MANAGE a production process.

Yes your average programmer/engineer might be able to manage a project. But why not take some of the expertise of a manager to make it a bit better?

If someone like Alan Cox should now be ignored as "some MBA toting PHB" how open minded are you?
I think Alan might have a bit of an idea how the software development process works.

If you're not even willing to consider their ideas, you're doing yourself quite a disservice.

Some tools I've found handy ....

[mike_diack]

For DOS/Windows/OS2 etc:

Gimpel Software's:
PC Lint (cheapish)
Flexelint (pricier)

Freeware (checks GDI leaks)
bear.exe (http://www.geocities.com/the_real_sz/misc/bear_.h tm)
gdiobj.exe (http://www.fengyuan.com)

Linux:
Electric Fence (free)
Valgrind (free)
Splint (free)

Books:
John Robbins books on debugging. Concentrates on Win 32 but useful ideas wise for any x86 platform.

And now the gags...

Tools I've not found helpful.....
Rational Rose!
Microsoft's beloved COM!

Re:Some tools I've found handy ....

[mike_diack]

One I forgot:

A free version of a bounds checker type tool for Win32 (ala Electric fence) - which checks read and writes on array bounds via hardware:

HeapCheck

http://www.softlab.ece.ntua.gr/~ttsiod/HeapCheck .h tml

oops

[Anonymous Coward]

read
"Am i missing a programing language reference here?"

as
"Am i missing a programing language specific reference here with use of interface? ie as a reserved word? Java perchance?"

Ironically...

[jejones]

The Ping Wales article's link to Page 2 loops back to Page 1.

QA != testing !!!

[gosand]

I have said it for years, and I'll keep saying it.

Quality Assurance is not testing.

Testing is testing, and can run the gamut from unit to use case, from integration to system, from acceptance to beta. But QA is not testing. A lot of people call testing QA, but it is not the same thing.

Testing is what you do when you get the code. QA is everything that you do throughout the software development cycle to ensure that you have quality software. This can include code reviews, process audits, statistical analysis, etc.

I have been doing QA and testing for 11 years now. I have a degree in computer science, and I CHOSE to do this career. You may be able to get away with ignoring QA professionals and still produce high-quality software. But not all software projects are equal. QA is probably the most overlooked part of software development, testing the second.

Re:QA != testing !!!

[Brandybuck]

Okay, as someone who has chosen QA as a career, does all this damned paperwork actually improve the quality of the code? Really now, does it? Or is it just a way for non-technical people to pretend that they're engineers?

In theory QA sounds great. In practice though QA does not produce anything other than process. The only reason QA reduces defects is because it reduces the rate at which all code gets written. It's like improving highway safety by removing the number of cars on the highways.

My company, like many others, is engaged in a strange boom/bust cycle. The boom cycle consists of rah-rah process improvements, efforts to improve CMM ratings, firing coders to make room for QA auditors, etc. Then the bust comes when we realize we haven't shippped a product in over two years, and the CEO has to descend from on high and handcuff the process police.

Re:QA != testing !!!

[gosand]

Okay, as someone who has chosen QA as a career, does all this damned paperwork actually improve the quality of the code? Really now, does it? Or is it just a way for non-technical people to pretend that they're engineers?

1. Assuming QA peole are not technical shows your ignorance.

2. Coders aren't engineers. If they were, then they would certainly understand why QA is valuable. Coders are the ones who like to call themselves engineers.

3. Proper QA not only decreases defects, but it lets you analyze why you got the defects you ended up with and the ones you eliminated.

In theory QA sounds great. In practice though QA does not produce anything other than process. The only reason QA reduces defects is because it reduces the rate at which all code gets written. It's like improving highway safety by removing the number of cars on the highways.

QA is not directly linked to process. I think you are confused. And in theory, outsourcing is a good idea too.

My company, like many others, is engaged in a strange boom/bust cycle. The boom cycle consists of rah-rah process improvements, efforts to improve CMM ratings, firing coders to make room for QA auditors, etc. Then the bust comes when we realize we haven't shippped a product in over two years, and the CEO has to descend from on high and handcuff the process police.

*sigh* You obviously work for a company that has no clue. From the sounds of it, it is no wonder you are jaded. The FIRST rule of process improvement is that it comes second to doing your business. The entire point of process improvement is to improve (duh) your processes and make things run more smoothly. If it does not, then you simply are not doing it right. The fact that you mention "auditors" and "process police" are sure signs that you aren't doing it right. Another obvious statement is that you go through cycles. If you are doing CMM correctly, then you follow the same processes regardless of what is going on. (and processes don't have to be rigid, de-moralizing things) The true test to whether you are doing it correctly is if you don't have to question it, it is just the way you do business. If you don't measure what you are doing, how do you ever know how well you are doing things?

Yet another statement that puts up red flags is that you think the CMM leads to better code. It does not, and it is not designed to. Anyone who tells you differently doesn't know what they are talking about. CMM is process management, pure and simple. It demonstrates how mature your organization is when it comes to software development processes. It has nothing to do with code. I'd suggest that if you are writing buggy code, it could be because you write buggy code. If it is for anything other than that reason, then you could actually look to process improvement to help you. If you are getting bad requirements, the CMM (level 2) states that you have to have a documented requirements management process. If there is no plan for the project, all the CMM states (L2 again) is that you have to create a project plan according to a documented procedure. It just points out that you need to have a plan on how to do various things. And if your senior management doesn't know what is going on with the project on a regular basis, then you sure as hell aren't doing CMM properly. If you haven't shipped a product in over 2 years (and you should have) then you have a lot of other problems besides CMM. Don't shoot the messenger.

Re:QA != testing !!!

[Brandybuck]

Assuming QA peole are not technical shows your ignorance.

It's ignorance I've had to learn. It's been beaten into me. I used to be a Software Quality Engineer. Then my company got bought out, and they renamed the SQA department to "Software Test", and made a separate SQA group. Everything I knew was turned upside down.

To these people, quality is synonymous with adherence to the process. Thus, they truly believe they are productive members of a team when they strut around like a police on patrol. They insist on being members of technical reviews, but they are not qualified to offer technical criticism. They only thing they do at these reviews is to nitpick over inconsequential process details.

You obviously work for a company that has no clue.

That's for sure! I work for a division of Siemens AG. We're not just some small fry startup operating out of a garage. We're one of the ten largest companies in the world. Which I why I think this problem infects more than must my employer.

I've seen experienced QA Engineers join this company then quit in extreme disgust weeks later. Is it really different elsewhere? I can only dream...

The FIRST rule of process improvement is that it comes second to doing your business.

I swear our unofficial motto is "process is our product". I've been with Siemens AG for six years. In that time I've seen five new processes rolled out. We have another one scheduled to be rolled out next year.

Please don't misunderstand me. I am NOT saying QA is valueless. I am NOT saying process is useless. I am only saying that in practice, from my experience working for the quintessential multinational corporation, process is more important than product.

Re:QA != testing !!!

[Brandybuck]

Let me re-reply. I've just come back from my daily run, and have thought about this a little bit more.

The problem is that there are two kinds of people implementing Quality Assurance. One kind are engineers and the other are MBAs.

Engineers are focused on the product. They use QA to produce a quality product. They define "quality" to be validating the product requirements and verifying the product specifications. They want it to do what the customer wants and be free of defects. The process is always secondary to the product.

MBAs are focused on the process. They use QA to ensure a quality process. They define "quality" to be adherence to the process, e.g. validating the requirements document and verifying the specifications document. They want the process to do what the management wants and be free of issues that might be discovered by outside auditors. The process is the product.

The MBA way leads to bureaucracy. The larger the company the more likely it is that their QA groups are focused on process instead of product. My company is one of the largest in the world. Bureaucratic process is more important to them than the actual product. When we shipped our last product I got a teeshirt and a thank you by my immediate manager. When we announced our new process we had a company outing and barbecue plus a grand laudatory speech by our CEO.

Re:QA != testing !!!

[Tony-A]

In theory QA sounds great. In practice though QA does not produce anything other than process.

Nah, I think you are assuming that QA is strictly about improving quality.
Qa is more like a pair of eyeballs so you can see what quality and/or the lack of quality is really costing you so that you can make intelligent trade-offs. Perfect quality is rarely achievable and almost never worth the required effort.

It's more like improving highway safety by putting up streetlights so people can see and be seen.

Re:QA != testing !!!

[Brandybuck]

If my employer's QA group was in charge of improving highway safety, they would audit the DMV!

Cheers :-)

Re:QA != testing !!!

[gosand]

That's for sure! I work for a division of Siemens AG. We're not just some small fry startup operating out of a garage. We're one of the ten largest companies in the world. Which I why I think this problem infects more than must my employer.

Wow. The person where I work that is leading the effort to achieve CMM Level 2 is a former Siemens employee. He was overly confident about how to achieve Level 2, saying "Oh, we did this all the time at Siemens." The problem was, all he wants to do is get that CMM rating. His processes are shit, and on top of that he circumvents them at every opportunity. I always wondered how the hell he ever survived at Siemens, but now I think I know.

Re:QA != testing !!!

[Brandybuck]

Definitely sounds like one of our guys :-)

We had this initiative to get our division from nothing to CMM level 3 in one year, skipping levels 1 and 2 on the way. Seriously! That one year turned into two, and then three. We finally gave up and started using the Siemens OPAL(tm) process improvement inititive. We achieved OPAL level three after only a three month effort.

Re:QA != testing !!!

[Tony-A]

My sympathies.
I'd expect your employer's QA group would be in for some rude shocks if they tried for ISO certification. It's not all that hard, but what you do has to match what you claim you do and it has to be documented. Done right it's productive and not all that difficult.

Re:QA != testing !!!

[IgLou]

I like your post so I'll tag unto it. I'd expand to say QA is radically different from testing. If you take a look at TQM (and I know there are folks who will groan at that) the foundation concepts are not "test" centric rather building towards a Quality culture. Most folks do not work in a shop that has a quality culture.

It's my firmest belief that when the quality culture is developed in a shop that QA comes about from this quite naturally.

Re:gmail invites (6)

[ajs318]

Oh, come on. If you didn't laugh at that, you'd have to cry. Even if you don't like the subject matter, you've gotta admire the way this just cruised in under the radar.

Or am I the only IT boss who insists to disable JavaScript by default except for the office Intranet {our in-house LAMP [and we use at least two of the possible P's in that acronym] apps use JavaScript a lot for flinging data around between forms and highlighting stuff in tables ..... the server can spit out dynamically-generated JavaScript which in turn modifies style sheet properties ..... when you want to edit a record from a table, sometimes it's easier to populate the inevitable "add a new record" editing form straight out of the table, highlight the row being edited and put the UID into an invisible <input /> field, rather than fart-arsing about fetching another page and repeating an earlier SQL query just for the editing form} and certain carefully-selected sites?

By the way, if you really want a GMail invite, they are giving them out like confetti at the moment.

Alan, HELP!

[Anonymous Coward]

I don't get it.

Re:Alan, HELP!

[HogynCymraeg]

Bwyd Gyntaf - Food First Menyw ar ol - Menyw sounds like "menu" but is south walian welsh (yes different to north walian) for "girl" so it's basically a play on words about a girl offering herself to the farmers :)

Re:Alan, HELP!

[Anonymous Coward]

If you assume the waitress is speaking Welsh, the conversation gos:

"Woman, sir?"

"Food first, woman later".

OK, not actually hilarious.

Are you a manager?

[Duhavid]

Cause you didnt heed #1. Or #2, for that matter.

I dont hate managers, but I gotta tell you, mlh hit the nail *right* on the head.

From the listening will come many many concrete steps.

Cox was better without an MBA

[ElitistWhiner]

Alan Cox got O-O programming and Objective-C, reusability and abstraction layers right.

Now I have to listen to him bitch about academic concepts because he has an MBA. Pluueese...

There wasn't an original idea in the whole article in the link to this thread.
-r

Re:Cox was better without an MBA

[Anonymous Coward]

We don't really need *original* ideas. We just need good ideas and good implementation, regardless of originality. Management = common sense. We're just not used to that because there are too many managers who fail in the common sense department.

CS1 comments...

[Anonymous Coward]

Great, now we get to hear everything we've heard in CS1 classes repeated over and over.

I'm tired of people simply repeating what they've read in a book. I'd like to see some actual studies to measure the benefits of some software practices. I think the results would be enlightening.

No mention of Ada

[museumpeace]

I agree with most of the posts citing organizational and management techniques as the most fruitfull areas for improvement of software quality. But technical fixes don't require changing attitudes or otherwise fighting human nature. It seems to me, since the Sun's, IBM's and MicroSoft's of the world are spending tons of money to give us slickly integrated or widely applicable software development tools, that they would do themselves and us developers a favor to incorporate some of the oldest "lessons learned" into the tools. We have had so many "revolutionary" languages come and go that we seem to have forgotton just what array bounds checking and strict type enforcement save the average programmer from having to think about. In my current project, I am porting Ada code to C++. Yes, Ada is a language only its Mother, the DOD, could love but we shouldn't have tossed out the baby with the bath water when everyone dropped their support for it. There were vendors of quality assurance tools to be used on top of the qualitity built into the language because the customers and the developement culture all emphasized reliability of the finished product. How did we manage to so thoroughly get away from those objectives?

Re:No mention of Ada

[Tony-A]

they would do themselves and us developers a favor to incorporate some of the oldest "lessons learned" into the tools.

The lessons have never been learned.
Old Burroughs hardware had that stuff built in.
The problem is that programs that would seeminging run on other stuff would blow up on Burroughs because the hardware refused to perform the logically illegal operations.
There's an awful lot that you can do that is blatantly wrong that nobody will ever notice.
If that something hasn't bitten you yet, hard enough and often enough, you keep using it.
Unfortunately, the solution to any of these problems will be to throw more and more of what causes the problems into the mix.

Testing and releasing software-Smalltalk.

[Anonymous Coward]

Or use a language that allows something like this in approximately 900 man/days for an individual. Working with live objects in an integrated IDE is powerful, and eliminates many of the problems, and tools built to combat those problems that other languages have (BTW that FAA radio problem mentioned on "/." wouldn't have happened with smalltalk).

Why?

[tiger99]

Why would they have to physically meet to implement any of that? Tools, procedures, tests, etc do not require that the coder, the tester, the manager, the QA person and anyone else involved are in close proximity.

A company I worked for recently, in the South of England, was having much of the testing done in India, via the internet, on real hardware which was in the lab in the UK. The testers could drive the emulators and debuggers as if they were present. Same for code reviews and all the other things.

This was safety-critical software to DO-178B Level 1, it does not get any higher!

Type Checking = false promises

[Tablizer]

The implication above that type checking automatically produces better software is false. Type checking tends to bloat up the code, making it harder to read. Harder-to-read code means more errors during inspection and changes. Plus, the time saved using dynamic or "free" typing languages gives one more time to inspect the code and build unit tests.

Heavy type-checking relies on the same theory that more buerocracy is the solution to quality. It is not. Keeping code lean and clean is the road to quality in my observation, not bloated formality.

Re:Type Checking = false promises

[dvdeug]

Heavy type-checking relies on the same theory that more buerocracy is the solution to quality.

The earlier you catch a bug, the easier it is to fix. That's been proven. Heavy type-checking catches bugs at compile time. Dynamic type-checking may leave bugs until the user runs over them.

Is the array row-first or column-first? If rows and columns are different types, then the compiler will tell me when I got it wrong. I don't find that chasing that bug later, when it could be anywhere in a thousand lines of code, is a more efficent way to quality. Sure, it means a few more casts when I want to add rows and columns, but I've never found that a problem.

Type-checking doesn't always make the code harder to read. In a type-checking language, "if (a==0)" lets me know that a is a number. In several non-type-checking languages, a could be just about anything. It's possible that you can't figure out what a is, even after looking around the code; it's possible that the else part of that statement may have to deal with a being a list, or a record, or a string. There is no local checks you can make to discover that; you may have to read every line of code to discover what type a is.

Re:Type Checking = false promises

[Anonymous Coward]

Guess you haven't heard about that Robin Milner dude eh? "well-typed programs cannot go wrong.".

Re:Type Checking = false promises

[grumbel]

### The implication above that type checking automatically produces better software is false.

Type-checking does of course not produce better software, there are just to many other issues that can go wrong. It however frees you from a very common programming error or at least moves it from run-time to compile-time, which can save you a whole lot of bug hunting, especially when a part of the code isn't used all that often.

I find for example refactoring in static typed languages a few orders of magnitude easier then in dynamic typed ones. In the static I just refactor the code, compile and fix the places where the compiler shows an error, pretty simple. In a dynamic however I change the code and then have to do bug hunting, guess work and grep'ing around to find the places where the code will now run into a type error, no static type checking that will help me.

And well, I don't get the hype of dynamic typing anyway, yes, there are a few places where its nice, ie. being able to return a False or Nil instead of an Integer to indicate an error, however thats already all good I can say about dynamic types. Stuff like arrays of ints vs. arrays of string and the like are solved by generics in static languages already pretty well, so thats not much of a plus for dynamic typed languages.

About making the code harder to read, it depends. Sometimes it can be quite helpfull to actually know what types a function expects instead of just hoping that the docu is accurat enough or existing at all.

Last not least, dynamic typing can be usefull in some situations and not specifing the types can also save a bit of typing, however not providing any static typing at all is something that I consider quite a big mistake since it just moves to many errors into run-time, where they really do not belong. And yes, in a perfect world a bunch of unit-checking might catch all my dynamic-type checking bugs, however we don't life in a perfect one and I still kind of prefer to let the compiler do the work then being force to write additional code.

Re:Type Checking = false promises

[Tablizer]

The earlier you catch a bug, the easier it is to fix. That's been proven.

It has also been proven that staticly-typed languages use up more code.

Type-checking doesn't always make the code harder to read.

No, just *most* of the time.

Personally, I would like to see a kind of compromise: A "lint" like feature that scans interpreted code and warns of suspicious stuff.

Anyhow, this issue is a classic holy-war between coders that has been going on for decades. Personally, I am more productive with dynamic languages, but for other people this may be different. I only know what works for me.

Re:Type Checking = false promises

[dvdeug]

It has also been proven that staticly-typed languages use up more code.

Is there a finite supply of code somewhere? If there is, then APL all the way. Otherwise, what's the issue here?

No, just *most* of the time.

Doubtful. Strong typing makes the weird stuff stand out like it should, and the normal stuff needs no typecasts.

A "lint" like feature that scans interpreted code and warns of suspicious stuff.

The only way for a lint program to even start to compare is if you annotated the program with notes, which reduces readability more than using a strongly-typed language would.

Personally, I am more productive with dynamic languages, but for other people this may be different. I only know what works for me.

Which is quite different from how you've presented the issue.

Re:Type Checking = false promises

[Tablizer]

Is there a finite supply of code somewhere?

My point is that smaller code is easier to inspect as you're are typing it and quicker to write unit tests for. Also, the less you type the less errors you make.

The only way for a lint program to even start to compare is if you annotated the program with notes

No. Example:

x = 3
y = "foo" . x // assume period is append

The second line is suspicious because we are append a string to something that looked like a number originally. Ideally we could tell such tool to stop flagging a particular suspicious spot if we really want to do this.

Which is quite different from how you've presented the issue.

I have found over the years that a whole lot of software engineering is subjective (depends on individual psychology) such that it is redundant to explicitly state such.

Re:Type Checking = false promises

[Tablizer]

And well, I don't get the hype of dynamic typing anyway

Like I stated in another reply, it is perhaps a subjective thing. If dynamicy does not work for you, then so be it. Some people seem more productive and comfortable under dynamic languages and others under static ones.

I started out under static languages for the most part, but slowly realized I prefer dynamicy. Sure, it results in some kinds of problems that type checking would have cought, but the reverse is also the case. Another way of saying this is that static typing catches more "dumb" errors, but results in more logic errors because it is harder to read what you are typing. At least for me.

Re:Type Checking = false promises

[dvdeug]

My point is that smaller code is easier to inspect as you're are typing it and quicker to write unit tests for. Also, the less you type the less errors you make.

Again: APL all the way, baby.

Your unit tests shouldn't change at all; in fact, they can be come shorter, since they don't have to test the constraints embodied in the strong checking.

The second line is suspicious because we are append a string to something that looked like a number originally.

This is a simple case; just as importantly, it's going to flag every time you want to append a number to a string. Why is

x = 3
y = "foo" . x // LINT: Shut up!!!

better than

x = 3
y = "foo" . image (x)

?

I have found over the years that a whole lot of software engineering is subjective (depends on individual psychology) such that it is redundant to explicitly state such.

Then why are you arguing it? I don't sit around arguing whether Coke is better or worse than Pepsi, because it's purely an individual preference. It's absurd to make logical arguments about subjective issues.

Re:Type Checking = false promises

[Tablizer]

Again: APL all the way, baby.

APL is only less code for a narrow set of problems. (However, it has hints of "table oriented programming", which is my pet favorite and reduces the need for array coding.)

Your unit tests shouldn't change at all; in fact, they can be come shorter, since they don't have to test the constraints embodied in the strong checking.

No, I only need one isInt() function, while you have to declare "int" at least twice: once in the original function and once for the test parameters. Plus, inspection functions often combine multiple constraints into one test. Example:

checkNum(foo decimals=0 minsize=0 maxsize=9999 etc)

It is not realistic to make a "type" for every possible combination of these constraints.

As far as your coding example, one can have an "image" operation for a dynamic language also if you really want one (to supply both intent and checking).

It's absurd to make logical arguments about subjective issues.

Are you saying there are no logical arguments in the field of psychology?

Re:Type Checking = false promises

[grumbel]

### The only way for a lint program to even start to compare is if you annotated the program with notes, which reduces readability more than using a strongly-typed language would.

The annotation could actually be pretty small, ie. only annotate the cases where its not the obviouse and derive the rest by the way the code is written. Haskell for example can detect which type a function has based on type inference, one can still manually specify the type, but for most stuff its simply not needed. Variables for example could simply 'locked' to the first type they get assigned to, everything else could then be reported as error/waring depending on the settings, ie. a = 5; str = "10" + a; => error. Sure, this doesn't work always, but for most of the code it should already be a great help.

Re:Type Checking = false promises

[Tablizer]

APL is only less code for a narrow set of problems.

I should clarify another aspect of this. It depends largely on how you count code size. APL has special symbols for operations that would normally be words in other languages. If we had a single symbol for "while" for example, should that count as being less code than the word "while"? Perl does similar things by using the entire keyboard of symbols in place of keywords. It is like claiming that Chinese is less wordy than english because it uses mostly (but not entirely) pictograms instead of phonetic-based word construction.

To "normalize" the comparision, it would probably be more fair to expand the symbols to equivalent words. Counting code-size can also turn into a holy-war, I would note.

Re:Type Checking = false promises

[dvdeug]

Haskell for example can detect which type a function has based on type inference

I would consider Haskell a strongly typed language, as types are known at compile time. I think the difference between strongly typed and weakly typed languages is between systems that know all types at compile time and those that figure them out at run time.

Re:Type Checking = false promises

[dvdeug]

It's absurd to make logical arguments about subjective issues.

Are you saying there are no logical arguments in the field of psychology?

That's a non-sequiter. You aren't talking about psychology. A subjective issue doesn't have a logical basis to argue about; that's why it's not objective. Psychology, as a science, studies objective, testable, things.

Re:Type Checking = false promises

[grumbel]

The difference is however in the implementation, not in the language itself. In Haskell the compiler can figure out the types, even if I don't give him any hint, in Python the interpreter can't, however not so much because of the difference in language but simply because it doesn't even try to. Sure, there are lots of situations (eval() and friends) which make it impossible to give a 'right' answer about the type of an object, however those are relativly few in most code and could be easily be flagged 'away' if the language would provide support for that.

Re:Type Checking = false promises

[dvdeug]

The difference is however in the implementation, not in the language itself.

I don't believe that's true. Haskell, by definition, uses strong type inference, so that is part of the language itself. A Haskell program that misuses types in certain ways is not a valid Haskell program.

Languages with type inference usually publish a sheet showing how it all works with the type calculus, because type inference can run very quickly into the Halting problem. In

a = 1
b = f(x)
a = "string"

, a changes types iff f(x) returns. If you would protest that that is not realistic code, then

if f(x) then
a = 1
else
a = "string"
end if;
[...]
if f(x) then
a = 3
else
a = "queue"
end if;

which changes types iff [...] changes what f(x) returns. You could add a complete type system, but it would inevitably rule out things that work correctly and don't seem "tricky" to any programmer who doesn't think using the type calculus. You will have in effect built a new subset language on top of the old that's rather different in usage from the original.

Build it three or four times then it'll be good

[TheLink]

To take the analogy from other Engineering fields:

The first one (v1.0) is the "Blueprint". With software the blueprint actually works like the Real Thing! Compiles, runs, makes the right noises, blinks the right lights etc. But it should never be mistaken for the Real Thing.

The second one (v2.0) is the equivalent of those plastic/clay models. You do various tests on these. Go back to a new blueprint if you've screwed up badly.

The third one (v3.0) is The Real Thing. It'll have bugs of course, but by this time it should mostly work as expected.

The fourth one (v3.1) is The Real Thing with the annoying bugs fixed - equivalent of a renovated house just the way the customer now realizes they want it.

The fifth or sixth one (v4.0?) is when a bright spark or two decide that something fancy is needed and adds pink flamingoes, garden gnomes, ornate parapets, Clippy and other stuff. Things start going downhill soon.

The big trouble with software is it costs about the same to do each stage. So most of the time people try to sell the blueprint (and usually get away with it ;) ). The more responsible ones sell the plastic models...

And that is one reason why most software isn't that good.

The other reason is most programmers are crap (and many use languages which highlight their crappiness - e.g. C or C++). There are tons of crappy books and few great novels. Spell checks and good proof-reading won't make a crappy book good - they can't fix a plot with holes like a sieve... Good editors (auditors?) are rare.

But fortunately(?) for us all, many people still want to buy crappy books ;).

Caveat: I'm not a Programmer/Software Engineer and have no Comp Sci or IT degrees (I'm just an IT security consultant), so take my words with a dollop of salt if you may.

Software dev is getting a free pass, who knows why

[Anonymous Coward]

Look, there's a couple hundred posts in here already about how to improve software quality. To me it's all besides the point. We already have a rich collection of ideas and approaches to improve things. The problem isn't a lack of comprehension about how to improve in terms of coding practices or general development processes. Most individual coders and their immediate managers IMHO already know very well what they're doing and what they're not doing right.

The problem is a business problem originating 'higher up'. The folks who own and run software development companies simply know what they can get away with. At the present time they can get away with selling defective software. I don't know why but for some reason the marketplace mechanisms that normally correct this sort of quality problem aren't working.

The whole software dev industry is basically in denial about this. We like to talk quality but in reality our customers don't demand it and we don't produce it. Until that overall dynamic changes how can anyone expect the PHB's to do anything different. No responsible PHB is going to spend money on something producing no return.

Btw, can anyone explain why this isn't the case with other high tech products. We all expect our home electronics etc to work 100% perfectly but with pure software products we're much more tolerant.

Re: prototypes

[Anonymous Coward]

Some of the best programs I've ever used are/were proof of concept. In many cases, releasing the prototype is the only way the product will ever see the light of day. Once there's a demand for the original, the company can afford to design a 2.0 version and spend hundreds of thousands of dollars building it the right way. If a company refuses to ditch the prototype on the 2nd release, then the product is doomed.

Rule of thumb:

• 1.0 is a prototype/beta.
• 2.0 is the first redesign.
• 3.0 fixes 90% of the bugs and adds user-requested features.
• 4.0 is nearly perfect
• 5.0 is a needless redesign
• 6.0+ are just spiffier graphics and/or useless redesigns.

Two years later, someone releases a prototype similar to the original 4.0 and the cycle repeats.

No tests

[12357bd]

I've never believed on testing.

It may sound crazy these days, but it is not.
Never saw a non trivial piece of software (read 'real application') that is 'FULLY' tested.
The whole concept of 'QA' on software is ridiculous, software has two main propieties that invalidates the whole concept:
1 - The complexity factor, interrelation between parts give an exponential number of possible error conditions, testing those conditions, simply takes too much time.
2 - There's no way no qualify a design as 'good', that's a application dependent evaluation, not an objective one. The best we can say about a given design is that is not that bad, we cannot logicaly assure quality on design.

I can understand the bussiness need of such concepts, and the real opportunity of people doing bussiness around them, but pretending QA is something more than a buzzword and a bussines catchword is simply false.

Re:No tests

[Kourino]

... so you're telling me that testing and QA are equally worthless on modern processors like the (massively complex) Itanium family? They may not perform as well as expected - that's due to incorrect assumptions about things like compiler quality and actual effectiveness of features like predication - but when's the last time you heard of Itanium chips being recalled because they didn't run code correctly? I doubt one would argue that Itanium implementations, with their 220 million transistors and "more lines on them than a London road map", are somehow trivial compared to a modern software application. If QA can work for complex things like hard drives, aerospace vehicles, and modern microprocessors, I'm guessing there's a way to successfully apply it to the software industry.

I've seen it said that testing is not the exact same thing as quality assurance. I don't know what else people associate with QA, but you may want to consider that possibility.

Re:No tests

[Anonymous Coward]

Uh...is there a CS professor that lost a first year student here? He's wandered into Slashdot. Please come and claim him. If he's not claimed by midnight he becomes the property of OSTG.

Re:No tests

[12357bd]

I think you have a point here, but realize how strict your example is, a piece of hardware!. That means an strict set of inputs and operands with a predefined set of outputs.
The case is not trivial but is well defined, on the other hand, consider how any simple database independent piece of software becomes far more complex if you pretend fully tested portability across a range of database implementations.
Or consider any program expected to run upon a posix implementation, the program may be simple (ie, open/read/close), but the working instances inherits the underlying complexity of the running posix implementation, and so the testing should consider the different posix implementations and behaviours, becoming 'de facto' impossible to test properly.

I've been thinkink about software as an industrial activity for more than 20 years, but it seems that as long as writing software is not fully automated, I see no way to seriously consider QA on a 'hand made' product.
In the end we deal with uncertainty, and logical proof of correctness are always the exception, never the rule.

Yes, Design is the thing....

[tiger99]

.... which is often lacking. Too may people just sit down and start to code.

Things like UML, and before that, Yourdon, and lots of others, are there as methods of expressing the design, before a single line of code is written. So are textual documents with pseudo-code, and informal sketches in the designer's log book, and lots of other things, which ought to be considered as vital parts of the source documentation. And of course, Requirements Specifications are absolutely vital in any branch of engineering. You really do need to know what you are designing!

The change control process needs to include everything that is used to generate the final code, so that it is all kept up to date.

I don't think that Sir Bill comprehends this, because otherwise the Criminal Monopoly would not be changing the fundamental requirements of Latehorn right now, ripping out bits that they can't implement, in the same way that every new piece of bugware they create is utterly lacking at the front end of the process, and is hacked and patched (in the derogatory sense) till it "seems" to work, at what should be the tail end of the development process. But there again, I don't think that Sir Bill understands anything that is remotely technical, but he does have better comprehension than most of new ways to run an Illegal Monopoly.

Where is Wales?

[aaronmcdaid]

Wales doesn't exist, according to the EU

Zero day holes are nothing new

[mikefe]

What? They only found out about zero day holes recently?!

Ever heard of a one night stand?

Nevermind, wrong site...

INTERFACES INTERFACES INTERFACES!

[argent]

Good interfaces is why UNIX originally took off. Back in the '70s when you had to actually call the OS rather than just doing (say) Fortran formatted I/O, you had to do stuff like:

Allocate a file control block. In assembly, this was usually done statically at compile time. In Fortran it was usually a global common.

Call something like SYS$INIT%FCB

Fill in half a dozen random fields in the FCB with magic numbers. Like, file mode, file type, access mode, device type, file name, file extension, file owner, file password, read key, write key, tape policy, ...

Call something like SYS$OPEN%FILE, which may involve two or more calls. If It was a device, you might need to call SYS$ATTACH%DEVICE, for example, or SYS$LOCK%FILE...

Repeat the above for an I/O control block. If the I/O control block doesn't contain a buffer, repeat the same for the buffer. You may need to allocate an event flag, or just pick one and hope that the same one wasn't used by another library. You may need to allocate a "mailbox" or other asynchronous I/O endpoint.

Call the variant of SYS$READ%BLOCK for the file type or device type you're using. You could be calling SYS$READ%BUFFERED or SYS$QUEUE%IO followed by SYS$WAIT%IO.

Do something with the buffer.

Manually increment the block offset in the I/O control block.

Repeat the reads until done.

Release the I/O control block, and any event flags or mailboxes.

Call SYS$CLOSE%FILE or SYS$RELEASE%DEVICE or whatever.

On UNIX you did this instead:

int fd;
char buffer[BUFSIZ];

fd = open("file name",mode);
if(fd != -1) {
while(nr = read(fd, buffer, BUFSIZ) > 0) {
do_something_with(buffer, nr);
}
close(fd);
}

This was revolutionary. Really. It's not perfect, but it's so much better than what we were using at the time that it's no wonder people couldn't wait for AT&T and re-implemented UNIX from scratch several times.

This is the same kind of improvement we need in our interfaces for GUIs, databases, network services, and so on. Even the Berkeley socket interface is too complex... all those details of address formats and address structures? Those shouldn't be there... you should be able to do this:

fd = open("/tcp/host.domain/http/options",mode);
// or at least fd = tcpopen("host.domain","HTTP",sockopts);
if (fd != -1) {
...
close(fd);
}

Yes, there's libraries that do this, but they all have the same socket()...gethostbyname()...connect() stuff under the hood. This should be handled at the system call level.

As for GUIs... Plan 9 is about the only one I've seen that looks like it's even trying to reach the level of clarity, safety, and consistency we need.

Re:INTERFACES INTERFACES INTERFACES!

[spectecjr]

Yes, there's libraries that do this, but they all have the same socket()...gethostbyname()...connect() stuff under the hood. This should be handled at the system call level.

Try writing a library of your own that wraps it all up in a nice pretty bow, and you'll quickly see why it looks like that. There are some abstractions which you just can't abstract away any further without losing functionality - and the sockets library is one of them. You can either have a general networking library, or a nice sanitized easy-to-use-by-kindergarten-kids library - you can't put both in the same package.

Re:INTERFACES INTERFACES INTERFACES!

[argent]

Try writing a library of your own that wraps it all up in a nice pretty bow, and you'll quickly see why it looks like that.

0. You can do things at the OS level you can't do in a library, but I've used a canned tcpopen() library and implemented my own, and for 90% of the code all that extra stuff *is* surplus... and the other 10% can be handled with a clone device.

1. I can open a terminal with open(), just like a file, but if I want to do complex things with terminals I need to call ioctl() and fcntl() and open the non-blocking device or call open with O_NONBLOCK and... but I can also tie all that down at the OS level and just call open().

2. The UNIX API *did* reduce the functionality compared to the existing APIs. Massively. People complained. You couldn't specify all kinds of things that were important, but it turned out that some of them were important and some of them weren't.

Here's what I'd like to se gotten out of the socket API:

1. gethostbyname() and anything else that ends up requiring the application know about address or endpoint formats. At a bare minimum the standard system call should always take a string, with a flag to tell if it's a hostname or an opaque (to the application) address. Applications that need more can use the equivalent of ioctl(), to get the address from the name or vice versa, you call the equivalent of stat() or readlink().

That's the biggy, if you did that, the whole IPv4 vs IPv6 vs IPX vs CLNP vs CONS mess would just vanish. You'd use the same API for streaming connections on ANY network that supported them, and you'd never even need to know what an address it.

Then, to finish integrating it with UNIX:

2. abolish the separate socket/connect or socket/bind: these should be handled by passing the right string to open. Listeners would still need to call attach(). Again, if you're doing something more complex you use the ioctl() interface... but most programs wouldn't.

What? What about programs that NEED to deeply grok the network? Wouldn't they be more complex? Maybe a little more than they are now, if at all. They're already pretty complex as it is, and a lot of programs could be disposed of or turned into shell scripts.

Do I expect this to happen? No. It's a very small complication compared to the horrors in GUIs, but it's stuff that shouldn't have been frozen until it had shaken out more.

Re:INTERFACES INTERFACES INTERFACES!

[Anonymous Coward]

..you can't put both in the same package.

Huh? Sure you can. Why exactly cant you make a package/library/whatever that offers both, the easy-to-use-kindergarten call built upon that bunch of 1337-haxorz functions you can use for the voice-over-SMTP stuff?

Holy grail of reusable objects

[bastafidli]

Pretty interesting reading especially since it touches several points we are also trying to make with our OpenSubsystems project.

He says: "Of the much-vaunted 'holy grail' of reusable objects, Cox said, "As far as I'm concerned these all generally suck too. Part of the problem is that they're sold as products and the original ideas behind a lot of reusable products is that you wrote it once. If you write it once, it has to do everything. If it does everything it's complicated, and if it's complicated, it's broken. That's not always the case but it is quite frequently the case.""

I cannot agree with this point. It is impossible to start every project from scratch and even though not reinventing the wheel, create your own version of it. Using his own argument about microprocessor industry, microprocessor manufaturers mastered the art of creation of complex and reusable objects Similar examples can be found in other areas of life (construction industry, car manufacturing). Since it is possible to do it in hardware, there is no reason why software components cannot be complex and still reusable but still of high quality. The software industry should probably learn their lessons from the the above mentioned industries.

Some of the critical requirements to get to that point are

Be specific then generalize. Only very few people have the capability to abstract the patterns to create reusable piece of software. If the generalized patterns don't match the actual need and use, they will not be used. Create software you need and that does exactly what it needs to do. Then go back, review, revise, observe and only then extract the common themes into patterns and reusable components. Replace the specific parts of you system with the newly identified reusable components.

Start simple. Most software projects struggle with incorrect, invalid or misunderstood requirements. It is impossible to create something, which can be reused if we do not understand what it should be used for. When trying to create reusable component, do not try to encompass "infinite and everyting". Take only the pieces, which are truly generic and handle other scenarious by inheritance or customization. Software follows 80/20 rule where 80 percent of users use or need only 20 percent of the provided functionality. Your generic components should represent those 20 percent.

Good interface. Design good interface for your reusable components. This is what everybody will be using with the rest of the software being just a black box for most users. If you do not get the interfaces right then the component will not be used correctly or as often as it should be. If they are not easy enough, the perception will be it is easier to recreate it than reuse.

Test, Test, Test. There is no excuse for releasing code, which doesn't work. The reusable code represents you and your reputation and it is much easier to loose a good reputation than to gain a bad once. Think about it as warranty. It plays a big role when buying car or house. Why shouldn't it play the same role when buying software.

Extend and iterate. Once you got the simple reusable object right, customized and extended it few times for specific situations look back and identify the next set of common behavior. Listen to your users. Instead of including every new feature into the simple component, think about creating new extended version, which can be reusable as well. This way you can still provide and use the simple object when the simplicity satisfies the requirements without confusing users with the additional bells and whistles.

Documentation. Without documentation it is difficult to use any slightly more complex object. Without documentation it is hard to communicate your ideas and intentions. The better you communicate the larger audience understands you.

Re:Holy grail of reusable objects

[skids]

This comment irked me a bit as well. But I think what he's getting at is that most of the time when people write reusable objects, they get it wrong.

Personally I think good evidence for this is the lack of dominance of any particular implementation of reusable objects in a certain area. If there's not one or two accepted "best" libraries, then to me obviously none of the libraries are of satisfactory quality.

And writing such things is hard, not on the actual level of writing the code, but in the amount of consideration and discipline involved in deliniating the boundaries of the object library.

Personally I wish there was a project which aimed to study the use of 3rd-party reusable object libraries across the OpenSource codebase, figure out which ones were the best or what needed to be done to make one of them the best, and then, with extreme tact and backed up by helpful coders, encouraged projects to switch away from the inferior or in-house implementations.

Part of the point of OpenSource is sharing code, and this seems to happen less often than it actually should.

Why not just use PHP?

[Anonymous Coward]

Since PHP is a scripting language, you can write pretty much anything and something will happen when you run it. Usually PHP does a pretty good job guessing what type you meant and such, so it kind of fixes your bugs for you. That way you don't have to test your code.

Languages: we have a lot of room for improvement

[descubes]

Concept programming is an approach to programming that I hope will yield improvements in quality. If your code is structured like what it represents, then it's easier to understand and maintain. This simple idea yields interesting metrics, and highlights issues that are a bit hard to spot otherwise.

Over time, I became convinced that a new language was actually necessary to implement concept programming correctly. It turns out that some of the tools developed for XL help many other things (like documentation, good interfaces, automated tools, etc).

Devoid of any new info

[Anonymous Coward]

If I ever had an engineer working for me who didn't already know all of those points that Alan Cox writes about, I'd fire him on the spot.

Alan Cox wins the award for having a firm grasp on the obvious.

I actually read the article and watched the video hoping that there might be some new information in there. But alas, it's all just normal everyday qa processes.

His diatribe against explicit memory allocation didn't really belong there. While there certainly are issues with it, gc is no panacea. It just puts the burden on code that you don't control. I can't begin to tell you all of the bugs I've tracked down that were caused by bad gc implementations.

The title

[esap]

I first read the title as "Alan Cox is writing better software", and thought that finally he's doing that :-) Then I realized my mistake and was disappointed.

Positive Code review experiences

[KenSeymour]

One place I worked had mandatory code reviews. It accomplished a couple of things:

1) Enforced variable naming conventions including informal exceptions to the convention. "You get i, j, and k for free."

2) In an environment where there were both employees and contractors, it made sure that there was no code that only contractors understood.
It also makes sure that there is no code that only one person understands.

3) It kept gratuitously clever code (usually mine) out of the production system. An example of this, in C++, was using constructor syntax in integer variable declarations, e.g. int i(5); instead of int i = 5;

4) Other programmers would make suggestions as to where they would like to see comments added.
As a result, comments were put where the code was hard to understand, not where it was obvious.

5) Oftentimes somebody would catch where the code didn't match the comments.

It mostly worked because there was a strong manager that knew the personalities, chose who reviewed whom, and kept pointless arguments to a minimum.

Any given software development practice will not solve all the problems by itself.
Code reviews won't catch all the bugs. Unit tests won't catch all the bugs. Design diagrams won't prevent all the design flaws.
But applying pressure on all these fronts, combined with talented team members, will improve the quality of the software.

QA

[Brandybuck]

...but others seem heavily influenced by his recent MBA. In particular, he has a lot to say about Quality Assurance in the software world...

Software QA by normal people: Test the product.

Software QA by MBAs: Assure that twenty thousand meaningless documents are signed, perform audits to ensure that these documents are signed, provide mandatory training so engineers know how to sign these documents, award bonuses to those who sign the most documents, define productivity to be the number of signed documents in an engineer's cabinet.

Quality assurance is dead.

[Pathetic Coward]

Any programmer that tries to "convince" management that quality assurance checking is desirable will be first on the outsource-to-India list.

Management doesn't want any backtalk about "quality". They expect the programmers to do things right the first time; that's what they're paide to do. When management has compliant workers in India that work cheap, follow instructions, don't talk back, and aren't around the manager's office geeking up the place, they're not going to bother with "quality assurance" insubordination. In particular, programming methodologies such as Extreme Programming that require greater management involvement in the coding process will be treated with scorn; management wants less involvement, not more. As to whether or not the code actually works - once it's out the door and bonuses are in hand, who cares?

Re:Quality assurance is dead.

[dubl-u]

In particular, programming methodologies such as Extreme Programming that require greater management involvement in the coding process will be treated with scorn; management wants less involvement, not more. As to whether or not the code actually works - once it's out the door and bonuses are in hand, who cares?

Well, for one, companies that want to make money. A company may be able to get away with shipping crap for a little while, but it's rare that somebody can do it for long. Why? It's not just that customers notice. A cruddy code base is hard to build on, so low initial quality means slow development for the life of the code base.

Once a manager has experienced doing a project right, it's pretty rare they want to go back to the old, painful, unproductive way of doing things.

Re:Quality assurance is dead.

[Anonymous Coward]

I don't know about your experience, but in our company the guys hires in India do most of the QA. Of course, there are code reviews and automated testing for every code change, but the rest are done by them. From my overall experience, companies don't hire programmers in India to do the creative work, but mostly for the manual jobs with well established processes, which can be easily done by anyone. Once they will take over the development, I will start to be really scared of my job. Right now I have no problem talking back to my manager and its him who will push QA, if you work for a good company. Seriously, go and find a better job, your company sucks.

Quality is not profit

[Anonymous Coward]

Stunned by the horrible quality of the software in the megacorp I work for, I was complaining to a dot-com millionaire friend of mine who got rich on a different company. It was enlightening.

He related the experience of meeting one of their VPs. Turns out the VP was famous for having realized that every customer service call was an opportunity to SELL MORE PRODUCT. Their profits went up. Wooo-hooo! Writing SHIT CODE actually made them MORE MONEY.

I realized it was the same with my company. On all the on-line forums I hear "I'd never buy any other brand. I once had this horrible problem, and their customer service was so responsive! They fixed the problem!" It never seems to occur to customers that if the product actually WORKED they wouldn't have needed to call support in the first place. Shit code boosts our profits, too. People get a warm fuzzy talking to good customer support, no matter how bad the technology is.

There are other ways to benefit from bad code, especially if you dominate the market. Releasing a new version? If you botch the backward compatibility it forces everyone to upgrade! Profit!

So, what's all this nonsense about better code?

Programmers often clueless about managing projects

[AHumbleOpinion]

Yes your average programmer/engineer might be able to manage a project.

I think that is way too generous, if we are going to continue the Dilbertisms keep in mind that your average programmer is mediocre in the profession that he/she has been trained for. Why would you think he/she could do well in a profession that they are not trained for?

Overall I agree with you. The problem is that there are very few people who are trained in both technical areas and management. More often than not a person in a given position has knowledge of one side and ignorance of the other, or possibly contempt as so many posting around here show. The geeks with the later attitude are the nerd equivalent of the pointy headed boss and are probably making their own contributions to project failure, should we coin the acronym point headed geek, PHG?

Original ideas are highly overrated

[AHumbleOpinion]

There wasn't an original idea in the whole article in the link to this thread

Original ideas are highly overrated. When the audience is ignorant of high level ideas, mid level ideas, and may have only heard but not understood the low level ideas, it is far better to go over the old material once again.

"ElitistWhiner", +1 for cuteness.

Re:Original ideas are highly overrated

[Alan Cox]

If you are giving a talk to people in small businesses do you want to give them a list of things they can do or have an esoteric discussion over the relative reliability data for C++ and Java exception models ?

I'm glad you don't think the content is original - that means you are one of the people who actually has some idea of how to write good code and automate/enhance the testing side. Unfortunately to a lot of people out there actually writing code in business the concepts are new.

This was Alan's morning talk to local businesses. I'm suprised it was even worthy of slashdot, when things like Indymedia disks being seized by the FBI and rackspace are apparently not even noticed by the slashdo crowd

Oh wait .. Rackspace are advertisers
8)

Alan

Re:Which is better?

[Anonymous Coward]

Alax Cox on quality assurance
-or-
Sex with a mare

Or a governor.

what about web site quality?

[nazsco]

images on the background of large portions of text is a NO NO!

Refactoring

[znaps]

Refactoring is the key to quality, especially with commercial software which is on a regular release scedule. If all development projects had a fixed Refactoring phase, after every release, the codebase would be better designed, more maintainable, perform better, bugs would decrease, and new features easier to add.

Unfortunately convincing most managers of this is nigh on impossible. They somehow infer that it means that you write shitty code.

Alan Cox doesn't get it...

[renehollan]

... which surprises me because he is one smart dude.

All his points are valid, but (a) dangerous when taken as gospel, and (b) miss the forest for the trees.

What kills software is complexity. I've been writing code professionally (i.e. getting paid for it) since I was 15. It's been 28 years. Starting with Dijkstra's "GOTOs Considered Harmful", I've seen fads to improve software reliability come and go: structured programming, object-oriented programming, garbage collection to handle memory leaks, etc; as well as programming languages prividing the syntactic and semantic sugar to support the fad du jure. Hasn't helped, has it?

The general problem is one of managing complexity: if you can "come from" anywhere to a snippet of code, how can you ensure that all your assumptions about the context you're in are valid? Similarly, if you can access a global variable, well, globally, how can you be sure it contains what you expect? How do you know all the ways your data can be accessed? How do you control when and where an object is destructed, or that all resources (memory being just one) are freed?

Either restrict who can do what, or restrict the assumptions you make about the things you are operating on.

Using a garbage collector restricts who can allocate and deallocate memory. Object oriented programming restricts who can muck with private members. Structured programming restricts how you can get somewhere. O.K. wise guy, how are you going to write a garbage collector without dealing with raw memory? Gee, you have to get your hands dirty. How are you going to deal with private members inside private member functions? Gee, looks a lot like functional programming with globals, doesn't it?. How, the heck are you going to compile that loop without a jump at the end? Gee, what was that about GOTOs?

The trend appears to be to try to find the "next great technique" which will provide the best bang for the buck when improving quality. All of them help. None of them enough. Frankly, this incremental approach is not going to solve the problem of defects that are a result of the product of human error and code complexity. We need to learn how to manage complexity on its own.

Are there any examples of success in managing complexity, and can we learn from them?

I think so.

The best example I can think of is a compiler. Look at how many different inputs it can handle and still produce correct machine code with a fairly low defect rate. I attribute this to the fact that its input is highly structured: it has to follow strict syntactic rulers. Thus, when compiling something, one has a great deal of knowledge about the context in which this occuring. Yes, you have to deal with semantic issues (types, declarations, etc.), but an unambiguous language should make this clear.

One can point out that programming languages are well-specified, so implementing a compiler is relatively easy. If only all requirements were so detailed. I don't think that's it, however: one can come up with very detailed specifications for a complicated system that's difficult to implement. A programming language, by contrast, can be syntactically expressed in a few pages of BNF.

Contrast this with a user interface, where various elements need to be enabled or disabled depending on what other elements have been previously activated, or used to gather data. How easy or difficult is it to "forget" to enable or disable a control? If you see a parallel with this problem and excessive use of GOTOs in a program, you're starting to get a feel for what I'm talking about.

What has happened in the past 25 years or so of programming language evolution is that the complexities of the past have been pushed and morphed into the complexities of the present. And tackling one in isolation (memory management) does nothing for a transformation of the same problem (resource management in general -- memory isn't the only thing that leaks), though it may provide the best bang defect-rate-reduction-wise

Re:Alan Cox doesn't get it...

[pkhuong]

With all this talk about goto as the ultimate control flow, i'd say it's pretty clear someone doesn't grok continuations.

Re:Languages: we have a lot of room for improvemen

[Anonymous Coward]

Can you summarize in clear terms what the difference between concept programming and object-oriented design is?

Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.

Re:Languages: we have a lot of room for improvemen

[Anonymous Coward]

I took a look at your webpage. Kudos on the effort. However, it looks like you're reinventing a clone of python. No offense, but I think you'd probably be better off making a frontend for python, given how many "in progress" and "todo" items you have (and the fact that those make up a significant portion of your total project).

Disclaimer: I'm not a fan of python, but I'm working on a language of my own, so I make it my business to read about and compare language ideas. While it looks like you've spent 90% of your time documenting, I've spent 90% of my time writing code. I have a working interpreter that runs an order of magnitude faster than interpreted perl or python, and I'm about to make the leap to JIT compilation. Anyway, once my compiler is ready, you may want to think about writing a frontend for it. (Note: I don't have a website yet, and I won't publish the spec until I finish my compiler.)

Re: bad Quality Assurance.

[Anonymous Coward]

Quality Assurance:

QA of GCC sourcecode (C,C++,...) is very bad (demonstration: gcc-4.0-ss is very unstable and dirty).
QA of C# Mono (from Novell?) is very bad (demonstration: it has memory leaks, the guilty is who uses Boehm GC).
QA of Java from GCC is very bad (demonstration: it has memory leaks, the guilty is who uses Boehm GC).

open4free ©

oh, exactly

[foog]

Unix read is not always what you want, and the error handling leaves things to be desired, and you end up with having to make choices like this, that aren't covered in too many books (and just try explaining the trade-offs involved to a knuckle-headed mediocrity):

My favorite AOLserver story starts in the seventh-floor lounge of the MIT Artificial Intelligence Laboratory. I was asking Robert Thau, primary author of the Apache server program, why the Netscape 1.1 server was so slow. He said "Oh that's because those guys don't understand Unix. They're actually using the read system call to read files." Everyone in the room laughed except me. What? What's wrong with that? I asked. He replied, "Everyone knows you can't use read; you have to use memory-mapped I/O."

I knew that the NaviSoft guys were about to release a new version so I thought I'd give the naifs in Santa Barbara the benefit of some hard-core MIT engineering knowledge. I told them the story and asked them what NaviServer, as it was then called, did. They replied "NaviServer uses memory-mapped file I/O on single-processor machines but automatically configures itself to use operating system read on multi-CPU machines so as to reduce shared memory contention."

Ah.

--Philip Greenspun

But yeah, for the kinds of things I'd use a scripting language for today, Unix file i/o is OK and all.

Re:oh, exactly

[argent]

That sounds like a "stupid UNIX design" story, but consider: you memory map a file you've opened, you don't use a completely different set of system calls to do it. And you map anything else that looks like an array of blocks the same way: a raw disk partition, for example. You don't have to use a different set of system calls to copy a raw CDROM image in, you just read from (or map to) /dev/cd0c (or whatever).

Where to begin...

[andymac]

OK, first off let me fess up: I am a QA manager, have been for near on 10 years now. I've worked on projects with MS, Adobe, IBM, Sun, yadda yadda yadda. All sorts of projects and languages, products and programmers.

Cox really does highlight some of the best practices out there, but he also skims over some key ones. The biggest problem I've seen out there (and I've done QA Management consulting for a good chunk of those 10 yrs, so I've seen a lot of organizations) is commitment by management. Most QA folk know that there will always be a challenge to find the right balance between schedule/budget, quality of product, and feature set of the product. Do you want it good? now? or stripped down? And most QA folk are willing to work within that mindset. But when management 1) does not appropriately staff QA activities; 2) does not appropriately fund QA activities & annual budgets; 3) does not make it damn clear to all staff that QA is a requirement for project and thus ultimately product success and if you don't like someone testing your code and logging bugs against it, you better move along pardner, the organization pays lip service to QA. Heck even when QA finds a horrible problem prior to release, so there's time to fix the problem, you'd think most folks would be happy (ok, not thrilled because that balance is skewed towards a schedule slip) that there was time to get in a fix. But no, 99 times out of 100, QA is slammed for holding up the process.

Independent testing is a must for an organization to have any real understanding of the quality of the product. Engineers cannot be the only folks testing their outputs. For oone, it's a very expensive way to test - I want geers designing & coding & unit testing not integration or system or release testing. QA folks will cost between 30-70% of a geers salary - why would you want the most expensive resource doing the (in most cases) less technically demanding work? And work they usually don't enjoy doing anyways (grumble grumble, I didn't sign up for this!)

OK, so this is a bit of a rant. I'm just dealing with my current senior management who say they want QA to manage and execute the independent testing, but turn around and find 95% of Engineereing who refuse to participate in the process.

I'll just go have a beer and forget about my problems...mmm... beer... drool drool.

What i like to see in a program

[RobertLTux]

A few suggestions 1 have some sort of switch that dumps a complete config file to ~ (this is an all options with defaults type file) 2 set things so the most common run is shortest 3 assume the files to process are in the current directory (and are wanted in the current directory 4 actually write useful documentation

the key to good software

[Anonymous Coward]

Is good engineers. That's it. When you hire crappy engineers, no matter what you do or what process you implement, it will still be crap. Slightly better crap, but still crap.

Until management and HR people realize it's about hiring engineers who take quality and accountability seriously, the software has the deck stacked against it. It doesn't matter how long that person has been programming. It's about a person's attitude and work ethic. Even in a horrible environment, a good programmer will deliver acceptable software. they won't be happy about it, and will most likely leave, but atleast what they do write will be implemented well, carefully designed and documented.

Stop saying Bzzzt!

[Anonymous Coward]

Stop saying "Bzzzt! Wrong!". It's fucking annoying.

Re:Languages: we have a lot of room for improvemen

[descubes]

Can you summarize in clear terms what the difference between concept programming and object-oriented design is?

There's very little in common, except for the fact that they are both software methodologies :-) From a CP point of view, OO is an approach which models a rather large range of concepts represented as "verb + noun", where verbs are represented as methods, and nouns as objects. For instance, "window.draw()". There are some concepts that OO has trouble with, because they have no easy "verb + noun" representation. For instance, computing a maximum the OO way is tricky. In Java, you'd typically resort to a non-OO static method for that. See http://mozart-dev.sourceforge.net/cp-vs-oo.html for a more detailed discussion.

Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.

As to what makes XL a concept programming language, it's extensibility combined with readability. That it looks like a simple procedural language is by design. It would not be CP if it could not represent old concepts the usual way. It's under the hood that it's really different. And you see when you start manipulating non-standard concepts, for instance a simple plug-in allows you to manipulate symbolic differential forms in your source code. You can't do that as easily, if at all, with any of the languages you listed.

Re:Languages: we have a lot of room for improvemen

[descubes]

Reinventing a clone of python? XL has very little in common with Python, except the indent-based syntax. There's not much that Python can do that can't be done better with other languages. In other words, it's mostly syntactic sugar on well-known concepts. XL, on the other hand, introduces several powerful ideas, and does a few important things better than existing languages I know of.

So I think it's worth doing.

Re:Languages: we have a lot of room for improvemen

[descubes]

Also, what exactly make XL a concept programming language? It looks somewhere between Haskell, Ruby, and a simple procedural language to me.

The old XL (in C++) is about 55000 lines of code. The new XL is about 22000 lines of code. Documentation is a fraction of my time.

Re:Languages: we have a lot of room for improvemen

[Anonymous Coward]

Hi, can you post some kind of mailing list or "New language will be posted here" webpage?

I'd post a page on one of my sites if you don't want to/can't find a free site.
sd_newlang.4.webinfo
[at]
xoxy
.
net

Re:Languages: we have a lot of room for improvemen

[Anonymous Coward]

Well, if you want a pure OO maximum, rather than a Java maximum, then there would be a maximum method on a collection. Add all the numbers to the collection, then call maximum, and it will give you the maximum. Whether or not that would be able to handle comparison of different types would depend on the language (anything that includes generics certainly could), but an OO design like that can inherently handle multiple numbers.

Re:Languages: we have a lot of room for improvemen

[Anonymous Coward]

So far, nobody really expected the compiler to perform the differentiation for you, even if cheap pocket calculators like the HP-48 have been capable of doing this incredible feat for maybe 10 years... But why not?

That's quite simple. Your understanding of how calculators do it seems to be wrong. Nothing that I know of creates a derived equation and uses that. They use numerical methods that make use of the original equation to compute the derivative. With your example, the "incorrect" code is nearly correct. You make the equation into a function (in rough psuedo-code):

func I(t) = K*exp(-alpha*t)*sin(beta*t)

Then you use another function to find the value you want at t:

derivative(I, t)

Which will use the I function with numerical methods to compute the value at t.

Some complexity is required

[oo_waratah]

Complexity is sometimes required to make things work. Sure you can work out simple ways to do simple things but complex things like handling user interaction is not simple, users are not predictable especially when my kids get on the keyboard.

Re:Some complexity is required

[renehollan]

You miss the point entirely.

A complex user interface, with controls being enabled and disabled depending on the previous interactions with the user (possibly intentionally, so as the "steer" the user toward valid interactions), is complex in the same way that a function with many internal GOTOs is complex, and just as "harmful", to use Dijkstra's words.

We shun GOTOs, yet we accept such interfaces, and the style of programming behind them -- does one mean that we've wrestled the inherent complexity to the ground in one case and not the other? Perhaps, but having looked at a lot of UI code over the years, not bloody likely.

We need appropriate abstractions to simplify complex code: With GOTOs, we can enforce structure and scope -- if-then-else, while-do, repeat-until, case, and a plethora of single scope and multi-scope break and continue statements are a testament to this -- one could argue that all you really needed was if and goto, and they'd be right, implementation-wise, but wrong when it comes to managing complexity.

The typical multi-control user interface maps more to the excessive use of GOTOs than it does to a structured approach and so, is "bad", in the same way.

Now, consider approaching the problem differentially: at any point you have some active controls, and some inactive ones. Activating one of the available active ones results in several actions, including the mapping of current active set and action to a new active set. With that model, the individual control activations and deactivations, likely peppered throughout the UI callbacks or event handlers, start to make sense. Ideally, this mapping would be expressed in code in one convenient place instead of willy-nilly.

I know of no programming languages that make this possible (well, C# delegates might help) or elegant.

Historically, the way to manage complexity has always been through abstraction, and most modern programming languages, while supporting more and varied abstraction models, never seam to reach the point where it is convenient to express arbitrary absractions: C++ templates try to do thi (and type traits are way cool), but the meta-syntax of C++ template programming is absolutely horrid.

gcc -Wall

[oo_waratah]

Does a lot of the checking that lint does and it is free and happens every time you compile.

If you check -Wparentheses, I found three assignment bugs in OpenOffice.org already.

Code review is HARD

[oo_waratah]

It is interesting that doing a code review well is very hard. I have a hard time not reimplementing my concept of the code over the top of the code provided. This is incredibly hard to do.

It sounds like your "testing" is the automated testing that you have in place, this is excellent and should be part of the build. Note that you should NOT be testing it yourself before the code review The whole point is to ferret out bugs before wasting time on further testing, ie code, automated tests, review, then test thoroughly.

One of the points of this is attitude of the programmers. If you sit in and say "I tested this and it works" it immediately reduces the incentive to really find bugs.

padraig here

[padraigmcgivney]

hello

[OT] Re:padraig here

[aaronmcdaid]

Padraig, this isn't my journal!
Your after making a comment on a story about the great Alan Cox.
Although this is an old story so it will do.
How's tricks?

I see now ..

[aaronmcdaid]

I see now why your replied to this. It's a comment by me. I thought you'd just replied to a random comment in a story.

Re:I see now ..

[padraigmcgivney]

the journal thing you do has been archived so I can not reply to it but I can to this. I got some work today and some is the operative word. how was the exam?

Re:I see now ..

[aaronmcdaid]

Exam was OK. I'll ring you now. You can start your own journal in ~padraigmcgivney

Re:I see now ..

[aaronmcdaid]

"OK" looks really bad in an email.
I'm quite happy with it, but there's no point speculating about the result. We're not getting the results until around Xmas.

Re:Languages: we have a lot of room for improvemen

[descubes]

Well, if you want a pure OO maximum, rather than a Java maximum, then there would be a maximum method on a collection.

You obviously have not read my definition of a concept cast. A concept cast is when you cannot represent a concept, and use some alternate concept in its place. It's very insidious, and most people don't even realize when it happens.

In your case, you replaced the concept of maximum of N elements with the concept of a collection containing N elements. They are close, but not identical. As a result, semantic noise is introduced, for instance boxing and unboxing, or built-in memory management for lists (it depends on a particular implementation).

Re:Languages: we have a lot of room for improvemen

[descubes]

That's quite simple. Your understanding of how calculators do it seems to be wrong. Nothing that I know of creates a derived equation and uses that. They use numerical methods that make use of the original equation to compute the derivative.

The HP-48 calculator or Mathematica both do the thing that "nothing you know of" does. We could also discuss why the numerical approach may be incorrect.

Re:I see now ..where

[padraigmcgivney]

pick somewhere to use for these messages. i've enabled comments on my journal entry work