Slashdot Mirror

Been reading wiki again?

This is one of the concepts behind XP, is that programmers are more efficient when they work normal hours. "XP defines OverTime as the time spent working that makes a programmer less productive in the long term."

See also: OverTime

Sorry to spoil your Illusions but most /. readers are the Digerati.

Most /. readers are trolls, newbies, wannabes, larval stage or just plain linux fashion victims. The digerati are elsewhere, believe me...

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

• Freeing the Developer from OS Vendor Shackles

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

Some of the most amazing excuses for "software" get packaged up by commercial companies all the time and sold to an unsuspecting public.

This is not always what the companies want, not by any means, but often they feel they have no choice.

Scientific American did an article called "The Risks of Computing" a while back, I'm not sure if Neumann wrote it but it was where I found out about the Risks forum, and what it documented is that in any software system, the number of bugs steadily increases over time but the reproducibility of each individual bug goes down, so in the end you have 100,000 bugs each of which you will experience just once in your career.

There are ways to lower the upward bound of bugs, for example on Linux you can use Bounded Pointers for GCC and make great strides in a hurry - but then although you'll have fewer bugs you'll have different kinds of them.

Improving QA by using test suites is another important step, as I discuss in this article on Using Test Suites to Validate the Linux Kernel.

You think your commercial vendor uses test suites? Guess again. It's so frustrating when I have a client who I cannot convince there's a reason to actually perform QA of any sort, let alone use test suites.

Another way of lowering the upward bound is to use Unit Tests - but despite the fact that I've seen unit tests advocated in many places, and I guess they're more popular, the one time I have ever seen them put into practice on a project I've personally worked on is when yours truly used them on a consulting project last year.

Mike

SOAP and XML don't magically make applications speak to each other, like MS would like us all to believe.
Very true. Sounds like the myth of meta-data that I was reading about the other day on Wiki.

AEP

"if you do it that way, you'll mess up later because ...

Although (from memory, I haven't read XP in a while) the supposed way to go is not to be looking ahead to the next problem (that's what refactoring is for), but to concentrate on your one use case and tests. This is one of the parts that didn't sit right with me about XP. I liked the idea of most of it, although as I was reading I was thinking how it might apply to projects I'd been involved in, and wasn't so sure.

Also, since no-one else has mentioned it so far, the main source for information and discussion of XP (and an interesting read in it's own right) is the C2 Wiki.

There is *ALOT* of discussion on Extreme Programming over at wiki...

http://c2.com/cgi/wiki

If you aren't already familiar with wiki - do so. Comments posted there generally have *ALOT* more relevance than most of the whiney, dumb-ass trolls you see all too often around here!

It can sometimes be difficult to navigate, and sometimes the concepts flow as smoothly as a pile of boulders - but it's definitely something to check out if you haven't already...

Re: XP books. Boy am I stupid. When I finally got my head out long enough for two or more oxygen molecules to reach my brain at the same time, I realized that the ExtremeWay to write a book series is to write the first book covering the most important stories, and then later on write some more books if necessary. Please contribute to the XpBookStories.

(Quoting from the c2/wiki BeautyAintMyBusinessNoSir (which is a response to BeautyIsOurBusiness)):

"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -- Buckminster Fuller

- Dr. Foo Barson

(Quoting from the c2/wiki BeautyAintMyBusinessNoSir (which is a response to BeautyIsOurBusiness)):

"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -- Buckminster Fuller

- Dr. Foo Barson

Probably one of the first web sites of this type would have been the wikiwikiweb. Anybody remember that? I think there's still an incarnation of it around somewhere Granted, it probably isn't as interesting as Slashdot or Everything but I know its been around for a loooong time!

That article is very funny. First, it presents many alleged myths of OOP. Sure, these are very well myths from 70's, I guess there have once been people with such beliefs.

The author seems to confuse OO with some other programming techniques. What does OOP have to do with garbage collection, multimedia, OODBMS, visual programming, or even taxonomies or modelling the real world? These are all part of what programmers need to deal with, but none of them are OOP. So at minimum, blaming OOP for this is seriously misplaced.

The article also confuses and mixes object oriented _modelling_, object oriented _analysis_ and object oriented _programming_ with implementation mechanisms used commonly in major programming languages (e.g. C++). Look at some differently designed programming languages (e.g. Haskell), and you see that none of the assumptions made in that article are valid.

There is the concept of modelling the real world in object oriented _analysis_ (OOA), but even there, the article fails to reveal any insight on the problems people are having with modelling. In reality, no analysis method currently available does adequate job in modelling the real world. Nor are they intended to attain the impossible.

The concepts that programmers are modelling are more complex than many people think. However, mostly all the analysis machinery is exactly the same whether one uses OO methods or any other modelling technology. All analysis methods focus on finding the relevant pieces of information, and creating a simplified model that reflects it. Different modeling techniques make different simplifications. Then the software is written to assume this idealized reality.

The most common problem with modelling is that there are too many things that are simply *unknown*. Good software designers can identify concepts or constraints that are not well known, and reflect this uncertainty in the model by introducing flexibility. How this flexibility is provided is not important. Polymorphism (and not inheritance) is one tool provided by OO to doing this. Asking for user input for the unknown things is another (non-OO way).

In contrast, the article attacks inheritance because it uses a hierarchy. This is just silly. I was not surprised at the references to communism.

For *really* good information, see: Portland pattern repository, or any bibliography server (e.g. NEC Research index)

It's worked wonders in my organization, and I suspect that the "war room" approach lends itself to similar types of productivity gains.

It's worked wonders in my organization, and I suspect that the "war room" approach lends itself to similar types of productivity gains.

"any serious OO programmer knows that an OO language without multiple-implementation inheritance is a crippled husk of a language." I guess Smalltalk is not a serious OO language? But C++ and Perl, which do allow multiple inheritance, would be considered real OO languages? Seriously though, would someone please moderate Socializing Agent's post down to "Flamebait"?

Yes LaTeX2HTML is good. A kludge, but a good kludge none the less. However it remains a kludge.

So, the prequisite for something like this to gather steam is a MathML browser. Another killer reason to get the Moz Lizard.

Then there are structuring issues.

A mad sprawl as generated by a Wiki? Why not, Wiki's tend to self reorganised themselves.

Or a highly scholarly arrangement of committees and subcommittees etc. etc.

I think there is room for both...

Who will host it? Source Forge?

Please someone, start up the ultimate Free Math Site as a Wiki!

Well, it's nice to see that I'm working at a "slacker company", since we only demand about 40 hours a week. Sure, we have managed to do a lot with only a few programmers, but I suppose because we lack the amenities of a foosball table and large television, so we actually work those 40 hours.

I am glad that Greenspun provides more vacation time, but I abhor the attitude that the programmer should spend as much time at the company in the eventual hope of future reward. I know that he scorns "annual reviews", but I'm sure that many employees keep working for the even more intangible promise of stock options. It's always sad when those options become worthless. But we're in an industry that chews up young people only to replace them with H1B's when they get too old.

Some people in this discussion might find Extreme Programming interesting. It too tackles the problem of managing programmers but it comes up with some different proposals. You can check out the Wiki Version here.

Have a look at http://c2.com/cgi/wiki?WelcomeVisitors for enlightenment :)
--

This pretty much derives from pure Athenian democracy. The problem with Athenian democracy is scalability. Too many issues, too many people voting over them, it's just a lot of time that you or I don't have. And scaling that to a state or a nation is ludicrous.

The republican solution is to simply vote for the people you "trust" to vote the way you would. This is a better solution than simple democracy on a large scale, but it has its drawbacks. A lot of these drawbacks occur due to the fact that, since a limited number of people are actually making the laws, whoever controls those people control the nation. And it's a lot easier to control a small number of legislators than a large population.

One solution is a proposed "pebble democracy", described here. This solution relies on the extensive IT infrastructure that we now have, that our forefathers had no access to.

The general ideas are:

1. Everyone gets an equivalent vote (but not necessarily one vote, perhaps one thousand).
2. Votes are kept, audited, and tallied on a computer network. You vote from your own computer.
3. All legislative issues come up to a general population vote. You still need executives and other "fast-acting" officers--democracies are good at long term decisions, not short term ones.
4. You can use as many of your votes as you want to vote on any given issue, until you run out of votes. This way, you have more influence on issues you know and care about, and little or no influence on issues that are irrelevant to you.
5. Anyone can set themselves up as a "legislator" by offering "tickets". A ticket is a suggestion on how to vote that you can download onto your own voting computer, if you trust the ticket's writer. A voter simply allocates votes to a ticket, and automatically uses those votes per the ticket's suggestions.

If you have a setup like this, to screw things up you have to fool (bribe, blackmail, influence) the majority of the populace, rather than just a few hundred congressmen and fifty one Senators.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

I've spent most of my career fixing somebody else's broken code.

This is not to say that my own has always been of the very highest quality, but in fact I decided early on to try to come to a fundamental understanding of what was wrong with software development, to get very good at debugging (I say that debugging is a specialty on my homepage) and to learn to write better code.

In my early years I was initially very shocked at what I'd discover in production use at companies. Over the years I just learned that that's standard practice, in commercial software, in-house software, and even in scientific software (where I have become convinced, because of my experiences with high-energy physics data analysis, that many scientific papers are published with erroneous measurements because of software bugs).

Early on I read that something like 90% of software development is spent doing maintenance programming. Some of this is doing legitimate upgrading, but a lot of it is just spent fixing bugs, and even a lot of time spent doing upgrades would be more productive if the code were of better quality.

After reading this figure and having so many experiences with software bugs, both other people's and my own, I decided very early on to get very good at debugging.

One of the first things I did was adopt the regular use of "lint" for checking my C code. I would integrate lint targets into my makefiles and after editing a source file I would type "make lint" before compiling to objects and lint would check all the files that were out of date with the object modules. Pretty quickly I got to where I could write code that was nearly always lint-clean - but the existing code I worked on would make lint scream with hundreds if not thousands of complaints, often serious things like variables being used before they are initialized.

One of the first solid clues I got about software quality came from Robert Ward's book "Debugging C" - now out of print, it predated the common use of source code debuggers and talked about how to write your own stack crawls and other tools.

Ward emphasized the use of the Scientific Method in debugging, and because I was trained in physics, this came very naturally to me; before that I'd mostly floundered and used printf a lot.

I've gotten very good at debugging and have even worked full-time as a debugger at Apple Computer where I was a "Debug Meister" and my business card gave my title as "Cybernetic Entomologist".

I can easily get highly paid consulting work doing debugging for companies desperate to ship a product (and have in the past) but I don't really like to do it for various reasons, some of the same reasons I quit my debugging job at Apple.

One is that if I only do debugging I don't have something to point to at the end of the day and say "I wrote that". I could say "that works because of me", but sadly there's usually lots of bugs left that I didn't have the time to find so I don't really feel proud of the result. The other problem is that the bugs are usually not there because of something interesting, it's not like the code is mostly good but there's some subtle flaws, rather the code is a heap of dung and I can go in with a pitchfork and do debugging wholesale until I get tired of it and the client or manager decides the rate new bugs are being found is low enough they can feel OK about shipping it.

I don't feel good about contributing to such shoddiness. If a company is not good enough to support quality in their corporate culture I don't want to come in and put on a band-aid for them. It would be an entirely different thing if a company hired me to restructure their development process so that quality was a goal that was achieved through direct application of process but gee whiz no one has ever asked me to do that for them.

I do have to say though that the best thing that ever happened to me is that I became a "technology prostitute" as the author of the original article puts it. One benefit of this is that the process is entirely of my own creation, and almost all of the work I've been given has been to write entirely new products from scratch, so I can engineer in quality from the beginning.

Here's a few recommendations I have. Get good tools. Besides a compiler, editor and debugger, you need a static code checker and you also need dynamic testers. The ones I know about are (I haven't used them all yet):

• PC-Lint static code checking for C and C++. It runs on Windows but Flexe-Lint comes as shrouded source code and is highly portable.
• Spotlight dynamic tester for Mac PowerPC - I use this every day and recommend it highly
• BoundsChecker dynamic tester for Windows
• Purify dynamic tester for Unix (but apparently not Linux) and Windows NT
• Optimizeit dynamic tester for Java - do you know many Java programs have memory leaks? Can you understand why? Not just Java but any garbage collected program.

Finally, to really come to understand the software quality problem in the industry and what you can do about it, read The Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks. The book The Software Conspiracy exposes the complete disregard the commercial software industry has for serving the consumer by providing quality products - I haven't read it yet but it looks interesting.

A very interesting methodology that emphasizes personal responsibility and puts the fun back into programming as well as maintaining quality from the very start is Extreme Programming. I'm starting to adopt extreme programming (the the extent a one man operation can - I can't work in pairs :-/ ) and find it a tremendous benefit.

I don't think she would have understood if I told her I'd been featured on Slashdot and had to take breaks from her to go post...

I did read through some of the comments here earlier this evening and I must say that this has been an excellent discussion. The sheer number of comments posted shows I must have struck a chord with the community - and my experience with other programmers shows that this is a common problem with others.

I'll post tomorrow what the folks on comp.lang.c++ and comp.sys.mac.programmer.misc had to say but they were in general along the same lines as what was posted here:

• Take a break
• Get a life
• Do something fun that doesn't involve computers
• Engage in vigorous physical exercise
• associate with the attractive sex
• Step back from low-level coding and do other software-oriented things like design, discussions with a coworker or documentation

I did in particular step back to think about software from a different level than coding, but I didn't actually do design work. Instead, I just cracked open some good programming texts. If you haven't read much lately there's probably a lot of good stuff that will stimulate you and improve the effectiveness of your work - check the book reviews online at The Association of C and C++ Users (and consider joining it - I did, a couple months ago).

One thing I consider important in the reading I did was that I wasn't looking for solutions to the problem at hand. Rather, I was trying to get back to something I'd been missing for a long time and wanted to indulge in - the sheer joy of learning for its own sake.

It was the case that the books I was reading were pertinent to my work but I wasn't searching them for solutions. I was just reading and flipping through them as my curiousity led me. And when solutions to my problem would occur to me, I'd put them out of my mind until the time I'd decided ahead of time would be my time to resume work.

What actually got me going again was that I had such a flood of ideas and they had crystallized so clearly I was able to sit down and implement my solution in a day and it worked just fine - still does.

Something else that helped stimulate me was the website on Extreme Programming.

A lot of the approaches there really appeal to me. Particularly I like the ideas they have that could be generally expressed as "design by coding" and are mentioned I think by Stroustrup in the intro to More C++ Gems as "expressing designs in the code".

That is, rather than doing a bunch of up-front modeling using diagrams like OMT or UML or what have you, you just write code - but you are designing in the code, so they emphasize in extreme programming that you constantly rewrite the code as designs gel.

One thing that saddnes me though is that Extreme Programming also suggests programming in pairs. This is something I used to do with Dave Johnson when we were at Working Software together. We'd help each other through hard spots and just rap about politics and stuff and go have coffee or a beer and get a lot of work done.

Now I live at the End of the Internet and I'm working for myself as a one-man consultant shop. It has its advantages (I can work at home and set my own hours) but one big disadvantage is that I work very much alone and there's no one around to bounce ideas off of.

I have other programmer friends and I do call them up but they all have their own gigs - it's not the same.

On another important note, several people both here, privately via email and in the newsgroups raised the possibility of this being clinical depression.

Well that is something I was well aware of and had been considering. Depression is something I have been dealing with all my life, as you will see in another slashdot article I posted:

Manic Depressive Geeks

I didn't used to be (woefully so) but now I'm very introspective about my mental and emotional state. I have to be. I didn't used to be but now I just won't tolerate the depths of misery that I just thought were part of the normal human condition.

But I don't think that what was happening to me was the sort of depression that I usually consider. There are "endogenous" and "reactive" depressions. Endogenous depression just happens to you and is usually caused by chemical imbalances in the brain (shortages of serotonin or norepinephrine) and is what's usually experienced with Manic Depression, while reactive depression is (naturally) a reaction to external events, like a personal tragedy.

Life has been really hectic for me for a long time, with the turbulence of my consulting business, falling in love with a woman from another country, planning a wedding, moving to Canada, and just trying to keep it all together. Maybe if all that hadn't been going on, I wouldn't have gotten stuck. But basically, I just got stuck.

Robert Pirsig talks about stuckness and ways to overcome it extensively in Zen and the Art of Motorcycle Maintenance, which I recommend highly (and probably ought to reread). And I really was suffering the kind of stuckness he described, the stuckness that occurs when you just want to get your bike fixed and you break the head off a crucial screw...

(Robert Pirsig went nuts while a grad student in philosophy at the University of Chicago. He had shock treatment back when it wasn't very carefully administered and lost nearly all his memories. The book is about his motorcycle trip across to some of the places he used to live to visit old friends he hardly remembered, along with an amazingly enlightening discussion of what he'd been so obsessed about that it drove him crazy - what is Quality?)

Someone mentioned meditation in the discussion. I had found reading about Zen and doing meditation on my own was of profound help in overcoming my mental illness back in the really dark days. But as things got better and my career got in shape and I stopped seeking so much and concentrated on learning to program and making a place in the world for myself I drifted away from that, something that I think is really wrong.

During my time off my then-fiance lent me her copy of Chogram Trungpa's The Path is the Goal, A basic handbook of buddhist meditation. It is published by Shambhala Publications

I'm afraid I read a little bit of it then when my time off came to an end I set it aside and started thinking again.

One of the little traps our mind has for us is thinking. I like to think, and I'm particularly well-developed at it. But my wife tell me that we are not our thoughts, and actually our thoughts can lead us astray. And when I was getting so stuck on my programming problem I was thinking really hard and trying to solve my problem by thinking harder.

One thing you do in meditation is to stop thinking. Hardened programmers might find that a frightening concept. And you can't really try to stop thinking - you just sit, and look, but not too hard, and experience

You cannot experience your world as it really is and be thinking.

One thing that Pirsig discusses in his book is how to bring the wisdom attained at the rarified mountain peaks of meditation down to practical value in everyday experience. He uses fixing a motorcycle as an illustrative example but when I read the book I found that I was able to program better because I could "become one with the machine".

My wife doesn't really believe this is possible but I think it is, that one can meditate while carrying out an intellectual activity like computer programming. That's something that I seem to have lost long ago, that I had years ago when I was not nearly so knowledgeable but I did have the ability to really lose myself in the machine all day long without distraction - and without getting tired or worn out.

Don't forget:

Tilting at Windmills for a Better Tomorrow

Just like it's impossible to completely reverse engineer .DOC, it's going to be impossible to clone winDOS. Certain 'features' of winDOS are just NoGo code that solified into the morass. Unlike Linux, which can be POSIX-compliant and therefore has a particular behavior goal, winDOS is just whatever MS says it is.

For a more open freeforall on the web, try playing around with a wiki:

This idea has been implemented for awhile in a more elegant fashion via WikiWikiWebs. To see how they work, check out The Portland Pattern Repository

To set up one yourself, I recommend checking out phpwiki.

Remember the days when you would go to a web page and every sentence had at least one link? Even corporate sites weren't shy about doing off-site linking.

Of course the web was atrocious, but if you found a dumb page (take my old one for example) there was always something linked to that WAS moderately interesting.

Wiki pages are awfully remniscient of the "old web". (Of course that one is centered around eXtreme Programming and kinda boring, IMO, but it's the principle!)

Oh well. The corpratization of the web has brought lots of cool things, too; they're just harder to find now.

You can try Swiki (here) for a collaborative Web server. It is very very easy to use and it is free!! You can find implementations in Perl, Smalltalk and Java.
It is used in the portland pattern repository too. You can write web pages, without knowing a lot of html, do search on the archive and so on...
Enjoy!!

These are low-end systems, but they are in fairly wide use.

A related subject is collaborative annotation. this paper has a good review of tools, and CritLink is interesting.

I really want to work on this as part of an Open Source developer groupware app I'm working on, but the tuit supply is remarkably scarce at the moment...

- Barrie

I remember watching a number programs displaying the date 29 FEB 1990 to me a decade ago. That wasn't a leap year. Fortunately for the vendor, who responded quite quickly, the dates were stored internally in Julian format and converted for display, so no data was corrupted. The bug was introduced during some maintenance on some old software. I suspect that they were among the first to start Y2K fixes.

This particular problem arose from the fact that far few programmers completely understand the leap year rules, and the code that does the calculations is rarely touched, usually for some reason not directly related to leap year calculations, such as Y2K remediation. It is all wound up in the reasons why software maintenance gets expensive in nearly every case. The specs were either never written down to the level of individual functions, or they are out-of-date. Comments are incomplete or misleading. There's no automated regression tests to give assurance that nothing has been broken.

Why should we care about this? This particular instance was probably due either to Y2K work or a latent bug from some programmer who over-applied the century portion of the leap year rules. Once it gets fixed, this code won't need to be touched for ages. First of all, Y2K was just a single instance of a justification for going through bodies of code making huge numbers of small changes. Porting is another one. And any programmer with a bit of experience can name at least one or two others.

Earlier, I provided a link to the description of the Extreme Programming practice of automated unit tests. Doing that might not have caught these bugs before they got loose. Testing generally only catches the bugs you know to look for, and the tests can be wrong too. But I'm lobbying here to try to overcome the natural resistance many programmers feel toward testing. I know I'd certainly rather be writing code. The reason I've started automating it is because I have no such aversion to building tools to take that dull task away from me. Larry Wall pointed out that laziness is a virtue for programmers. Use it.

I remember watching a number programs displaying the date 29 FEB 1990 to me a decade ago. That wasn't a leap year. Fortunately for the vendor, who responded quite quickly, the dates were stored internally in Julian format and converted for display, so no data was corrupted. The bug was introduced during some maintenance on some old software. I suspect that they were among the first to start Y2K fixes.

This particular problem arose from the fact that far few programmers completely understand the leap year rules, and the code that does the calculations is rarely touched, usually for some reason not directly related to leap year calculations, such as Y2K remediation. It is all wound up in the reasons why software maintenance gets expensive in nearly every case. The specs were either never written down to the level of individual functions, or they are out-of-date. Comments are incomplete or misleading. There's no automated regression tests to give assurance that nothing has been broken.

Why should we care about this? This particular instance was probably due either to Y2K work or a latent bug from some programmer who over-applied the century portion of the leap year rules. Once it gets fixed, this code won't need to be touched for ages. First of all, Y2K was just a single instance of a justification for going through bodies of code making huge numbers of small changes. Porting is another one. And any programmer with a bit of experience can name at least one or two others.

Earlier, I provided a link to the description of the Extreme Programming practice of automated unit tests. Doing that might not have caught these bugs before they got loose. Testing generally only catches the bugs you know to look for, and the tests can be wrong too. But I'm lobbying here to try to overcome the natural resistance many programmers feel toward testing. I know I'd certainly rather be writing code. The reason I've started automating it is because I have no such aversion to building tools to take that dull task away from me. Larry Wall pointed out that laziness is a virtue for programmers. Use it.

I remember watching a number programs displaying the date 29 FEB 1990 to me a decade ago. That wasn't a leap year. Fortunately for the vendor, who responded quite quickly, the dates were stored internally in Julian format and converted for display, so no data was corrupted. The bug was introduced during some maintenance on some old software. I suspect that they were among the first to start Y2K fixes.

This particular problem arose from the fact that far few programmers completely understand the leap year rules, and the code that does the calculations is rarely touched, usually for some reason not directly related to leap year calculations, such as Y2K remediation. It is all wound up in the reasons why software maintenance gets expensive in nearly every case. The specs were either never written down to the level of individual functions, or they are out-of-date. Comments are incomplete or misleading. There's no automated regression tests to give assurance that nothing has been broken.

Why should we care about this? This particular instance was probably due either to Y2K work or a latent bug from some programmer who over-applied the century portion of the leap year rules. Once it gets fixed, this code won't need to be touched for ages. First of all, Y2K was just a single instance of a justification for going through bodies of code making huge numbers of small changes. Porting is another one. And any programmer with a bit of experience can name at least one or two others.

Earlier, I provided a link to the description of the Extreme Programming practice of automated unit tests. Doing that might not have caught these bugs before they got loose. Testing generally only catches the bugs you know to look for, and the tests can be wrong too. But I'm lobbying here to try to overcome the natural resistance many programmers feel toward testing. I know I'd certainly rather be writing code. The reason I've started automating it is because I have no such aversion to building tools to take that dull task away from me. Larry Wall pointed out that laziness is a virtue for programmers. Use it.

Sounds like a great way to write non-maintainable code to me. I think I'll pass on this one.

Ever heard of RefactorMercilessly and DoTheSimplestThi ngThatCouldPossiblyWork ? These two together should lead to maintainable code, because XP states that anything that isn't written well should be improved on immediately and the unit testing ensures that the changes are correct. This methodology is probably best suited for development of smallish apps in dynamic languages like Lisp and Smalltalk, where the cost of change is small. Interesting, but not as extreme as the name leads you to believe.

Personally I like the ideas. For some reason big processes like the RUP seem to get in the way of concentrating on the task. Something small, elegant and adaptive probably works better, IMO. At least for small groups of specialists (like games development, etc.). I wonder if there's any methodologist working on processes for Open Source development over the net ? IMO there's a serious need for research in this area...

Sounds like a great way to write non-maintainable code to me. I think I'll pass on this one.

Ever heard of RefactorMercilessly and DoTheSimplestThi ngThatCouldPossiblyWork ? These two together should lead to maintainable code, because XP states that anything that isn't written well should be improved on immediately and the unit testing ensures that the changes are correct. This methodology is probably best suited for development of smallish apps in dynamic languages like Lisp and Smalltalk, where the cost of change is small. Interesting, but not as extreme as the name leads you to believe.

Personally I like the ideas. For some reason big processes like the RUP seem to get in the way of concentrating on the task. Something small, elegant and adaptive probably works better, IMO. At least for small groups of specialists (like games development, etc.). I wonder if there's any methodologist working on processes for Open Source development over the net ? IMO there's a serious need for research in this area...

XP is nothing but engineering. Highly disciplined engineering, SEI CMM Level 5 Engineering. It's repeatable, it records, it measures, it optimizes, it plans software development in exquisite detail. XP is a painstaking and rigorous process that is simultaneously paper-light and stress-free. Anyone who disagrees with these statements simply doesn't understand XP. Plainly most of the correspondents here simply don't understand XP.

Beck's work fundamentally advances the state of the art in Software Engineering, and his book is at least as important as Design Patterns. Where Beck has failed is in anticipating the outrage of all you shmoes. Beck's book is obviously failing in communicating the idea that XP is *NOT* Cowboy Coding. If you think it is, get the book, read the book, understand the book. And then you'll probably want to try it. And then you'll understand, but that'll be too late to quench the flames.

Still, isn't this a risky way to evaluate the XP approach? Well, look at it this way: over half of the world's software projects fail outright. So far there are no known XP projects that have failed. None. So what have you got to lose? Besides, the whole thing is vastly more fun than you've ever had programming in teams. Quit yer yammering and give it a chance.

And if you're too cheap or lazy to buy the book, most of the material there is also out on the wiki-web. Most of the XP boffins hang out on wiki - go raise hell with them there and you'll find that all the questions here have been answered in detail.

XP is not programming without engineering. XP is engineering without therbligs.

For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use.

Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language.

For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use.

Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language.

For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use.

Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language.

For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use.

Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language.

What if you told the customer that this little change would take X time/cost to implement, while this new feature woult take Y, and let him choose which is worthwhile and which should be done first?

Funny, that's what the XP people call the Planning Game...

I ran into XP via Cunningham & Cunningham, Inc.'s ExtremeProgrammingRoadmap. I had a lot of the same thoughts that many here have posted, with tons of reasons why it couldn't possibly work. I decided to use some of the XP methodology for some tutorials and samples I needed. I will never look at programming the same again. If you have some extra time I would suggest buying the book, opening your mind, and doing some extreme programming. It has changed my life, it might change yours.

The way would not exist if not for the laughter.

I ran into XP via Cunningham & Cunningham, Inc.'s ExtremeProgrammingRoadmap. I had a lot of the same thoughts that many here have posted, with tons of reasons why it couldn't possibly work. I decided to use some of the XP methodology for some tutorials and samples I needed. I will never look at programming the same again. If you have some extra time I would suggest buying the book, opening your mind, and doing some extreme programming. It has changed my life, it might change yours.

The way would not exist if not for the laughter.

Another site is ExtremeProgrammingRoadmap. This is a "WikiWikiWeb" site, where every page can be edited by anybody, and new pages and links spring into existance automagically just by RunningCapitalizedWordsTogether. This site also covers pattern languages, java idioms, and other semi-related topics...

For example, maintainability is maintained through several cooperating practices, the first being PairProgramming. Every line of code is written with two sets of eyes looking at it. There are reasons for this that I won't go into here, but you can find out about them at the URL I mention below. Next, there is the rule about OnceAndOnlyOnce. This says that code can only appear in one place in a system. If you have the urge to replicate some portion of the code, then you are obligated to refactor the system to provide for a single place for that code to live. This above all else serves to create an elegantly designed system. This leads to RefactorMercilessly, UnitTestsFirst, and a few other of the XP practices.

In the end, though, XP-produced systems tend to be exactly what the customer wants (PlanningGame), thoroughly debugged (UnitTestsFirst), and easily maintainable (OnceAndOnlyOnce et al.).

Check out the Extreme Programming Roadmap for a thorough discussion of the XP principles, and subscribe to Rational's Object Technology User's Group for a spirited discussion with many of XP's founders.

Wiki sites are really just editable web pages. Somebody starts a page on some topic and then others add to it. You can go in and change what you said a week ago or add something new.

They can be quite nice as the 'editing' feature allows authors to refine what they said eariler.

Facades As Distributed Components
Distributed Facade

My heuristic is that one should design CORBA interfaces thinking of them as network protocols, not as collections of objects in a program.

I honestly don't know what flaws you are refering to, unless you are one of them wussy VB programmers that regards real OO as a flaw because it's "too hard"

OO is harder than procedural, but it is also nearly useless in many domains. It is complicating software, languages, and training in exchange for minimal benefits. Perhaps in large RAM-centric scientific or modeling applications it shines, but I have found OO to add nothing but complexity, headaches, and mind-numbing buzzwords to regular business apps.

It seems like OO is all geared up to solve "problems" that are not really problems. For example, the apps I work on expand at least as much in the operational dimension as they do in the sub-type dimension. OO tends to assume the type-wise orientation is better than operational-wise orientation, which I find to be bogus. (Some OOers try to remedy this OO weakness by adding "pattern" classes. These are often nothing more than bulky, silly middlemen classes that add nothing useful to software except satisfaction for anal-retentive OOP class protection purists.)

Inheritance is another look-good-on-paper-just-like-socialism OO concept that makes bigger messes than it solves. The real world does not expand or change in a hierarchical fashion. Businesses love to recombine features into unpredictable new arrangements that do not follow any clean hierarchy. OO books like to use animal species and shapes for inheritance examples, because most business examples would prove too inter-relational in growth and change patterns.

Finally, there is not one shred of scientific evidence outside of pro-OO organizations that proves that OO is superior for most applications. Even the hyper-promoted reuse of OO is being withdrawn as a benefit. Any remaining benefits are vaguely stated in a Zen-like tone or are perhaps personal preferences. (Software engineering is about modeling developers' minds and habits more than about modeling the real world, which OO does not do well either. Thus, OO may simply be a subjective personal preference.)

Much of the criticism that OO fans toss at procedural concepts are based on a bad specific language (like C), or a bad procedural experience that they were too uninformed about to solve. For example, I sometimes bump into OOers who claim that procedural/relational programming cannot factor as well as OOP. However, with a few language constructs included, it can indeed factor as well as OO. (My results are often ugly from a type-safety standpoint, but they factor.)

However, that amount of abstraction is often not a goal of most programming projects anyhow. It is widely accepted that building generic routines takes roughly 3 times longer than building per-application routines. Very few business will budget for this.

Part of the reason is that they know a new language or paradigm fad will pop up and eat away at their source base within a few years. I can't wait for this day. OO has been mucking up software and progress with useless mind-candy and abstraction toys for too long. It is time to leave the dOOrk ages behind.

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?

Given that it would have been possible for both teams to work with whatever units they wanted, as long as they'd agreed on a conversion function between them, it's obviously not the fault of the measurement system.

This was a human error, a tiny glitch in the communications between two programming teams. This happens all the time in software and the only scalable solution is proper testing.

I don't think NASA tested this part of their software.

The physics of modelling a satellite going into orbit aren't that difficult, so why not build a test harness which could simulate all the inputs the satellite would receive (inertial guidance etc), and could take the output from the guidance system (start firing this thruster now, stop firing now)

Since you're in a simulation and the "player" (satellite navigation system) is a computer you can ramp up the rate at which the clock ticks. In this way NASA could have tested that the Mars Climate Orbiter navigation system worked. The level of certainty would be based on how good the model was.

How do you build a good model? Testing of course. E.g. start small, check that when the nav system says fire this thruster, check the engine management subsystem throws the switch, check you can model the body in freespace firing it's thrusters and ending up where it should. Slowly add in more complexity (but keep running all the simple tests too) e.g. gravity, change in rotational inertia as fuel is consumed. Test it can hold an orbit round a model planet, check it can change orbits etc.

Testing this kind of thing would be challenging and fun, there would be parts you'd think were not testable. But if the solution is not testable by a computer how can you hope to solve the problem with a computer.

This has been cross posted Here and Extreme Programming Discussions

What do people think would be hard to test about putting a satellite in orbit around another planet?