Critical Thinking

Well - those five kids will learn a great deal, be directed by others
who know more and develop and application that can be adapted by anyone
who sees fit to do anything they so wish. The crust old timers will pat
themselves on the back and wonder off down the happy road of oblivion
whilst the users suffer another BSOD and more work lost.

"IIS is a significantly more ambitious piece of software than
Apache" - you mean its got more bugs in right? Has the idea of software
modularity died or someting? Do something really well. Don't do
everyhing badly.

The whole point of Open Source means that when something goes wrong it
can be fixed quicker by more brains.  It means companies can't
hold others to ransom - nor jepordise other businesses by their
inaction.

It's about an ethos of getting everyone pitching and sharing the load
and the glory.  The cult of self worship that closed source coders
get into is really sad.  Genius is one idea - it means standing on
the shoulders of giants. Giants who give you a leg up.
 

This is the second of a three part series regarding how to think like a programmer.

In my last blog (How to Think Like a Programmer: Part 1), I discussed how education, particularly a strong background in mathematics, is crucial to being a great progrommer. In this post, I will go over some of the things that I have found extremely helpful in my personal development.

The number one most useful experience in my learning process was EdScheme. Never heard of it? Sounds vaguely familiar? Well, it might sound familiar because of the word "Scheme," a language in the Lisp family. You probably have never heard of it because it is pretty much useless. That is the point of EdScheme. The EdScheme language has only a few built-in functions (less than twenty, if memory serves), and no libraries that I am aware of. Working with the EdScheme books, you slowly build a much more full featured language out of the meager tools you are given. In the process, you are taught a lot about things like recursion, efficiency, and the idea that there is usually more than one way to skin a cat. One example that still sticks out in my mind was building a simple string reversal function. My memory of this is all very hazy, but I seem to remember that we did not even have strings at first; just arrays, chars, integers, and a floating point type. As we progressed through the course, we kept building on our previous projects. Problems and inefficiencies which were not found in the early work were soon uncovered as we progressed through the course.

What this experience taught me was how to break a problem down to its most simple form, an Occam's razor of programmatic thought. Ever since then, I have been much better at looking at a problem and ask myself, "what is the simplest way of making this work?" All too often, programmers find solutions that are incredibly inelegant, simply because it uses methods and tools that they are already familiar with. Programmers should not code for the sake of writing many lines of code, they do not get paid by the subroutine ala Charles Dickens. They get paid to create solutions that meet the why of the users. Anything more than that is simply hubris. Developers are not their own customers. The EdScheme experience showed me that achieving workable, maintainable, and excellent solutions was paramount; the pride of kludging impossible solutions out of inadequate parts never enters the equation.

Another experience which has helped me expand my awareness of good programming is the Perl language. Perl is the most elegant language I have ever used. There is something very satisfying about writing one line of code that does what another language might take five, or ten lines to accomplish. Some time ago, I re-wrote the Perl SoundEx CPAN module as a VB.Net class. The differences in how the code was written were astounding. I was not just that Perl has regex's built in as a string operator and VB.Net requires a regex object. It was the entire attitude of the two languages. Writing in VB.Net is like talking to a four year old; programming in Perl is like talking to an adult. Yes, Perl code can quickly devolve into an unreadable mess, especially by overuse of the implicit operators. And yes, Perl has quite a number of contradictions and inconsistencies. But the Perl language is so incredibly instructive and powerful. In 2000 or so, I wrote a piece of shopping cart software. In 1,609 lines of code (including whitespace, comments, etc.) I was able to pack in a flat file database system (this was before every web host came with MySQL), a full templating system that I consider to be better and more powerful than PHP's (this was before every web host came with PHP), the actual shopping cart system, session handlers (you could not count on the CGI module being installed), error logging, the whole nine yards. It even had a module system for rapidly constructing plugins. Admittedly, it lacked an online administration system; I also believe that it was simply enough to use to not need one. Like EdScheme, I found myself writing my own, custom tailored versions of code in order to handle things which most programmers take for granted, because one design specification was that the only requirements were FTP access and Perl 5.

To get a deeper appreciation for well written code, I highly suggest that you find an open source project that is not a "big player" and try modifying it and customizing it for your own use. Recently, I was working with ZenCart. Out of the box, the software itself is fine. But my customer had extremely demanding needs, and "out of the box" was not nearly enough. I had to go extensively into the code, to the point of modifying its base functionality. I was horrified. The code looked like the worst examples from Computer Science 101. There were nested loops with iterations like "m," "n," and "o." There was little consistency in variable naming. And so on and so on. The code itself was fine on a functional level. But it was so unreadable that sometimes even minor changes would take hours just to find the right place to make the code change. That reinforced in my mind the need to develop a programming style and stick to it. I have a different style for every language I use. But I stay consistent within a language, to the point where I can copy and paste code from one project to another with little (usually no) modification needed. Small things, like always naming my iterators the same thing make a world of difference; someone who sees what a particular variable does in one function immediately knows what it will be doing in a completely separate function in another part of the code, even another program that I wrote. It is especially important for teams of programmers to develop a common style and stick to it.

Finally, I recommend that you get your hands on a variety of different languages, and try writing the same small project in each one. You will quickly learn what works and what does not, for each language. Most programs, at the end of the day, are essentially CRUD mechanisms; get data from somewhere, present it somewhere, allow some changes to be made, and put the changes back into the data source. Some languages are better at this that others. The .Net languages, for example, are outstandingly pleasant to use for straight database-to-screen-and-back functionality. But try to do anything with that data programmatically, and the serious shortcomings of Visual Basic and C# become quite clear. They are weak languages, incapable of doing too much without the giant .Net Framework behind them. Java is about the same. Perl is an incredibly strong language for performing processing, particularly of text, but its systems for getting data to and from the user leaves much to be desired. Its roots as a procedural language make it less than fun to develop user interfaces with it on the backend. And so on. As you learn more languages, you also have the opportunity to see how things can be done. The more tools in your toolbox, the more likely you will be to use the right one for the task.

I know that there is a lot more to be added to this list. Really what I want to make clear is this: always expand your borders, never cease learning, and do not get too attached to any one language or methodology. Learn what works in what situations, and you will be able to meet any challenge.

J.Ja

This is the second of a three part series regarding how to think like a programmer. Part one discussed the reason why mathematics skills are important to the code writing process. In the third part, I will cover the difference between shot term expediency and long term solutions.

Insert comment text here

I suspect that Justin is referring to code generated by the UI designers of each of the IDEs. If you use the NetBeans UI designer to develop a Swing-based UI, you cannot then switch to Eclipse and use its UI designer on the same code. This often causes Java developers to shy away from using the IDE's UI designer tools at all.

I haven't used it, but I see that there is a NetBeans Eclipse Project Importer now included in NetBeans.  You are also supposed to be able to create a .war file in NetBeans and then use the 

"File > Import > WAR File" menu/wizard in
Eclipse WTP" to import a NetBeans web project.  I haven't used any of this stuff, nor am I a java developer.  I've used eclipse in the past for learning purposes and found it a bit confusing.  A quick look at NetBeans gave me the impression that it was better organized and more inutitive but that's a very hasty judgement.  And yes, applications written in java seem to be extremely slow if StarOffice/OpenOffice is representative.  Compared to pascal and C, languages that I've used in the past, I've found it pretty tough to get off the ground with java!

Kor

Although some will debate the validity of the criticism this author
makes, i applaud him for making these points nonetheless. The
developers who are doing the engineering to create the .Net and Java
platforms/frameworks need to have their collective "noses held to the
grindstone". And that goes for IDE developers, too. ALL developers need
to be held accountable and pressured by the market to make their
respective platforms/frameworks/tools as simplistic-to-use, yet
powerful, and consistently open and portable as possible. (Fortunately,
in the case of eclipse, if there's something an end-user programmer
doesn't like about it, he or she is allowed to change it, due to the
freedom its license provides. Given this fact, if eclipse provides a
superior way of doing things, and netbeans refuses to change, then it
is up to netbeans to "evolve or die".)

End-users and programmers have every right to demand that all their
tools and target platforms play well together. It's constructive
criticism like this that keeps developers on the right track. Not only
do the end users benefit, but i think that ultimately it makes
everyone's lives better when all these needs mentioned above are met.

Incidentally 1) i was also thrown for a small loop by the large and
slightly unclear selection of packages the first time i went to
download the windows version of eclipse (Fedora, for one, at least
whittles it down to a few core packages and eliminates some of the
confusion). 2) i also find the .Net framework and toolset slightly less
overwhelming and confusing than what exists in the java world.

People have been predicting the imminent demise of Java for at least 10 years. It's still here. It probably will be here in 10 more years. It is better than it was 10 years ago and will most likely be better in 10 years than it is now.

Yes, certain classes and methods are deprecated from version to version but you generally get a warning message when you try to use one in a new project rather than an error for several point releases before the thngs are actually dropped. An exception was the change in the event model and the resulting change in event handlers when Java went from version 1.0.x to 1.1.x many years ago. The ability to compile a new program in compliance with an old JRE
spec and the ability to install several different JRE versions on the
same box at the same time pretty much make this argument a non-starter, anyway.

The "there must be ONE IDE or people will be confused and go back to VB" argument is a variation on the similar argument reagrding how the KDE/Gnome UI "confusion" is keeping users on Windows. Maybe, but so what? The same applies here. Most of the people professing confusion about NetBeans vs Eclipse sound like VB programmers, anyway. OK; use the tool that can do the job and that fits your hand. If your choice is different than mine that's OK; use .NET if you want, I'll use Java. Use NetBeans if you like; I can still choose Eclipse. Not a problem.

I also get a kick out of the argument that basically says that if the alternative to the MS product in any category is not *absolutely* perfect for *everyone* than it's *useless* for *anybody*. Funny, nobody even tries to make the same argument against using MS products. I guess they *are* perfect for everyone... Right?

I see some commenters are confusing the issue. The point that J. James is making is that it's the people that make a difference on a project, NOT the process by which the software is made. For several years I've heard claims made both online and offline that OSS is inherently more stable and secure, because of the open source process of making software: the "many eyes" theory. There is some truth to this notion, but it is not universal. From what I've read from a few sources, developers who work on open source projects tend to focus on what's exciting about it. There are aspects of projects that are boring, whether it be auditing the code, or focusing on a feature of some piece of software that is necessary for its functioning, but just doesn't scratch that itch that programmers have. These areas can tend to get neglected. In other words, there are "many eyes" on some aspects of the project, but very few on others. This equation can change if the primary people working on the project are paid developers, even if the project is open source. Paid developers have more incentive to listen to direction from a competent product manager, who will insist that the boring aspects of their projects get their attention.

"Many Eyes" Is Not Better

Though this is really a side bar to the major thought in the blog item, I would like to point out that multiple reviewers is actually a detriment to quality.  

It was pointed out by Dr. W. E. Deming, among others, that multiple reviewers leads to a decrease of attentiveness by individual reviewers plus a "group think" issue, where individuals become hesitant to point out issues that no one else has raised.  Having a thousand reviewers becomes no more effective than zero reviewers.

This is by no means intended to be a swipe at open source, merely a recognition that any development approach requires an explicit mechanism to identify short-comings.  Relying on lots of reviewers simply will not get the job done.

Most posts here couldn't be more wrong. I don't know why this
myth keeps hanging around. Look at the security and tight code of
Apache. Look at some of the FLOSS projects that, out of the box,
are more efficient, secure, and effective than their counterparts.

I suggest everyone take a read of:
The Cathedral and the Bazaar
Nip Nikolai Bezroukov's card in the bud
Open Minds, Open Source
The Magic Cauldron

Better Quality Control
No more Secrets
A good paper on the benefits and drawbacks

Unfortunately opensource today is just MS windows vs Linux and MS office vs Openoffice and MS IE vs Firefox. They just dont think beyond that (the open source guys). Even if they do want to opensource everything who is going to fund them :)) TO all OS guys, how about cloning websphere, rational rose, java etc ?? 

Who's going to fund FLOSS?  The consumers.  Those who buy the products.

Just because it is free doesn't mean it is free beer...

I'll respond to points in an order opposite that in which they've occurred.

1. Funding: Funding buys manpower in software design. Since open source software provides free manpower, funding isn't really necessary. On the other hand, jmgarvin is right ? it's entirely possible to sell open source software (and support and so on), and you can then use some of that funding to pay programmers who will improve the software.

2. Cloning Software: There are open source "clones" of the Sun JVM. I don't know much about Rational Rose, so I'm afraid I wouldn't know whether there's a "clone" of that, but I do know that it runs on Eclipse ? which is open source. There are open source systems that provide functionality equivalent to WebSphere's, though there are significant differences (since they're competing technologies and not merely an attempt to copy it feature-for-feature).

3. jmgarvin's List of Links: You forgot one. Have a look at Security through visibility: The secrets of open source security. What's that? Why, yes, I am sort of an attention whore at times.

4. Supposed Refutations of the "Many Eyes" Principle: You're assuming "many eyes" in an open source development methodology are subject to the same limiting circumstances as "many eyes" in a closed source development methodology. The truth of the matter is that in a popular open source project, there are typically at least dozens of people who regularly skim bug reports and fix a bug now and then ? and those bug reports are generated when someone has trouble using the software for some reason. As a result, flaws and vulnerabilities in software get fixed without having to institute a formal review process as you would with closed source software. There's no "groupthink" issue, no "unglamorous work" issue, and so on. When someone defines a bug for you, it's generally pretty easy to fix it. In addition to this, people can fix their own bugs, so when a bug is noticed by someone who not only uses the software but also knows enough to be able to fix it, that person can submit a patch so that later updates to the software will include the bugfix. This adds the programmers in the software's userbase to that "many eyes", without suffering any of the problems that many paid eyes would create in a closed source project.

I see nothing in particular with which to take exception in your post, J.Ja. In particular, though, I'll comment on the calculus issue:

Calculus itself doesn't really teach any skills that are needed. In fact, higher algebraic maths would be even more helpful than calculus. What's helpful about learning calculus is the mathematical logic it teaches, and what's helpful about the mathematical logic is the fact that it's logic. As such, something like Linear Algebra would be more helpful than Calculus II. On the other hand, a course in Symbolic Logic would be about as useful as an equivalent-level algebra course -- beyond basic algebra and logic, mathematics is not very useful to programming skill at all.

Calculus ensures a fairly solid grasp of logic and algebra, which is a good thing for programming, to be sure. There are other ways to get the same skills, though, without having to estimate the volume of an irregularly shaped container.

Point One:
The issue is fewer bugs.
Point Two:
Then when there are bugs shortest fix time.
Point Three:
Not repeted bugs.

Now! which fits    Open / Closed
In my house hold, My wife is a great person, but getting yahoo! web
page to look as her way it should under winders 98, 98se, ME, Xp Home,
Xp Pro, just did not work.
But A load of Red Hat Fedora Core 2 and then Three / 60th of an hour. It was done,
Get-hur-Done Once is best, don't you think ?  She is sold on
"OPEN" and she lives with no ".pps, .wmv," and some ecards that done
work under Mozilla.    That is fact!
And fact is all that is real...  ..........ed   
All other things said, that is what we paid, real working  OS, not
junk out of Wash~ Stat. whom will charge you $495.00 to strip you
software form you machine that you wrote / and reconstructed from poof
up disk that 95 did to it. All the while charging to help you ~~~
not.  Then later seeing some code in WindersAPI  for three
button mouse that didnot even change the incorrect spellings of each
button statements of that code  ie:
leftwinmousebuttun, middlewinmousebuttun, rightwinmousebuttun, and some
more incorects this a type "O" but work in the source code any
way.   who neads to fit miss spellings when you just trying
to get that really nice track ball working again in your own
machine.  mnow I donot spell well at all mnumonic did not
either.   I didnot write all the code I just fix what wash
out stat did to it while i had exames to get to or studies for.  I
know bad grammer is here also.  Bbut!  Time was short. and
those classes just keeped coming around.    So they did
not even correct the grammer either in the remarks
statements.    Now that is "Close" statements uses of
code after complied and leaving the symbolic parts in the C:\mouse\*.*
directory.     Some coded because it is not cheep
to open them as proof.   That is why wash~stat can't open
source anything, because very little is without problems at
wash~~stat.  
I've used many different OSes: everyone of MS; PCDOS; OS/2; Portals;
and
UNIX also Linuxes.   I loved OS/2 warp {3.0}{4.0} witch
started out as joint project {MS / IBM} but was later only IBM while
still giving MS copyright markings to programs.  
the OPEN sources do have few weak spots in all POSITCs is most compactable.
Compatable is what sold MS - OSes, but saywhat about office97 does not
work with office95 or office98 and under XpHome write's ".rtf " don't
with the other Xp Pro write ".rtf " either. So that parent brings home
an HP w/windows XpHome for kids to do home work, on. The kids then uses
the write program for that home work and takes to school, where 
that school uses Xp Pro and wordpad  {write by another name}
just  will not show that kids work to the teacher.   And
to top it off  that  Xp Pro does not reconize  the
floppy  which was formated  by the kids  XpHome
computer.    And MS has still to answere that one
yet.   That is not bugs those are software that will not be
compatable by choice of MS design. I did the test ing my self with
other OEM loaded machines, yes they don't read each other floppies.
and write does not read write outs even when sent by email to the other machine.
My test was done useing "AOL cisnet Xphome edition" to egghead Xp Pro".
The Kid's  was HP XpHome to Compaq Xp Pro.   the problem
is that if the person formats the floppy before use then the none
reconization is triped on. The floppy drv
technics & panosonis under other OS no such differences showed up
same machines were used and no hardware changed.   Why should
we deffend this kind of programming?   P.S. all spellings
& grammers or no perposses. The Trade Marks are of the respectfull
owners.   And all test are not concluesive.  But there
reason to be  of  aware....  Teachers  are not
computer testers, why should they be.    P.S.S. 
Please strip and edit for safer uses.

Open source, in and of itself does not produce
better code. Better coders and better testing produce better code. It
is that simple. When a closed source shop has the better coders and
better testing, they write the better software. When an open source
project has better coders and better testing, they write better
software. To think that just because a piece of code can be modified or
inspected by anyone and everyone means that the best coders and testers
will be modifying and testing that code is just not correct.

The reason that Open Source has attracted the better coders is simple, the pool is every coder in the world that they draw from. The proprietary software houses have only the pool they hire, and the best coders are not all working for the same employer.

Yet all the best coders in the world can contribute to any open source project they want to.

Why is most popular open source software so blessed with good coders? Because they choose to contribute to a piece of software they they see is usefull. All open source software is rated on that one point, if it's usefull, it will be used and draw a community of people to support it. If the original creator of it dies, the software can continue to be improved. If  no-one finds the software usefull, it will die off a quick and painless death. Proprietary software is rated by how much money the company makes off it. If they don't make enough, it doesn't matter how usefull, or what quality it is, it's gone.

This is the third of a three part series regarding how to think like a programmer.

One of the biggest mistakes that I continually see in the world of technology is the problem of short term expediency versus long term solutions. All too often, a programmer takes shortcuts based on what is easiest, what tools are in his toolbox, or what technologies are currently popular. These kinds of compromises lead to systems that are kludged together becoming legacy code that is nearly impossible to maintain, inefficient, and slow.

Recently on TechRepublic, there was a great discussion on whether or not a developer should try to anticipate their users' needs. Part of that discussion came around to the idea of just how generic the code should be, which really balances the trade off between initial development time and long term flexibility. For example, in an OOP language, the programmer can implement every piece of code as a class, ignoring the chance that in the future their might be a need for that class to have been an interface. On the other hand, to write everything as an interface and only have one class implement it adds and extraordinary amount of time to the development process. It is indeed a fine line.

One example of where this tradeoff never should be made is in the readability of the code. I do not care what kind of deadline you are under, there is simply no excuse for naming variables "a," "b," and "c," the extra bytes will not break your budget. In fact, for every half second saved with writing the code, you are probably adding three minutes to the debugging time.

Another shortcut that causes big problems down the road is the inefficient usage of libraries. It is all too tempting to load up a million libraries for just one, easily replicated function. The end result is an application that does not scale well. Take that little Web application you wrote, the one with a million dependencies, and look at its memory usage. "But it is only using a few hundred kilobytes!" you say. Multiply that by what happens if your application suddenly gets very popular, or used in a large corporate environment. Multiply "only using a few hundred kilobytes" by 70,000 simultaneous users, and all of a sudden your systems administrator is banging on your door and using words like "refactor the code." If you are loading a whole library for just one small call or two, ask yourself if that is something you really need, or could possibly re-write within your existing code. That is one nice thing about open source, you can take what you need and leave the rest behind.

XML (and similar technologies) are another pitfall. I know that I keep harping and nagging about XML, but it bear repeating since it seems like everyone likes it so much. XML is easy to use, there are plenty of libraries and built in functions in most major languages now to handle it. But it is ridiculously inefficient, both as a transport mechanism, and in terms of systems resource usage. XML manages to get the worst of all worlds; it involves a zillion more bytes worth of delimiters than a standard flat file, and uses a tree structure that is CPU intensive (to say the least!) to parse. If you find yourself reaching for the XML scheme for tabular data, think again. Take the twenty minutes to write and test a CSV creator on the data end and a CSV parser on the client end. Not only will you save yourself the overhead of those XML functions, but the size of the data will be significantly smaller, and the parsing will be faster by an exponential amount. Even better yet, if you have the same language on each end, serialize your data structures and pass them around. It may be bigger than a flat file, but it will be even lighter on the CPU. Microsoft learned this lesson in the Live applications; they switched from XML to JSON and the speed went up dramatically.

It has been my experience that debugging and testing often take up at least 25% of the programming process, and frequently extend to 50%. Code is relatively trivial to write if you start with a solid knowledge of the language, the business goals, and some quality pseudo code (which you should be writing anyways to verify that the program meets the customers' needs). Spending a few extra moments to reduce unnecessary lines of code, ensuring consistent variable naming, giving variables proper names, skipping implicit operators unless they are obviously being used, and so on goes a very long way towards making the debugging and code review process go as smoothly as possible. What is the use of saving twenty minutes coding if you increase your debugging and maintenance by 10%?

Also learn about how your interpreter or compiler handles conditional statements and loops. It is all too easy to write one of these statements in a way that causes your application to run much slower than needed out of laziness or ignorance. For example, if the language you are using evaluates conditionals from right to left, put the conditions that are most likely to make or break the condition on the right. Why evaluate conditions that are not likely to make a difference? The same holds true for loops. Sure, it is easier to write something like: for (intRowCounter = 0; intRowCounter < tableDataSet.Rows.Count - 1; intRowCounter++) { but your users will be much, much happier if instead you assign tableDataSet.Rows.Count - 1 to a variable and check that variable. This eliminates the software from having to keep going down the object tree to find the count of the row object, and then subtracting from it. Little things like this add up very quickly, especially in a commonly run block of code.

Programming with this type of thinking requires a wholesale shift away from the short term, towards long term thinking. I have listed only a few tips here, but I think you get the idea. Ignoring the long term consequences of your coding for short term expediency is the path to buggy and slow code that you will regret ever having written, and your users will wish you never wrote it.

J.Ja

This is the third of a three part series regarding how to think like a programmer. Part one discussed the reason why mathematics skills are important to the code writing process. Part two discussed some techniques for expanding your thinking skills to be a better programmer.

It appears that you are trying to quantify what defines a good
programmer (How to "think" like a programmer is the same as how to "be" a good programmer, yes?). This is a hopeless activity - charming in a way, and
bemusing; it will fill many hours of time if you let it.

But it isn't truly productive in the long run, because programming itself remains undefined.

Programming remains undefined for good reason: It isn't a single
activity, it isn't a monolithic discipline. The characterization of a
good database programmer is wildly different from that of a good web
programmer or game programmer or widget programmer, or AI programmer,
and if you reduce your list of characteristics to what is common to all
sorts of programming you end up with a plain vanilla list of things
that are good in ANY discipline... "good programmers are...
CAREFUL...". Yeehah.

Programming is achieved with language; any language worth the name is
an open system, open systems cannot be meticulously defined, they can
only be mastered - ask Hilbert and Russell, who spent half their
professional lives trying to formalize mathematics before Godel upset
the applecart.

Scientific background is certainly helpful to a programmer; it is also
helpful to an accountant, and even to a priest, and probably to a broom
jockey too. Creativity is also helpful in navigating most disciplines,
but saying things like this isn't really saying anything useful.

I think you're pursuing an interesting line of thought, but I think you've
framed it too narrowly, creating a figure/ground confusion for yourself
- mistaking the dollar for what it buys. You correctly identify the
point of phase change, when a discipline shifts from
philosophy/folklore/religion to science - it's when quantification and
repeatability creeps in. But programming per se can never BE a science,
any more than English can be a science, or Urdu, or Tagalog. The STUDY
of English can be a science, and the STUDY of programming can be a
science, but a language itself, whether C++ or French, is not science.
There's a difference between biology (a science) and elephants (one of
the objects biologists study).

Certain efficiencies can be achieved by programmers if they acquire
analytical skills and problem solving skills, and these skills are also
common to many scientific disciplines, but they are not a priori
scientific methods, they can be applied to landscape painting or
cooking or burping babies too. I have frequently found myself using the
scientific method of theory/test/repeat while debugging, or when
building a special use compiler, but I also use it in analyzing the path I take from my front door to the train station. Programming is more like music
than anything else, I think - part math, part inspiration, part luck,
part muse.

The example you gave of reducing tabular XML data to string data and
parsing it so - this is not a balanced example. In a large organization
dependent on a phalanx of programmers doing things transparently, the
efficiencies of your one-off string parser are rapidly lost in the
welter of confusion that such cowboy antics can create in a big shop.

Big shoe
factories don't employ cobblers, no matter how artistic/elegant/efficient their work may
be. But certainly there is room in the world for custom shoes crafted
in unique ways, and there will always be a boutique market for custom
code of the sort you describe. XML is just a way to get data from point
A to Point B, better than some ways, worse than others, and most
importantly better sometimes and worse sometimes. And once again we run
into the impossibility of thoroughly quantifying the needs of "this
discipline we call code". Sometimes ya need one thing, sometimes
another.

Your contention that Skinner quantified Psychology is just wrong
- the bastard learned how to brainwash pigeons, for heaven's sake,
something every major religion achieves in its infancy, and a human
legacy thousands of years old. He sure used big words to describe it
though, didn't he? Much of his work has been discredited or
dramatically reduced in scope, along with many of his data collection
methods. Most importantly, he failed to account for feedback - the
effect an organism can have on itself. He refused to consider internal
stimuli at all.

He made one truly interesting discovery: His Paradoxical and
Ultra-Paradoxical Phases, when a stimulus would no longer be required
in order to evoke a conditioned response, or would evoke
counter-intuitive responses. Don't sound like science to me. I'm afraid
psychology (define "psychology") remains at best a mendicant's art, and
it's practitioners are mostly self-deluded charlatans and pill pushers.

I think you're several decades ahead of your time, J.Ja. - might be
better to define the field of endeavor - programming - before you start
in on the qualifications necessary for its practitioners.

This doesn't mean the discussion is useless - there are many
interesting things about mathematics and much has been achieved with
it, despite it being unquantifiable and inherently intractable when
subjected to analysis. Little arenas of clarity can be staked out in
the chaotic jungle or our discipline, and they should be. But don't
imagine that the rules that apply in one arena necessarily apply to the
clearing just down the road...

staticonthewire said:

The STUDY of English can be a science, and the STUDY of programming can be a science, but a language itself, whether C++ or French, is not science.

Maybe I misunderstand you, but C++ or any programming language is based on scientific and mathematical principles. In contrast French or any human language (perhaps with the exception of Esperanto) is not. Programming languages are based on a structure called a context-free grammar. French and other human languages have context grammars. It's been a while, so I don't remember exactly what "context-free" means when talking about programming languages, but I know it has to do with disambiguating the language so that a compiler or interpreter can parse the code and produce logically consistent results. This may be a bad analogy, but the one that came to mind is it gets rid of the "Who's on first" (referring to the Abbot and Costello routine) types of confusion. Programming languages have been fashioned in such a way that programs written in them always reduce down to a string of symbols (if the program conforms to the grammar correctly), which then may be translated to machine code, that can be executed in a logical fashion by a computer exactly as specified by the source language. So there is a science to creating programming languages.

How a programming language is used is not restricted to scientific methods, though they can be applied to it.

Two excellent points, Mark, but my interest (and my post) were based on
the second of your two points. It's true that all useful programming
languages are based on a defined context-free grammar, but this doesn't
mean that all productions of that grammar can be formalized
(which is your second point, and the one I emphasized in my post). I'm
not so interested in how a language is created - mathematics is also
based on a formal context free grammar, and while it's fun to play
around with Backus-Naur formats and come up with little languages of
all sorts, the real interest for me is in what a language can produce. As you point out, even formally defined linguistic systems have an infinite, open ended production list.

And that's why I was bemoaning J.Ja's campaign to quantify the characteristics/qualities of a good programmer.

The one thing all computer languages have in common - even the
"symbolic" languages and the cut-n-paste/drag-n-drop tools - is that
they are all languages. And languages, as we have both now
pointed out, are unconstrained production systems. This, it seems to
me, indicates that the skills a programmer of ANY language would need
would depend on what production subset they were specializing in. This
is what I meant when I said that different kinds of programming require
different skill sets.

This sort of defeats J.Ja's whole campaign, since, if a language is
capable of infinitely many productions, it follows that there are
infinitely many production subsets, thus, infinitely many skill-sets,
thus an enormous difficulty in defining a non-contextual and still
useful set of programmer skills or programmer qualifications.

J.Ja's overall goal (the formalization of characteristics for a good
programmer), like David Hilbert's and Bertie Russell's, seems
impossible to me. But as I also noted, things of value can still come
from the attempt.

Maybe I'm taking this 'way past the point J.Ja intended, but I don't
think so, because he specifically refers to the phase change between
scientific and non-scientific endeavors, and I assume he did that for a
reason - i.e., he wishes to place the defining (and eventually,
perhaps, things like hiring) of programmers on a scientific
footing. I was simply pointing out that this seems premature - perhaps
by decades... and in the long run, a bit Quixotic, yes? Since it really
boils down to an attempt to number an infinite system.

BUT - I applaude his industry, and suspect we will all learn once again what we already know - you cannot formalize a list of characteristics or skills that fully encompass what it means to be a top-flight programmer. Not in this day and age.

And you should thank your lucky stars that it is so...

I agree Justin is defining a "good programmer" too narrowly. He's thinking of programmers as those who work on OS kernels and compilers, or device drivers. Most programmers out there don't work on this sort of thing, and wouldn't get the opportunity if they tried (unless they wanted to write these things themselves or join the Linux kernel team or the team developing a programming language).

I take exception to the notion that physicists make great programmers. I worked with a programmer whose only degree was in Physics. He wrote code that worked, but it was difficult for anyone else to understand. The setting was a company that wrote custom business accounting solutions for a vertical market. He was notorious for writing the following in C (I put in comments to say something happens without actually doing it):

int Read(char *a, int b)
{
   int i = 0;
   int c = 5;
   for ( ; i < b + c; i++)
   { /* do something with a */ }
}

or,

He just used the while structure so he could use break statements to skip past the bottom of the loop structure once a step was taken.

Besides the function name, the rest of his code was cryptic. He never learned structured programming, and he got complaints about his one-letter variable names, which were only understandable to him. This made working as a team with him difficult. He was a nice guy, and easy to work with on a personal basis. But by our criteria he was not a great programmer.

Another programmer I heard about a long time ago, working at a small software manufacturer, was a genius. He could write working, highly functional programs in a matter of a few days that would've taken any of the rest of us a few weeks at least. I doubt it had to do with his programming technique, or that he was a faster typist than us. He just had the ability, IMO, to work the whole problem out in his head and then just "stream" the solution into working code. The problem was nobody else could read what he wrote. He programmed in C, but he would use labels and goto's to implement loops, when a for or while loop would've done the job just as well. It was as if he had learned how to program in either BASIC (old-style with line numbers) or assembly language, and just applied the techniques learned in those languages to whatever language he was programming in. It made his code utterly unmaintainable. We were getting complaints about memory leaks in the software, but we had no easy way, by looking at his code, of finding where the problem might be. The only senior engineer there, while I was there, spent a significant amount of his time rewriting this programmer's code, as structured code, so it would be readable.

I also had trouble with J.Ja's criteria and definitions, for similar
reasons. I think science in general, math in specific, and the
scientific method (in the design and debugging context) are particularly
pertinent to programming, but as I mentioned, music also seems to be a
good background; I've noticed especially that recording engineers -
people that work with multi-tracking music software and the layering of
sound - seem to be able to visualize a program in toto, once they're bitten by the coding bug.

Over the decades I've seen people from all walks of life with all sorts
of backgrounds end up as programmers, good and bad. I was once
responsible for a community college adult education "programming"
course, and I started the first semester with a dim view of the
potential I would be dealing with. But I was amazed at how many of
these Average Janes and Joes were good at it, and it was constantly
surprising to see who was good at what. A middle-aged matron with an
Agatha Christie jones was our best debugger, for example. Tenacious.

We never took programming very far, but it was clear from the beginning
that some members of the class had a real flair for what we were doing,
and loved it. Then there was a real interesting transition group - they
were perfectly capable of understanding the concepts and process, but
the whole business left them completely cold. And of course there were
people who never did quite get what a variable was, and left after the
first month...

What intrigued (and concerned) me most was that transition group - the
people who got it, but didn't care. They were by far the largest
segment of the class. It was then that I had my first inkling of what
the main qualification for a good programmer might be - you gotta LOVE
it. You gotta get a kick out of it. Once you have that, it's just a
matter of growth and native gifts. The ebb and flow of the business
determines where you go. But that love of the process determines how you grow.

J.Ja. starts his post by saying that it takes a special sort of person to code - "Writing
code involves a mode of thinking that is foreign to most people" was
how he put it. I used to think so too, and it pleased me greatly to
consider myself somehow special. But my experience teaching night
school stripped me of that particular conceit. Most people in that
class could code, and competently, if they thought it was important. But of those who could code, very few wanted to code.

So it isn't a "mode of thinking" that makes the difference. It's
desire, passion, interest. As a profession, we should be looking for
ways to communicate how exciting programming can be, if we want to
encourage people to understand it and enjoy it with us. I think this
might be harder than creating a list of qualifications, but maybe not.

Programming is everywhere - word macros, object scripting in games, in
3D Studio, in spreadsheets, in web pages; its all over the place, in
hundreds of variations. There's no common skill-set that encompasses my
teenaged son hacking Runescape servers AND my ex-wife's mother building
Excel macros AND me, writing real-time risk analysis software for day
traders. Sorry. The only common element is - lust. Avidity. The desire
to make something happen, the realization that you can do it, the
willingness to make the attempt...

I think I am beginning to come to terms with AJAX. Frequent readers know how much I dislike it. Joel Splosky ("Joel On Software") wrote a good piece recently (FogBugz 4 1/2 and Subjective Well-Being) that has helped turn me around, but only slightly. Joel helped me see where my anti-AJAX crusade is unproductive. AJAX does have the right goal in mind, but I still think that it is a poor technique for accomplishing it.

What Joel (rightly) points out is something that I harp on a lot, which is that the user experience is what it is all about. AJAX holds out the promise of much quicker response to user input, which is a prime factor in user satisfaction. AJAX also allows user interactivity that traditional Web applications do not provide, such as drag and drop and right click functionality.

What Joel misses though is the technical issues with AJAX. As Roger Ramjet (frequent ZDNet commenter) says, "JavaScript is the COBOL of Web development." I would like to add to that, "AJAX is the Yugo of programming techniques." Sure, it can get you where you want to go, but you really will not enjoy the ride. In this case, the destination is a great user experience, and the ride is the development process.

When you mix "the COBOL of Web development" (JavaScript) with "the US national budget of data transfer mechanisms," (XML), you get "the Yugo of programming techniques." AJAX combines a slow language that has many mildly different implementations with a bloated way of transferring data, and tries to display it on the screen with a system that still will not reliably display the way you want it (HTML). This just makes no sense to me.

Many AJAX proponents that AJAX is the only way to achieve these goals. I believe that this is incorrect. Remember, the goal is to provide a great user experience. Does drag and drop or right click add much value to the user? Yes, but only for some users. The majority of users do not use drag and drop or right click unless they have been taught to do so in a particular application. Users are timid. They do not try things outside of the ordinary. So to add this functionality is an incredible amount of work for no gain for most users.

So I am softening my stance a bit. If AJAX can be used in a way that the problems with JavaScript and XML do not hinder it (small chunks of data, basic JavaScript functionality) then it is a perfectly fine technique to use. But to try to replicate full rich client functionality just does not work. Microsoft has discovered this with the Live.com development. They reached very far, and had to drop the XML end of things in favor of JSON; XML parsing was taking far too long on the client side. AJAX can deliver usability benefits, but only when used appropriately and carefully, and the cost of development must be weighed against the expected utility.

J.Ja

To staticonthewire:

I think you're right that passion is key. It sounds like my experience. I always had a love for machines and science. As a child I was leaning towards becoming a meteorologist. I've sometimes said that if computers didn't exist, I'd probably be one of those storm chasers now. My first encounter with a computer was mesmerizing. I was 7 or 8. Learning to program one though, at the age of 11 was intimidating. I first learned to program on computers available at my local library. What really drew me to it was seeing other people program these computers, and seeing what they were doing with them. I loved the idea of making the machine do what I wanted it to, so I kept at it. I made a LOT of mistakes. There were many days where I felt worn out and defeated, because something was going wrong with what I wrote but I couldn't figure it out. I never got to the point of giving up though. It was like an itch I had to scratch. Getting a program all debugged and running was GREAT! It was exhilerating. I think the reason it felt so great is I realized how hard it was.

Fortunately I had some help too. The library had a few computers in a room, so other people there would lend me a hand.  After a few months I finally got to the point where I could write a program on my own without much hand-holding from helpers. Then I found a programming magazine that had what were called "type-ins". They published the source code for a program, and the accompanying article explained what the code did. A great learning tool. Not too long thereafter I started writing little word game programs. Then I started writing programs with features I thought would be genuinely useful to others. Things progressed. I got my computer science degree in the early 1990s and I started working in IT software. That's where I am today.

What made programming exciting to me was 1) knowing that the option was available, and 2) I got the opportunity to watch other people program, and watch their programs evolve as they fixed bugs and added features. Most of the initial programming I saw done was in graphics or gaming. The visual aspect is very exciting, and to actually watch it work under the control of a programmer is exciting. Heck, just seeing a program run, and allow me to interact with it, got me hooked on computers as a kid. What got me programming though was seeing the cause and effect, seeing the process that a programmer goes through to get something working. Another hook for me was I could relate to the end product.

One of my first memories of watching a programmer do his thing was watching a man sitting at one of the computers. I sat there observing what he was doing. He would type things in, and then run his program, repeatedly. He had already written a fair amount of code, so a concept was there. I tried to guess what he was trying to accomplish. It looked like he was trying to create a horse racing game, but the problem he was running into was that as the horse figures moved across the screen, the old copies stayed on the screen. Secondly they went across the screen very quickly. It didn't have a sense of suspense that one expects with a horse race. The programmer was trying to figure out how to erase the old copies so it looked like movement, rather than stamping a bunch of horse figures on the screen, and how to slow it down. If he had just been working on something high level, like statistical analysis, I don't think I would've been as interested. I wouldn't have understood it at that age.

In terms of multidisciplinary qualities, I found in college that I was good at music theory. I had participated in orchestra in public school, where it was available, but I was able to understand music at a symbolic level, which is a significant part of music theory. My professor commented that he noticed over the years that people who were good in math were also good at music theory. I'd say I was good at math, but not great.

So Mark, we can agree that at least in part, the "special sauce" that makes
for a good programmer consists of the pleasure we take in the game.
From your anecdotes, I would guess that early exposure would also help,
although it doesn't seem to be required (in my case, my father was an
E.E., and I could build logic circuits before I could ride a bike). A
minimal seat-of-the-pants ease with math is probably another enabler.

But this may not be what J.Ja is after. I've been trying to understand
what he's after - why he's examining the issue at all. I thought
initially that he was trying to assemble a list of criteria that would
make it easier for him to winnow resumes while hiring. When I read
through parts 2 & 3 of his post it seemed more like he wanted to
work up some sort of syllabus or study guide that we could all use to
raise our level of competency. But in the end I can't really determine
what his context is, and that makes his post it harder to address.

I have a personal interest in the question though, which is why I
postedat all (I very seldom post on TR). I've been in the business all
my life. I remember when the cutting edge in hard drive technology
consisted of a vertical aligned ceramic coated aluminum disk that held
about 250k - you couldn't say definitely, because we all loaded our own
disk I/O programs separately, and some were built for comfort and some
were built for speed. The disks were kept under big metal hoods because
periodically the ceramic coating on those big 24" diameter disks would
disintegrate and send shards of crap flying all over the place if they
were uncovered.

So I've been in the biz for some time, and have watched lots of
programmers come and go. In all the decades I've been at it, I have
experienced almost spiritual highs in the process of
programming. Few things compare favorably to the sensation of grasping
an entire system, creating it, making it all work, and seeing it help
people. But at the same time, I've found myself increasingly isolated,
completely unable to communicate what it is that I find so terribly
consuming.

Most people seem to think that programming is something like
accounting, and their eyes glaze over when you start talking about it.
Even most people who program for a living don't get it because they're
what J.Ja calls - what was his term? It was good... oh yes - "shake n
bake" programmers. Most programmers I run into cut code 9-5 and have
never had the experiences J.Ja indicates when he lists things like AI,
device kernels and so on - at best, they have had a very limited
exposure to exploratory programming and haven't had the eureka moment -
nothing has ignited their passion; they're in the biz because the money
looked good, or because it looked too hard to study law...

For years I've tried to understand why programming - which seems to me
to be shot through with all the colors of the rainbow - can seem so
colorless to the world at large. Maybe J.Ja is barking up the same tree?

To staticonthewire:

Since you had trouble understanding what Justin was getting at, I think I can summarize:

The first part is philosophical. Justin is advocating for efficiency and elegance. He thinks this can only really be achieved if programmers take skills learned from other disciplines, like philosophy and math, and apply them to their work. I think he's also saying that great programmers have an intuitive sense about problems. They don't just insist that they need to go down one line of reasoning to solve a problem. They explore other possible solutions, and try to pick the best one. Perhaps the reason he thinks math helps is that it emphasizes simplification, reducing more complex mathematical expressions to simpler ones. Good math courses encourage students to search for the best rule/formula that will solve the problem. He also says they should take a scientific approach to solving problems: try an idea, and observe how well it works, repeat.

In Part 2:

He says when you are forced, in an educational environment, to try and build basic things with little to no library support, you are confronted with how to write these functions efficiently, because you end up using the functions you are building, often. This is in contrast to the "shake 'n bake" programmers he speaks of, since they're just spoon-fed the APIs, which do a lot of work for them. They don't bother to explore how the APIs they use work, and therefore don't understand their pros and cons.

He gets into code efficiency (lines of code) in his Perl example.

In his open source project example, he emphasizes the need for a consistent, structured programming style.

Next he emphasizes learning a bunch of languages, adding them to your toolbox. He suggests using different languages together, since some languages are very good at certain tasks within a project.

Lastly he says keep learning, expanding your horizons, have a passion for learning.

In Part 3:

He says good programmers think long-term, and design their software accordingly. Further, they code so others can read it.

Programmers should think about memory usage that comes as a result of their actions. He uses the example of loading up a bunch of libraries to utilize one easily replicated function. What he means is there are situations where if you load a code library to access a function, that the library will have dependencies on more libraries, which will also get loaded. If the function is simple enough to just rewrite, without all the library dependencies, then you should do that, as opposed to bringing in all that overhead.

Programmers should think of processing time for their solutions. He uses XML as an example of something that's tempting to use, but is processor-expensive. He advocates writing custom CSV code instead for transporting tabular data. The code will run faster.

Programmers should be conscious of how their language compiler/interpreter handles certain structures. Doing things that seem benign can have negative effects on performance.

In short, in this last part he's saying that programmers need to be conscious of the underlying implications of what they're doing. Logically, at a high level, everything they do makes sense, but when you dig deeper, they're creating programs that use a lot more memory than they need to, and run slower than they should. Programmers need to think about this.

Overall, he advocates for efficiency, efficiency, efficiency, and elegance. I think what Justin is also advocating is that great programmers are in a sense trained in computer science, because everything he advocates is taught in a good CS curriculum: good structured code, descriptive variable names (and comments--he didn't mention this), emphasis on efficient use of algorithms, learning how to write efficient code, learning how programs execute, and how compilers/interpreters translate/execute programs, learning a variety of programming languages and see how each has certain advantages and disadvantages, and learning how to use different programming languages together (at least they used to teach this).

In all the decades I've been at it, I have experienced almost spiritual highs in the process of programming. Few things compare favorably to the sensation of grasping an entire system, creating it, making it all work, and seeing it help people. But at the same time, I've found myself increasingly isolated, completely unable to communicate what it is that I find so terribly consuming.

Huh. I would've thought the people who got into it for the money would be long gone by now. IT hasn't been the best place to be in terms of worker morale and pay.
Interestingly the only programmers I've met who for the most part see the programming world as "colorless", as you put it, are female. I haven't met many female programmers, and the few I've talked to have other interests they're more passionate about. I've asked them if they've written programs on their own time. Without fail they've said no. In fact they think I'm strange for asking the question, like, "Why would I want to do THAT?" One lady I asked thought of programming like accounting, just like you said. So I could understand why she wouldn't see it as a recreational activity. This isn't to say they were necessarily bad programmers or unskilled. They just didn't have the passion for it. Please understand I'm not trying to cast aspersions on all female programmers. I wish there were more of them in our profession. This has just been my experience.

For years I've tried to understand why programming - which seems to me to be shot through with all the colors of the rainbow - can seem so colorless to the world at large. Maybe J.Ja is barking up the same tree?

I think you are both barking up the same tree. He's describing the frustration he's encountered from dealing with people who are programmers but care only enough to meet the minimum standards necessary to not get fired. They don't have any ambition to become better programmers. To them it's just a job. They don't care about the craft.

Just recently I read some articles by Joel Spolsky, Paul Graham, and others who complain about something similar to what you and Justin have talked about. They take a slightly different tact in they put the blame squarely on the Java programming language. They claim that Java enabled schools to spring up that teach people just enough to get something done, but otherwise they produce programmers who are unenlightened and messy. They blame Java, because they claim it handles all the messy stuff that programmers used to have to worry about, like memory management. Come to think of it, I don't understand why they don't direct their ire at Visual Basic as well. It shares some of these qualities with Java, not to mention .Net. On the upside for corporations, they said, Java enabled a lot more programmers to be produced. During the '90s this was seen as a boon, since companies complained of a shortage (they still do). The result though, they said, was a lot of second-rate software, failed projects, and failed companies.

If you're interested, the web page that directed me to these articles is at: "Why Java is not my favorite programming language" http://web.onetel.net.uk/~hibou/Why%20Java%20is%20Not%20My%20Favourite%20Programming%20Language.html

Interestingly, several of these authors had good things to say about Lisp, especially Paul Graham, who is a Lisp advocate. Graham's account of his use of Lisp in his start-up years ago, called ViaWeb (now Yahoo! Store), is compelling.

I programmed in Lisp a bit in college, but it was so alien to me, plus I had a terrible teacher for the class, and the materials I was given to learn with were not good. It turned me off to Lisp. But these guys convinced me to give it a second chance. I've been taking up learning it again just recently. The selling points for me were that Lisp has been, and continues to be used in some real world projects, and not just for AI. Secondly, at least one of the folks said that Lisp is a good language to learn, because it teaches you to be a better programmer, even if you never end up using it in a real project, like what Justin said about exposure to mathematics. The disadvantage Lisp has is most programmers don't know it, or avoid it, due to it being so different from the dominant languages. A few who have tried it complain that it lacks robust tool and library support.

To staticonthewire:

Since you were having trouble understanding what Justin was getting at, I believe I can summarize:

The first part is philosophical. Justin is advocating for efficiency and elegance. He thinks this can only really be achieved if programmers take skills learned from other disciplines, like philosophy and math, and apply them to their work. I think he's also saying that great programmers have an intuitive sense about problems. They don't just insist that they need to go down one line of reasoning to solve a problem. They explore other possible solutions, and try to pick the best one. Perhaps the reason he thinks math helps is that it emphasizes simplification, reducing more complex mathematical expressions to simpler ones. Good math courses encourage students to search for the best rule/formula that will solve the problem. He also says they should take a scientific approach to solving problems: try an idea, and observe how well it works, repeat.

In Part 2:

He says when you are forced, in an educational environment, to try and build basic things with little to no library support, you are confronted with how to write these functions efficiently, because you end up using the functions you are building, often. He says this to contrast against the "shake 'n bake" programmers, because they're just spoon-fed the API. They haven't looked deeply into the API, or read up on them, to consider the pros and cons of certain functions.

He gets into code efficiency (lines of code) in his Perl example.

In his open source project example, he emphasizes the need for a consistent, structured programming style.

Next he emphasizes learning a bunch of languages, adding them to your toolbox. He suggests using different languages together, since some languages are very good at certain tasks within a project.

Lastly he says keep learning, expanding your horizons, have a passion for learning.

In Part 3:

He says good programmers think long-term, and design their software accordingly. Further, they code so others can read it.

Programmers should think about memory usage that comes as a result of their actions. He uses the example of loading up a bunch of libraries to utilize one easily replicated function. What he means is there are situations where if you load a code library to access a function, that the library will have dependencies on more libraries, which will also get loaded. If the function is simple enough to just rewrite, without all the library dependencies, then you should do that, as opposed to bringing in all that overhead.

Programmers should think of processing time for their solutions. He uses XML as an example of something that's tempting to use, but is processor-expensive. He advocates writing custom CSV code instead for transporting tabular data. The code will run faster.

Programmers should be conscious of how their language compiler/interpreter handles certain structures. Doing things that seem benign can have negative effects on performance.

In short, in this last part he's saying that programmers need to be conscious of the underlying implications of what they're doing. Logically, at a high level, everything they do makes sense, but when you dig deeper, they're creating programs that use a lot more memory than they need to, and run slower than they should. Programmers need to think about this.

Overall, he advocates for efficiency, efficiency, efficiency, and elegance. I think what Justin is also advocating is that great programmers are in a sense trained in computer science, because everything he advocates is taught in a good CS curriculum: good structured code, descriptive variable names (and comments--he didn't mention this), emphasis on efficient use of algorithms, learning how to write efficient code, learning how programs execute, and how compilers/interpreters translate/execute programs, learning a variety of programming languages and see how each has certain advantages and disadvantages, and learning how to use different programming languages together (at least they used to teach this).

In all the decades I've been at it, I have experienced almost spiritual highs in the process of programming. Few things compare favorably to the sensation of grasping an entire system, creating it, making it all work, and seeing it help people. But at the same time, I've found myself increasingly isolated, completely unable to communicate what it is that I find so terribly consuming.

Huh. I would've thought the people who got into it for the money would be long gone by now. IT hasn't been the best place to be in terms of worker morale and pay.

Interestingly the only programmers I've met who for the most part see the programming world as "colorless", as you put it, are female. I haven't met many female programmers, and the few I've talked to have other interests they're more passionate about. I've asked them if they've written programs on their own time. Without fail they've said no. In fact they think I'm strange for asking the question, like, "Why would I want to do THAT?" One lady I asked thought of programming like accounting, just like you said. So I could understand why she wouldn't see it as a recreational activity. This isn't to say they were necessarily bad programmers or unskilled. They just didn't have the passion for it. Please understand I'm not trying to cast aspersions on all female programmers. I wish there were more of them in our profession. This has just been my experience.

For years I've tried to understand why programming - which seems to me to be shot through with all the colors of the rainbow - can seem so colorless to the world at large. Maybe J.Ja is barking up the same tree?

I think you are both barking up the same tree. He's describing the frustration he's encountered from dealing with people who are programmers but care only enough to meet the minimum standards necessary to not get fired. They don't have any ambition to become better programmers. To them it's just a job. They don't care about the craft.

Just recently I read some articles by Joel Spolsky, Paul Graham, and others who complain about something similar to what you and Justin have talked about. They take a slightly different tact. They put the blame squarely on the Java programming language. They claim that Java enabled schools to spring up that teach people just enough to get something done, but otherwise they produce programmers who are unenlightened and messy. They blame Java, because they claim it handles all the messy stuff that programmers used to have to worry about, like memory management, but it leads to carelessness. Come to think of it, I don't understand why they don't direct their ire at Visual Basic as well. It shares some of these qualities with Java, not to mention .Net. On the upside for corporations, they said, Java enabled a lot more programmers to be produced. During the '90s this was seen as a boon, since companies complained of a shortage (they still do). The result though was a lot of second-rate software, failed projects, and failed companies. They also emphasize the virtues that are taught in the older computer science curriculum. One of them claimed that Java has kind of corrupted computer science at universities, because it de-emphasizes some of the old virtues.

If you're interested, the web page that directed me to these articles is at: "Why Java is not my favorite programming language" http://web.onetel.net.uk/~hibou/Why%20Java%20is%20Not%20My%20Favourite%20Programming%20Language.html

Interestingly, several of these authors had good things to say about Lisp, especially Paul Graham, who is a Lisp advocate. Graham's story of his start-up where he used Lisp extensively years ago, called ViaWeb (now Yahoo! Store) is compelling.

I programmed in Lisp a bit in college, but it was so alien to me, plus I had a terrible teacher for the class, and the materials I was given to learn with were not good. It turned me off to Lisp. But these guys convinced me to give it a second chance. I've taken up learning it again recently. The selling points for me were that Lisp has been, and continues to be used in some real world projects, and not just for AI. Secondly, at least one of the folks said that Lisp is a good language to learn, because it teaches you to be a better programmer, even if you never end up using it in a real project, like what Justin said about exposure to mathematics.

To staticonthewire:

Since you were having trouble understanding what Justin was getting at, I believe I can summarize:

The first part is philosophical. Justin is advocating for efficiency and elegance. He thinks this can only really be achieved if programmers take skills learned from other disciplines, like philosophy and math, and apply them to their work. I think he's also saying that great programmers have an intuitive sense about problems. They don't just insist that they need to go down one line of reasoning to solve a problem. They explore other possible solutions, and try to pick the best one. Perhaps the reason he thinks math helps is that it emphasizes simplification, reducing more complex mathematical expressions to simpler ones. Good math courses encourage students to search for the best rule/formula that will solve the problem. He also says they should take a scientific approach to solving problems: try an idea, and observe how well it works, repeat.

In Part 2:

He says when you are forced, in an educational environment, to try and build basic things with little to no library support, you are confronted with how to write these functions efficiently, because you end up using the functions you are building, often. He says this to contrast against the "shake 'n bake" programmers, because they're just spoon-fed the API. They haven't looked deeply into the API, or read up on them, to consider the pros and cons of certain functions.

He gets into code efficiency (lines of code) in his Perl example.

In his open source project example, he emphasizes the need for a consistent, structured programming style.

Next he emphasizes learning a bunch of languages, adding them to your toolbox. He suggests using different languages together, since some languages are very good at certain tasks within a project.

Lastly he says keep learning, expanding your horizons, have a passion for learning.

In Part 3:

He says good programmers think long-term, and design their software accordingly. Further, they code so others can read it.

Programmers should think about memory usage that comes as a result of their actions. He uses the example of loading up a bunch of libraries to utilize one easily replicated function. What he means is there are situations where if you load a code library to access a function, that the library will have dependencies on more libraries, which will also get loaded. If the function is simple enough to just rewrite, without all the library dependencies, then you should do that, as opposed to bringing in all that overhead.

Programmers should think of processing time for their solutions. He uses XML as an example of something that's tempting to use, but is processor-expensive. He advocates writing custom CSV code instead for transporting tabular data. The code will run faster.

Programmers should be conscious of how their language compiler/interpreter handles certain structures. Doing things that seem benign can have negative effects on performance.

In short, in this last part he's saying that programmers need to be conscious of the underlying implications of what they're doing. Logically, at a high level, everything they do makes sense, but when you dig deeper, they're creating programs that use a lot more memory than they need to, and run slower than they should. Programmers need to think about this.

Overall, he advocates for efficiency, efficiency, efficiency, and elegance. I think what Justin is also advocating is that great programmers are in a sense trained in computer science, because everything he advocates is taught in a good CS curriculum: good structured code, descriptive variable names (and comments--he didn't mention this), emphasis on efficient use of algorithms, learning how to write efficient code, learning how programs execute, and how compilers/interpreters translate/execute programs, learning a variety of programming languages and see how each has certain advantages and disadvantages, and learning how to use different programming languages together (at least they used to teach this).

In all the decades I've been at it, I have experienced almost spiritual highs in the process of programming. Few things compare favorably to the sensation of grasping an entire system, creating it, making it all work, and seeing it help people. But at the same time, I've found myself increasingly isolated, completely unable to communicate what it is that I find so terribly consuming.

Huh. I would've thought the people who got into it for the money would be long gone by now. IT hasn't been the best place to be in terms of worker morale and pay.

Interestingly the only programmers I've met who for the most part see the programming world as "colorless", as you put it, are female. I haven't met many female programmers, and the few I've talked to have other interests they're more passionate about. I've asked them if they've written programs on their own time. Without fail they've said no. In fact they think I'm strange for asking the question, like, "Why would I want to do THAT?" One lady I asked thought of programming like accounting, just like you said. So I could understand why she wouldn't see it as a recreational activity. This isn't to say they were necessarily bad programmers or unskilled. They just didn't have the passion for it. Please understand I'm not trying to cast aspersions on all female programmers. I wish there were more of them in our profession. This has just been my experience.

For years I've tried to understand why programming - which seems to me to be shot through with all the colors of the rainbow - can seem so colorless to the world at large. Maybe J.Ja is barking up the same tree?

I think you are both barking up the same tree. He's describing the frustration he's encountered from dealing with people who are programmers but care only enough to meet the minimum standards necessary to not get fired. They don't have any ambition to become better programmers. To them it's just a job. They don't care about the craft.

Just recently I read some articles by Joel Spolsky, Paul Graham, and others who complain about something similar to what you and Justin have talked about. They take a slightly different tact. They put the blame squarely on the Java programming language. They claim that Java enabled schools to spring up that teach people just enough to get something done, but otherwise they produce programmers who are unenlightened and messy. They blame Java, because they claim it handles all the messy stuff that programmers used to have to worry about, like memory management, but it leads to carelessness. Come to think of it, I don't understand why they don't direct their ire at Visual Basic as well. It shares some of these qualities with Java, not to mention .Net. On the upside for corporations, they said, Java enabled a lot more programmers to be produced. During the '90s this was seen as a boon, since companies complained of a shortage (they still do). The result though was a lot of second-rate software, failed projects, and failed companies. They also emphasize the virtues that are taught in the older computer science curriculum. One of them claimed that Java has kind of corrupted computer science at universities, because it de-emphasizes some of the old virtues.

If you're interested, the web page that directed me to these articles is at: "Why Java is not my favorite programming language" http://web.onetel.net.uk/~hibou/Why%20Java%20is%20Not%20My%20Favourite%20Programming%20Language.html

Interestingly, several of these authors had good things to say about Lisp, especially Paul Graham, who is a Lisp advocate. Graham's story of his start-up where he used Lisp extensively years ago, called ViaWeb (now Yahoo! Store) is compelling.

I programmed in Lisp a bit in college, but it was so alien to me, plus I had a terrible teacher for the class, and the materials I was given to learn with were not good. It turned me off to Lisp. But these guys convinced me to give it a second chance. I've taken up learning it again recently. The selling points for me were that Lisp has been, and continues to be used in some real world projects, and not just for AI. Secondly, at least one of the folks said that Lisp is a good language to learn, because it teaches you to be a better programmer, even if you never end up using it in a real project, like what Justin said about exposure to mathematics. I've read a few complaints that Lisp does not have robust tool and library support. Plus there are not that many programmers who know Lisp. They either don't know about it or avoid it, probably because it's so different from the dominant languages out there.

Mark -

You summarized my thoughts perfectly, and you are spot on with where I was going with all of this. I am currently working on another post regarding the emotional involvement with coding.

Joel Splosky and Paul Graham are both two excellent people to be reading. In my most recent blog, I used one of Joel's recent postings to soften my anti-AJAX stance a bit. He reminded me that the users do not really care what is happening, as long as it works well for him.

I never had any direct Lisp experience, but EdScheme is a version of Scheme, which is a Lisp derivitive. Mr. Graham's writings have made me very curious about Lisp, and I would like to know more about it. Sadly, the work I get paid to do during the day is just not something that I would ever get to use Lisp with (I spent more of my programming time in VB.Net or VBA, bleh), and my personal time is extremely compressed at the moment. I am taking the chance to experiement a bit with F# (Microsoft's version of O'Caml), since it is easy for me to disguise "learning something new" as "learning to do things better" if it is occuring within a Microsoft environment.

To all of the people commenting on this blog, thanks for the great discussion! This is the smartest and best discussion I have seen on this site since the "Could AI Ever Happen?" discussion.

J.Ja

There was a lot of fantastic feedback from readers regarding my recent series, "How to Think like a Programmer" (Part 1, Part 2, and Part 3). Two readers, staticonthewire and Mark Miller made some extremely astute comments regarding the role of emotions. The series left out emotions, but that is not to say that they do not play a role. staticonthewire remarked that, contrary to my example, he has met scientists who made lousy programmers ? and a mystery novel buff who was fantastic, and that the difference was passion for programming.

I cannot agree more. A programmer who treats their job as a way to make money and nothing more will rarely offer make than what they are asked to give. These are the programmers who churn out mediocre code on a mediocre project, do not involve themselves in making better software, just meeting the project specs, and so on. The programmers that are passionate about technology and code writing are the ones who will go home and research the best way of doing something, write code in their spare time, learn new things after hours, and more. These are the programmers you want to hire.

My initial experiences with programming were amazing. I loved having a problem to try to solve, and figuring out the solution using nothing more than my own wits. We did not have Internet then, the answers were not a Web search away. You succeeded or failed based upon the knowledge, experience, and skill of yourself and the people you were working with. The debugging tools were primitive at best; dumping variable state information to the screen or a file was the best and easiest way to see what was happening at run time. Frequently, I would print out all of my source code, and follow it through by hand, inventing user input and seeing how the code operated in response. I could not have been happier.

What I love about writing code is the nitpicking and problem solving. A few days ago, someone asked me to describe what it is like to do my job. I told them, "I am a professional nitpicker. Every detail counts. On top of that, my job is to think of the craziest way someone could use my product, and then have it continuing functioning." I think that sums it up pretty nicely. I enjoy programming for the same reasons that I enjoy reading great books, doing crossword puzzles, listening to "artsy" music, looking at modern art, and watching David Lynch films. It is really all the same type of thinking, just a different medium.

It seems that in the last ten years or so, colleges started moving away from teaching Computer Science as an offshoot of mathematics, as a mostly theoretical discipline, to teaching Computer Science as a vacation. Instead of learning about "big endian systems," "O numbers," formal logic, and so forth, CS students are being taught how to write code in Java, SQL, and other languages. They are being given a four year education in "best practices." These are "shake and bake programmers." The passion, the excitement of solving problems has been taken away, to be replaced by painting by the numbers. The worst part about being taught programming at the vocational level, is that the industry changes rapidly enough that whatever you learned is going to be outdated by the time you graduate. Chances are, it was outdated by the time it got into the curriculum.

Programming is increasingly a matter of gluing together libraries written by a few select people, the ones who are having all of the fun. At this point, the places where truly interesting codesmithing seems to occur is in the shops making development tools (Sun, Microsoft, Borland, etc.) and the small places doing niche work. Some of the FOSS projects are extremely interesting as well, and they have the advantage of not caring about profits, so they are free to work on unusual and creative projects regardless of potential market size. Anyone in between these types of environments is just gluing together libraries written by a big-time player into a standard, boring C/R/U/D application.

One thing I have found over the years is that when I am enjoying myself at my job and being challenged, the passion is there. Put me on a tight deadline to come up with something that seems impossible, and you get great results. If you hand me a project with a long deadline and involves zero creativity or problem solving, it is likely that I will enjoy myself as much and the project will drag. The passion just cannot exist for a dull project. I think this is one of my big concerns with the IT industry. There was an extremely long period of time where things were being changed constantly, and when a piece of software or hardware, or a way of doing things became obsolete, it was replaced by something markedly better and more interesting, and more pleasant to work with. Every day brought exciting change.

It is a shame that the world of programming seems to be moving slowly towards "shake and bake" code. Maybe the direction will reverse? I certainly hope it will! I am passionate about programming. I am one of those twisted individuals who writes code in their spare time. I rarely have a day truly off of work, because even when I have the day off I cannot resist popping onto the VPN and doing a few things. For me, writing code is like playing Civ III, but instead of "just a few more turns!" it is "just one more subroutine!" When a project is rolling, I have been known to spend 16, 24, sometimes 50 hours straight at the office working on it (they know better than to make comments about the smell, and to just smile and appreciate the results). This is not too uncommon for programmers to do, and has been the source of jokes for decades. How many other jobs are notorious for having these types of things happen? Let's hear it for passionate programmers would wide, and give ourselves a hand.

J.Ja

Mark, I appreciate the trouble you took to summarize J.Ja's post. To clarify, I wasn't having trouble understanding J.Ja's content (although your summary was very comprehensive). I was having trouble understanding the why behind the content - why he thought his quest for "what goes into a top-flight programmer" might bear significant fruit.

As I emphasized (I believe in my first and second posts) there are
few, if any, comprehensively useful programmer characteristics that I
can identify. Even the efficiency and elegance that J.Ja admires can be
a liability in a large shop, where individual elegance and efficiency
can explode an operations' overall efficiency. I addressed the futility of efficiency in this context with the example of the cobbler, if you recall.

So my puzzlement with J.Ja's post was not with the content - Justin
writes with concision and cogency and puts things in ways that makes
them easy to understand. Your summary was an equally clear distillation
of his presentation. But neither you or he managed to address my
puzzlement - trying to define something like this seems impossible, so
why...?.

The futility of developing a comprehensive "list" of good programmer
characteristics or skills or activities led me to pondering the
underlying issue, which to me brings us to the whole business of
passion, of loving what you do, and personally, I think that's about as
far as it can realistically be taken.

For the record, my own tendencies are very much like J.Ja's - I've
worked with many languages, some by fiat but most by choice, and have a
strong background in basic science and math and would heartily endorse
most of his recommendations. But none of them will mean anything
without a deep desire to explore this art of ours (maybe someday it
will evolve into a science...).

"Huh. I would've thought the people who got into it for the money
would be long gone by now. IT hasn't been the best place to be in terms
of worker morale and pay."

Yeah, well, I didn't say they were RIGHT. I just said that was their motivation...

BTW, I know many woman programmers, and IMHO the range of excellence is
about the same as in men - 10% clueless, 80% "shake-n'bakers", 10%
genuine coin / the real deal / exploratory programmers. I've pulled an
infinite number of all-nighters (no really - I counted) with very
capable coders, women and men , and I can't say I've seen any
difference in competence or dedication.

I do notice that there are variations in emphasis and focus, but no
more than I would expect from critters as different as men and women.
I've noticed the same sort of variation between Russian programmers,
say, and programmers from the US or Japan. Cultural artifacts affect
how problems are approached, but the random walk we all perform seems
to bring us all to the same sorts of solutions...

"I think you are both barking up the same tree. He's describing the
frustration he's encountered from dealing with people who are
programmers but care only enough to meet the minimum standards
necessary to not get fired. They don't have any ambition to become
better programmers. To them it's just a job. They don't care about the
craft."

Oh, I share his frustration, believe me. There is nothing worse than
starting a project full of fire and realizing by the end of the first
week that the team with whom you're saddled consists of three
shake-n-bakers, a glorified word processor, two interns who just
finished their first "computer" course in community college and one
brilliant but completely warped programmer who frames all his function
calls in the form of koans that no one else can understand and is
deeply involved in completing a sculpture on his desk made of the
carefully preserved bodies of cockroaches he's trapped under his desk...

Whatever Spolsky & Graham et al may say, Java is not the root of
all evil, nor is VB, or .NET or anything else. I use all these
technologies competently and if I do say so myself, with real flair.
I love Java, and VB and javascript too - hell, I still have a soft spot
for Algol... the problem isn't with the tech, the problem is with the
people, as always. If we ever get to the point where we have a
foolproof language we'll find that it has a terribly limited array of
solutions it can present. If you don't have enough rope to hang
yourself, you don't have enough to save your ass, either. Or even solve
your programming problem...

There are always people grumbling about how easy kids have it these
days, they don't have to pay attention like we did in the good old
days. Crap. There were just as many shake-n-bakers back in the good old
days, FUBARing everything in sight. The 10% / 80% / 10% spread seems to
be holding, if you ask me.

I always liked Lisp as a toy or academic language, or for the
individual programmer or boutique project but I think it's a language
meant for the dedicated programmer. I shudder at the thought of a big
corporate shop filled with Lisp coders...

If you like Lisp you might
want to get a copy of Scheme, too, as J.Ja suggests I believe I have
source for an old version of Lisp and Scheme, if you're curious - or at
least the BNF that you could LEX/YACC into something workable...

As I mentioned in my last post, I was drawn to J.Ja's blog entry because it resonates with a
my own parallel quest, and perhaps I've led the subject too far away
from his original intent to be a useful contributor here. But Justin
has provoked this sort of resopnse from me before, in the "Could AI
ever Happen" discussion he mentioned, where the two of us, along with
several others, managed to carry a fairly simple question into some
very deep waters.

So maybe it's a personality thing... 

In any case, it's been a pleasure reading everyone's thoughts.

To staticonthewire:

I got a good laugh out of your description of some typical programming teams you've dealt with. Wow. A programmer who wrote his function calls in koans and was building a sculpture out of dead cockroaches from under his desk! What an image! LOL!!!! :D I assume you said some of that in gest. Somehow, as I read that I felt like I could relate a little bit, like I was the guy who was doing that at one point in my life. I have since been reformed :). When I got out of college I was a bit full of myself in terms of technique. I remember when I got into one of my first jobs, working on a script interpreter written in C, I took one look at the code and said to myself "Oh this will never do." The program had it's bad qualities (there was a lot of cutting and pasting of code that went into it). It worked quite well for what it did. It was difficult to modify, however. Overall I wouldn't say the program was terrible. I eventually convinced my boss to let me refactor the code (I use the term loosely). Before doing this I had read a book called "Code Complete", and I took a couple of its suggestions to heart: always consider the "else" case in an "if" condition, and always put the most common expected action first in an "if-else" statement (like "if (<commonly expected condition>) {<commonly expected action>} else {<rare, unexpected action/error condition>}).

This led me to write if-else's like this sometimes:

if (<commonly expected condition>) {} else {<error action>}

It was my way of testing for an exception condition (such a situation would be an exception in C++, for example), in a case where if the condition was true, everything was fine, so do nothing. I used this form often. Eventually my boss ragged on me for writing code this way though.

As I progressed through the code I fell into the "mission creep" trap. I found more and more things wrong with it. Instead of just improving it a little, like consolidating the cut-and-paste code into functions, I insisted on rewriting the parser into lex/yacc code. Originally it used gets() and a tokenizer function for parsing. Further, I was dying for a way to make the pointers more manageable. There were tons of them, very complicated to deal with. Every time I made a change to the program, it would crash the computer because of some errant null pointer (it was running under straight MS-DOS). Instead of taking me a couple weeks like I thought, I ended up spending something like a couple months on it. Once I was done I was so proud of myself. IMO the code was a thing of beauty to behold. In order to do this, however, I had to take out some language features. Best I could tell, yacc couldn't deal with a couple of the language structures that used to be there, so I convinced my boss to let me take them out.

There were a couple problems though. The new program required so much memory that I ended up compiling it using a DOS-extender. This meant that normal debuggers (like Borland C++ for DOS) would not work. I ended up using some other tool that could understand the DOS-extended code, but it was more difficult to use. The other problem came when our salesperson wanted me to create a software package, which included my program, which was a report generator (which included the script interpreter) for a demo he was going to do. It turned out he needed some of those language features I thought I could take out. So I ended up giving him a version that was several months old, from a time before I did all of my meticulous work. What I realized then and there was that all I had done was satisfy myself. My thing of beauty was of no use to some of the people who actually needed to use it. That was a huge lesson for me. A few months later we ended up dropping the entire thing. We had one main customer we were developing this highly customized system for, of which the report generator I had been working on was a part, and they ultimately came to the conclusion that it didn't serve them. So the report generator was dropped entirely. We ended up going with a completely different solution based on de facto standards: Windows 3.11 and a relational database. The reason we needed the in-house-created report generator at all is the company was trying to market a custom designed, data-driven application authoring system, which used a non-relational database. Anyway, the main customer, and subsequent customers, really liked the Windows 3.11 solution. So the company went with that. All the changes I had worked on for the script interpreter were for naught. No one ended up using it. It wasn't entirely my fault. Part of it, as I would later find out, was the fault of management, who despite the protestations of the senior engineer in charge, insisted on this highly custom system being developed in the first place. It showed me that I had missed the forest for the trees, in my part of it. I don't think I could've done much better at the time, given my immaturity, and that I had difficulty understanding what the full product was until I had been working there for about a year. I assumed the project was very important and would get used.

Anyway, I wanted to address something you said earlier, that you felt isolated and have had difficulty communicating your passion for programming to people who don't seem to get it. I don't have a lot of answers for you in solving that problem. It kind of sounds to me like when you've been teaching students, you're dealing with adults. Perhaps you might want to start with kids. Get 'em while they're young, in other words. When I was in high school, I had the opportunity to teach kids programming, in BASIC, in elementary school. What I found was there is a certain age when they are "ready" for the material. I didn't do it for very long, but I found that the "magic" age when they can start grasping programming concepts easily is 10-12 years old. I also had the opportunity to work with younger kids, and they had difficulty with the concept. I can say from my own experience, I started learning programming when I was about 11 or 12.

At the younger ages, they're still interested in fun things, applying their creativity to what they're doing. I would think you would get an opportunity to nurture that in the realm of programming, to get them to use their creativity, and have those AH-HAH!! moments, that sense of victory from having conquered a hard problem and to see the fruits of their labor play out onscreen just as they had imagined it. I've seen teenagers in programming courses who didn't really get the excitement. They tended to drop out of the class though.

I would think working with older folks (adults), that they have more practical concerns that dominate their thinking: getting to the goal (getting the project done), and making enough money to support their families and their standard of living. To them, for the most part, having those AH-HAH!! moments probably isn't that valuable. Just a suggestion.

Last week, I read the first chapter of Information Dashboard Design: The Effective Visual Communication of Data (ISBN: 0-596-10016-7) by Stephen Few, courtesy of the publisher, and available as a free download on TechRepublic. I liked what I read, and purchased a copy of the book. I finished reading it today, and wanted to share a bit about it.

I enjoyed reading this book. I have studied usability theory for many years (primarily Jakob Nielsen, but other authors as well) and did not find anything in this book to contradict what I already knew. I found the information in this book to be very useful in and of itself. Even better, the information in this book is extremely applicable to other less-specific forms of communication, such as Web sites in general, print, and so on. The author does an excellent job explaining the best uses of different types of graphs, data display, how to separate different groups of information on the screen, on so on. The author also (wisely) completely sidesteps any mention of any particular software packages. Because of this, this book will remain pertinent for a very long time. There are many excellent examples of good data presentation as well as bad data presentation.

The book itself was rather lightweight. Significant portions of each page were whitespace and the book was printed in a rather large typeface. The book itself claims 223 pages, but the actual content was more like 200 pages. Furthermore, much of page space was taken up by illustrations (reasonable, since the book is about visual design). There were also many "filler" pages throughout. Overall, I definitely got the impression that the book had a lot of "puff" to it to help justify its price tag. I read the book in less than two working days, merely by reading while my Excel reports were running. I think it was well under two hours to finish the book.

This leads to my biggest problem with the book, which was that it was extremely basic. The examples in the book of bad design show that either the vast majority of the people writing interfaces are clueless, or that systems with poor usability sell better than those with good usability. Overall, there was very little new to me in this book. But that is me, and the proliferation of unusable systems shows that the industry could use an easy to read, basic guide on data presentation. If you are new to the field of data presentation, GUI design, or Web design, or think that a basic text on how to show data effectively would be helpful, this is the book for you. If you have experience and knowledge in usability already, you will probably find this book to be a little bit too simplistic and general for your needs.

J.Ja

I guess there allways will be people to argue but why would Eclipse and Netbeans really have to cooperate for Java to loose or not. It is Java itself that has to make things happen. As it was rightfully said here, if there's only one interpreter, there would be nearly no problems at all. If they want to, they can create some but it would be much easier to cooperate.

 As for the .Net argument... I'm not sure it will "win" against Java in a near future (5 - 10 years) Because it is hell to make the most simple program runs on another platform and we have time before it happens.

For the differences between Eclipse and Netbeans. I think everyone will have to agree that they're not the same. Eclipse has much more in it. When you download the platform, it comes with PDE (plugin development environment) and JDT (Java development tools) and there are lots of thousands of plugins made for eclipse.
I'm not aware of anything like that with NetBeans. NetBeans is "cleaner". No doubt. And that's probably because it is more specific not targeting so widely.

For my part I LOVE Eclipse because you can find a plugin for anything you want and it generally takes 10 seconds to install it. I program in python, C, Java and there are Eclipse plugin for all of them also for tools like Antlr or Swing or anything you want. I allways found a plugin to help me in my work. And that's probably the reason NetBean is better if it's just Java you're up to.

To conclude I would recommand NetBeans if yoou will program Java but Eclipse if you're doing different things and you  like to do it in the same environment.

This is the first in a two part series.

Developers are often cocooned in a shell, isolated from much of the greater operations of their employer. All too often, IT is treated as a black box, frequently with GIGO (garbage in, garbage out) results. Project specifications are often driven by people and departments with little understanding of technical matters, and the people implementing the specifications have little understanding of the why of the project. When the why is "create or expand an Internet revenue stream," the result can be disastrous.

Many Web sites (especially online stores) are, and should be driven and run by the Marketing or Sales departments. They are experts at selling the product. They know the market, the competition, and more. What they do not know is Web development, and on occasion they do not understand Web design either. This creates bad project specifications, where the how is dictated in a demanding yet vague way, and the why is completely ignored. I have been given project specifications similar to these way too often:

* Look similar to site XYZ, but with our logo and colors
* Have a drop down menu system like site ABC
* We want to collect the following information from visitors at every opportunity: [insert list of the most personal and intimate details of the visitors' life here]
* Spiffy Flash intro
* A lengthy "About Us" page that gives the users plenty of pictures of our CEO and facility
* A shopping cart system, preferably one that does everything that a live salesperson would do, with a strange interface and bizarre options for the user
* "Community building" features, such as a forum, product ratings, instant messaging between registered users, wikis, blogs, RSS aggregation, and a million other buzzwords of the week
* "Viral marketing" systems like affiliate programs

Sound familiar? That pretty much sums up nearly every Web store project specification that has been dictated to me. It is pretty interesting how most of the items on the list are, at best, only loosely related to the why of the project: to sell products! Here is what a why oriented project specification might look like for a Web store:

* Must appeal visually to our target audience: [insert target market demographics here]
* Site must be extremely usable by our target audience, and very usable by non-target audience members
* Site must present the most useful and interesting product information up front, but allow visitors to get as much product detail as they need, to simultaneously encourages sales, as well as minimize the need for customers to contact us before making a purchase
* Site must be consistent with our corporate "look and feel" in a manner that does not compromise usability
* Site must be a secure as possible
* Site should foster a trust relationship between our company and the customers, particularly new customers
* Site must have search engine optimization baked in from Day 1

See the difference? Interestingly enough, not a single item on the why oriented project specification precludes a single thing on the how oriented list; however, many of the items on the how oriented list can preclude items on the why oriented list, depending upon a number of non-technical factors. For example, if the target audience is "well-to-do, young graphics designers using Macintoshes who are at work," a site with a lot of Flash pieces that often emphasizes form over function is not likely to hurt sales, and may even boost them a bit. If the target audience is "retired people on limited incomes," chances are that anything with a font size smaller than twelve points, or that requires "the latest and greatest" in plugins, or a good deal of technical savvy will not be able to sell much product at all.

In other words, we have a classic case of missing the forest for the trees. The trees are technological and aesthetic hows. The forest is the business why of the project in the first place. Even worse, it is not enough that when the development focuses upon technology that the business reasons for the project are forgotten. In all too many cases, the technology actively prevents the business reasons from ever being fulfilled. In the next article in this series, I will provide some examples of how focusing upon the technological aspect of Web development as opposed to the marketing side of a Web project can hurt more than help.

J.Ja

This is the second in a two part series.

In my previous blog (Web Development vs. Web Marketing), I discussed some of the ways project specifications can interfere with the business reasons for the project. Today, I will take a look at just how technical implementations, while being technical correct or acceptable, can hinder and even hurt a Web site's ability to fulfill its purpose. To illustrate, I am going to use the sample "why oriented project specification" that I laid out in the previous article. To repeat it:

* Must appeal visually to our target audience: [insert target market demographics here]
* Site must be extremely usable by our target audience, and very usable by non-target audience members
* Site must present the most useful and interesting product information up front, but allow visitors to get as much product detail as they need, to simultaneously encourages sales, as well as minimize the need for customers to contact us before making a purchase
* Site must be consistent with our corporate "look and feel" in a manner that does not compromise usability
* Site must be a secure as possible
* Site should foster a trust relationship between our company and the customers, particularly new customers
* Site must have search engine optimization baked in from Day 1

This is actually the basic skeleton for any good project specification. Note how it focuses upon why the Web site is being created in the first place: to sell products as efficiently as possible! A site that looks great and have cool widgets all over the place, but is totally unusable and baffles search engines will not make much money at all.

Must appeal visually to our target audience

I would have hoped that garish websites, graphics heavy websites, and so forth would have died with the late 90's. Sadly, this did not happen. Thanks to the broadband boom, Web designers and developers now feel free to load a Web site with 200KB worth of graphics. I guess these developers all live in major cities. Most parts of the state I live in (South Carolina) are still on dialup. Too much of the population either has no cable, or is so sparsely populated that the phone company is not going to put Cos for DSL all over the place. At best, these users are on satellite, which I have found to be unreliable and slow from my days of network management. South Carolina is not an isolated exception. Do you think that a farmer in the Midwest or someone in the Dakotas is likely to have a fast Internet connection? Even if your Web site is aimed at business users, you should keep in mind that many companies frequently under provision their offices. Most users simply do not (or should not) need to spend much time outside of the LAN, and what bandwidth there is, is frequently filled up with inter-office communications. In other words, when you have 20 users on a single T1, the bandwidth available to each user is not so much. Web sites should still be extremely lightweight, end of story.

Site must be extremely usable by our target audience, and very usable by non-target audience members

This is another pain point, on many levels. Those nifty menus that you designed may work for you, but they probably confuse a user. If they drop down automatically on a mouse hover, that is different from how desktop applications do things, and is confusing. If they need to be activated by a mouse click, you have confused your user because a mouse click in a Web site is "supposed to" (in the user's mind) take them to a new page. Even worse, did you break the user's right-click functionality, such as the ability to open the link in a new tab or window? Will the top level menu item take the user someplace useful as well, or is it just an access method for the menu? Can a screen reader read the resulting menu, so that vision impaired users can use your site? Will my mother be able to figure out your menu system? Avoid those drop down menus, they are simply a crutch for Web designers and developers who do not know how to construct a useful, usable navigation system.

AJAX is another usability breaker. It is nearly impossible for vision impaired users who use screen readers to work with. Anything requiring drag/drop or right clicking (they are acceptable if they are not the only way of using the site) is a bad move too. In fact, anything that requires any type of input other than single clicking with the left mouse button is an utterly unable system. You do not want to require your users to experiment beyond the lowest common denominator of input (single left mouse click) to use your site.

Sites that look like desktop applications are another usability disaster. You are confusing your user. Even if the whole Web went to "desktop-esque" sites tomorrow, there is still the problem of everyone having a different idea of how to make their pseudo-rich clients look and function. If you want your users to give up and walk away from your Web site, try to make it look and act like a desktop application and not a Web site. When the user opens their Web browser, they expect Web sites, not applications. That means standard form widgets and links only. That means that text or graphics that look like links should function like links, including retaining the browser's right-click functionality. That means that saving the page as an HTML file should work, and the user's copy/paste functionality should not be impaired. It means a lot of things. Keep your Web page a Web page; if you want to add additional functionality, it should be marked as such so that the users knows that they are using an application. Microsoft made this mistake with the new MapPoint web site; the site is useless and unusable now.

Site must present the most useful and interesting product information up front, but allow visitors to get as much product detail as they need, to simultaneously encourages sales, as well as minimize the need for customers to contact us before making a purchase

This one should be obvious. Many Web sites fail on this one, not due to over engineering the site, but due to under engineering. Products that only have a small thumbnail image of the product, database schemas that do not allow detailed product information, or force the information display to be so universal that products with special features do not have those features highlighted, short descriptions that are just truncated versions of the long description; these are all ways that an under engineered Web site can fail to present the right information to visitors at the right time.

Site must be consistent with our corporate "look and feel" in a manner that does not compromise usability

Frequently, Web sites try to incorporate too much of the companies non-Web branding into the site in a way which kills usability. For example, putting a Flash intro (or any kind of intro page) is a disaster. It is also a waste of time. Chances are, your users are coming from a search engine and will bypass that page anyways. What works for print and what works on screen are two entirely different things, right down to the choice of fonts. For example, Arial is more readable than Verdana in print; but Verdana is more readable than Arial on the screen. Times New Roman is even worse on the screen, while still being a great choice in print. Splitting the main text into columns is another items that works in print and fails on the screen. Sidebars, light watermark graphics under the text, "splash graphics" all over the place; these are all things that work great in print but fail on the screen. Similarly, the way your customer presents itself in television ads is not how you should be designing your Web site. TV ads are meant to get the audience's attention before they duck into the kitchen or bathroom (right down to having a higher sound volume, so they can be heard in another room). Your Web site does not need to be doing this; if it is on their screen, it does not need to gain their attention. They have already chosen to view it. And for the love of all that is good, do not force your users to watch your TV ads on the Web site.

Site must be a secure as possible

Every new feature you add to a site, if it involves sending data to the server, is a potential security hole. Too many "perpetual beta" pieces of software have security bugs. Even worse, updating third-party Web applications is usually an absolutely nightmare. In a nutshell, go ahead and use some "super cool alpha release" piece of code from SourceForge. But be prepared to sit on top of that application, checking their bug tracker, looking for updates, performing security audits, and so on. Constantly. It will be like 1997, all over again! Woo hoo! Go ahead, add an RSS aggregator to your Web site; just be prepared to take the blame when malicious code is dumped to your users (or your servers) via the feed. Use that third party survey system (which no one fills out anyways) if you want; but when a poor use of sprintf() lets some malicious user take over your server, accept the blame. Install some goofy search system, I will not be offended. But I will not have any sympathy if you chose a product that kindly offers your database information to users when it bombs out, and has a SQL injection hole in it to boot. To repeat myself, every new feature you add to a site, if it involves sending data to the server, is a potential security hole.

Security and usability also do not play nicely with each other. It can be a fine balancing act. I am indeed sympathetic to it. But when make your users have a strong password, but do not help them make it (the MSDN site has an excellent system for this, by the way; it has a little "security meter" that goes from red to green in real time, to indicate that you are meeting the requirements), then they are quite likely to give up and go to another site to make their purchase.

Even things like user comments or reviews can kill a website. All it takes is to have a poor filtering mechanism that allows someone to put in some CSS code to make your site look bad, or to be spammed, and make the system worse than useless. Captchas are not the solution either; there are plenty of tools out there to break them. If your site involves trading money for a product or service, you can be sure that someone will try to rip you off.

Site should foster a trust relationship between our company and the customers, particularly new customers

This one is pretty simple. Avoid sleazy things (like popup ads, banner ads all over the place, the awful "Ads by Gooooooogle", etc.), and your users will get the impression that you are a professional company and will be more likely to trust you. A site that spews out JavaScript errors all over the place does not foster trust. My first thought when I encounter a site with JavaScript errors is, "Wow, their programmers are incompetent. Will it be safe for me to let them have my credit card number?" Use your own ID systems, do not make the user give you their Social Security number or driver's license number unless required to do so by law. In fact, do not even ask for it. And if you are required to do so, make sure that you make that clear to the user. And when you ask for it, let the user know how it will be used, and how that data will be protected. Do not store your user's credit card numbers without asking them first (indeed, this is the law). And so on.

Site must have search engine optimization baked in from Day 1

This one is the ultimate killer. A five percent increase in traffic from organic search results is a five percent increase in sales. A site in the Top 10 of the major search engines will outsell a site on page ten of results by a disgusting amount. To put it bluntly, anything other than pure, static, standard compliant HTML is going to hurt your rankings in the search engine. Sure, your super nifty Flash application may look awesome. But how is the Marketing Director going to react when he finds out that if he wants top search engine placement, he will need to spend thousands of dollars a month on pay-per-click ads? Even worse, pay-per-click ads are not nearly as effective as organic search results; an organic search result listing is about twenty times more likely to be clicked, and around 14% of all pay-per-click page views are click fraud. Do the math. Is taking that kind of hit to your search engine ranking worth that kind of loss of search traffic? Are you hoping to make up for it by having other sites link to yours? If so, ask yourself this: how are those other sites going to find out about you in the first place, if you are not well positioned in the search engines? There is a reason why Google, Yahoo, MSN, and other sites earn billions of dollars in revenue from their ad systems. Search engines are that important.

Unless you are a site like Amazon or eBay, where everyone who is looking for what you sell is going to go to your site first, you simply cannot let technological wizardry stand in the way of your search engine rankings. A site that gets zero visitors makes no money, it is a simple equation.

What does this mean for the Web designer? It means that anything that is dynamically generated should come out as static HTML code. It means that your URLs need to be search engine friendly (which is also bookmark and email friendly too, another usability item). It means using CSS responsibly, to separate presentation from content. It means properly marking up your code, particularly with the header tags, strong and emphasis, etc. so that the search engines know what each page is about. It means providing ALT tags on your images (good for screen readers, too). As a shortcut, try out your site in Lynx or use a screen reader on it. If the site works great in those environments, the search engines will love it.

It is a great thing that as your site's usability improves, so does its search engine rankings. Search engine spiders are essential dumb users with technologically backwards browsers and a dozen different physical handicaps. They cannot right click, they cannot run JavaScript, they cannot drag/drop, they cannot use Flash, they cannot use AJAX, they cannot follow JavaScript links, and so on. To have any of your site accessible solely through any of these methods not only hurts your usability, but it kills your search engine rankings.

I designed a site about eight years ago that has been in Google's Top 10 for its keywords (very generic terms). It is pure static HTML. We recently redesigned the site, the customer told me one thing: "whatever you do, make sure that it does not hurt the Google rankings. I don't care what kind of features we might not use, just use the same techniques you used last time, and I am happy." I would say that this is a pretty strong endorsement of my techniques. At the end of the day, that customer is spending pennies on pay-per-click advertising (he likes to appear twice on the search engines!), while his competitors are spending a fortune. Users tell him that they like his site because it is to the point and easy to use. He likes the site because updates are easy to make. All of these benefits came from eschewing fancy programming for plain, static, boring HTML. And it was easier too!

So, before you write a single line of code on your next Web site project, ask yourself: does this code address why I am working on this project? Or am I just following the current trend, or having how I do this be dictated to me with no business purpose behind it? Otherwise you may find out that you met all of the project specifications, and have an extremely unhappy customer as a result. Remember, you are the expert on these things, not the customer. They may have some idea of what they want, but at the end of the day, you are supposed to know how to build a Web site. To let a customer make these kinds of decisions without you letting them know what the ramifications of those decisions is simply irresponsible, and your customer will appreciate you more if you work with them to make the best Web site for their business.

J.Ja

Check out this introduction article on Technical communication:
http://www.articleworld.org/Technical_communication
Content:
1.Professions
2.Formats
3.Tools
4.Resources

You're right, if my business model  was based entirely on using Google free maps API that would be foolish, but you need to ask yourself what's the alternative.  If you have a localized mapping system ok maybe you could buy the maps and the satellite images and host them youself at an extremely high bandwidth cost, not counting the high cost typically associated with any sort of quality up to date digital map.

Now let's say you want some sort of nationwide mapping system, the server space, cost of maps, and bandwidth that would be required would be unbelievable, all for a yet undeveloped application that may not even gain traction with consumers.

What Google Map Mashups allow you to do is beta test you app with real maps on real servers and see what happens.  You can see if people like your mashup that shows you bars within 1 mile of hospitals, or houses outside police coverage areas.

If it works then you can build your own infrastructure, or since Google really is just in it for the money, work out some kind of licensing or revenue sharing idea.

I am going to say something that will not surprise my regular readers: I am not a fan of rapid application development, agile programming techniques, "test in production," perpetual betas, the continuous patch cycle, and other current programming trends. I am not the only one, either. I think that this paradigm of programming is incredibly broken. I am of the opinion that patches should be rare, not because the developer should not fix bugs, but because bugs should be rare. I wholeheartedly support only a few minor version releases, and long cycles between major releases.

I also am fully aware that "this is not how things are done."

The current business environment is all about "now, now, NOW!" As a result, we have become accustomed to getting software that is slow, buggy, and insecure from Day 1, and (hopefully) slowly improves through its lifetime. Our best case scenario is software that is only mildly broken, but usable, and it eventually morphs into what it should be. The worst case scenario is a system that as it evolves and new features are added and existing features are fixed, backwards compatibility is damaged, security holes allow sensitive data to be stolen or maliciously modified, and users become frustrated and angry.

Right now, the development cycle is predicated on the first mover principle: get a product, regardless of quality, out the door, dazzle users with the feature set, and hope they stick around long enough for the problems to be fixed. Sadly, what ends up happening is that another competitor invariably pops up, so instead of fixing the existing bugs, new features are cranked out in an effort to keep the existing user base and maintain growth. The new features are buggy too, the old features become buried, and the code gets crustier and kludgier until it is a warm pile of compost. Eventually, the only way to fix the problems is a complete tear down and rebuild.

At the end of the day, I have a responsibility to my customers. That responsibility is to solve the why of their business process, whether it is selling products online, properly determining their sales, marking hazardous shipments in accordance to federal law, or whatever. The why is not "join the latest technical revolution" or "support a favorite software vendor" or "make decisions based upon my emotional reactions to certain things." Usability, reliability and security must always be primary in my development process. Unusable software does not get used, or is used incorrectly, which means that the why is not being accomplished. Unreliable software loses data, wastes the users' time, and often makes the users afraid to do anything (we have all used an application where we knew that certain operations would crash it out, so we ignored those features). Insecure software can destroy my user's business, and the resulting lawsuits can put my employers out of business as well.

Microsoft did exactly all of this for over twenty years: they put the development of new features ahead of perfecting existing features and producing reliable, secure code. It actually worked for them too. They achieved market domination. The end result though, was hundreds of millions of computers having severe vulnerabilities. Many of the features that helped Microsoft achieve business success (Office macros, IIS/ASP, ActiveX, and more) had holes in them so big you could drive a Mack truck through them. Microsoft has been the butt of endless jokes as a result. In response, Microsoft ceased development on a large numbers of new features to concentrate on fixing code, and has had to completely reengineer their development process to put reliability and security at the forefront of their efforts.

What I find most interesting, is that this is exactly the path every other developer seems to be going down now! The "Web 2.0" crowd especially, but OSS is headed towards this direction as well. One project I keep an eye on has not released a production release in years, that I am aware of, but keeps cranking out "alpha" and "beta" releases. There never seems to be any actual final, production release of any version, but they run both minor and major versions through "beta" constantly. Google seems to have 75% of its products in "beta" at any given time, some of them on the market for years. What I hear in many comments and discussions is that "we need to make the best of what we have today." No, we really do not. We need to write the best code possible today.

Here is an example of what I mean: today, I made hotel reservations with a Hyatt hotel on their Web site. I went back to change my reservation, because I had made a minor mistake in the days. Their reservation lookup form allows me to enter the credit card number to look up my information if I do not have my credit card handy. Except there is one huge flaw: it does not use HTTPS! So not only is my credit card number being sent in plain text (along with my first and last name), but it is going to be stored in my browser's auto-fill system in plain text! This is a failure on every level. All because someone did not think about what they were doing when they wrote code and no one gave their code a second review. All in the name of rolling out a feature to help the user. I am sorry, but I would have preferred to have to call customer support or find my confirmation number than to give out my credit card number over a plain text connection and have it stored in my browser.

I find this very ironic. Just as Microsoft works to tighten down the screws as hard as they can, without breaking Windows' backwards compatibility (and other features which help make it unreliable and insecure), Java starts growing its sandbox, developers begin to advocate putting out buggy releases and fixing them later, and the rest of the world in general transitions to releasing code quickly without proper review and testing.

George Ou has discovered that that tens of thousands of defaced web sites had something in common: most of them had a common hosting solution, and the hack appears to have occurred through sloppy ASP code. Worst of all, the suspected security hole was known since April, 2005. Let me repeat that for extra clarity. A bad programmer possibly wrote bad code that was known to be bad for about fourteen full months without being fixed, leading to a massive security breach and thousands of defaced Web sites. If I were that developer I would be writing my will right now, buying cans of baked beans by the crate and making plans to hide in the mountains for the next century. If I were the company that employed this programmer, I would be calling John Edwards and asking him to contact the spirit of Johnnie Cochran for legal advice. It is that serious. Talk about negligence of a criminal nature! This is why I am such a hard case about these things. Do you want to be the systems administrator who did not patch the managed code environment that was known to be buggy, allowing hackers to destroy your business? Do you want to be the CIO of a company that outsourced their development to a third party vendor with no internal review of the code, allowing a bug to linger for years that caused millions of dollars to be redirected to some bank in the Bahamas? Do you want to be the programmer who did a copy/paste on some code from some website that contained a buffer overrun exploit, giving hackers root on your servers?

Look at the why of some projects I have worked on: "selling products online, properly determining their sales, marking hazardous shipments in accordance to federal law." Imagine what happens if I write buggy code for any of these projects. Credit card numbers could be stolen. A federal investigation could be launched into the company's violation of SOX, or the incorrect payouts of millions of dollars in bonuses and other incentive compensation could occur. The company's transportation network could be shut down by the federal government while they audit the HAZMAT controls. The code I write must be bug free. The lives of real people and millions of dollars are on the line.

A short essay written by Professor Kurt Wiesenfeld entitled It Was a Rookie Error is something that I read during college, and I keep the ideas from this essay in mind whenever I write code. When programmers write bad code, people can die, companies can collapse, millions of dollars can disappear, or lives can be ruined. If this sounds overly dramatic, think again. Sure, you may only be working on a small personal Web site today. But if your small personal Web site gives root to a hacker, someone else's Web site that may be much more sensitive could be compromised. You may just be writing a "quick and dirty" script, but "quick and dirty" code tends to linger forever and have real systems built on top of it. Your small driver for an obscure device may end up in a system for air traffic control; if it crashes the OS, people die.

So the next time you think about releasing untested code, or code with known bugs for the sake of getting new feature in the face of users, think again. "Good enough" is never good enough in the real of real IT.

J.Ja