Critical Thinking

Interesting to read some of the comments within the thread of the
blogs. Everyone seems to be in agreement that proper requirements and
immediate access to the user are the keys to successfully generate
requirements and hence complete the work accurately and as expected.
Lets level set the discussion with the over-simplified statement above.

I've also read about processes and analogies regarding the proper
delegation of responsibilities (ie. doctors and builders) to properly
execute on projects; yet I've not heard from the development community
one comment on properly delegating the tasks to the appropriate
skill-sets. Introducing and utilizing other development resources
(multi-disciplinary approach) to be responsible for defining,
understanding and generating the 'users' requirements.

I've practiced XP/Agile/MSF/IPD/Chrystal/UCD/PMP/et al, I'm a PM with
an analyst background and I've never started a successful project
without the appropriate resources and skill-sets. What I'm talking
about is a multi-disciplinary approach. I delegate the requirements
realization to not only a lead developer but also a User Experience
Designer. This individual has a usability background, is a visual
designer and an information architect. You're worried about taking what
the user says as what the real requirements are? These are the people
with the skills to do the proper 'shadowing' and interviewing
techniques/observations/questions that will realize the true tasks,
activities and translate them into accurate requirements that are
represented within the interfaces. They will even perform quick
usability studies to validate the designs prior to development's
implementation. This provides enough time for the development group to
absorb the business requirements to tranlate them into technical
requirements, execute on low-level system designs, proof of concepts
and anything else required to make the technology work best.

Maybe I've been lucky in that I've had very little difficutly in
selling this to a client or organization, everyone from stakeholders to
the project team can understand and accept the approach, but I've found
this to be one of the most effective methods for interfacing with
users. Developers should not be attempting this alone, they will
already have too much on their minds to effectively provide this
service. You would never expect the developers to write end user
documentation, why would you expect them to go it alone to realize the
requirements?

The industry has to realize that in order for projects to succeed we
need the appropriate skills represented to provide the level of
competence and expertise to succeed. In order to do this we need to
educate ourselves and to introduce other possiblities that broaden just
the 'development' world, with methods that work and that don't work.
Hopefully this helps someone.

I've linked to this weblog entry from off-site, in a weblog entry titled users as programmers. If you read it, I'm sure you'll quickly grasp why I linked it, but in short, I was inspired in part by this entry to write about programmers who develop applications for their own use, as opposed to those who do so only to satisfy project specs handed down from on high.

In any case, I thought you might want to be made aware of the referral.

I Share Your Frustration 

I would diagnose the problem as being session timeout more than anything.  This has always been a major problem with every web based application that I have seen.  Neither the server nor the web client is aware of user activity.  I have seen numerous kldges implemented just so that a user can spend a reasonable amount of entering a thought.

I also remember the telnet days when getting a 9600 Baud modem meant life was good.  VT100 encode screens displayed and updated faster than HTML even over a LAN connection.  If we advance any further, I think I'll revert to faxes.

Any way, I tend to avoid posting anything in these blogs unless I really, really want to enter it.  I have also given up when my first attempt fails, usually indicated by a long period of no action.  The only trick I have found is to copy the text box (Windows trick) before I submit, kill the browser when the submit fails, relogin and paste and post.  Thanks for letting me vent as well.

So (no surprise here), Google is ramping up to start monetizing their map system.

There are a lot of companies and people pushing this "Web 2.0" idea. Never mind the fact that none of them seem to be able to define it (is it AJAX? is it cross-site use of APIs? is it simply a deep version of hot linking? does it involve lots of words that sound vaguely like English? does it involve another stock bubble?). Phil Wainewright over at ZDNet goes even further; he talks about "Web 3.0" (when companies learn to monetize the undefined "Web 2.0"). If he's right, than Google is leading the charge to Web 3.0.

People like Dave Berlind push the idea that the Internet rocks, because anyone can start a new business using a "mashup". Yes, it is true that you can put together a very interesting website, maybe even a complete application as a "mashup". You might even be able to monetize it. But to think that you are going to build a system for free out of other people's data is insane. Imagine if each time you booted up a RedHat Linux system, your computer took up a bunch of RedHat's bandwidth. Eventually, they are going to need you to pay for that bandwidth, whether it be by direct payment, or through advertising dollars.

This is the problem with "mashups". People are using a free service to try togenerate revenue. How long do you think that service will be provided to you and your customers at no cost and with no ads? And when the ads come, do you want the ads that seem to appear on your site to be under the editorial control of a different company? Let's say that you are running a religious website, and you have a map showing the location for a sermon about "Removing Lust from your Heart". Google graciously puts the locations of the nearest adult novelty shops within a 50 mile radius of your church on the map. Just what your visitors wanted, I'm sure.

Call me silly, call me crazy, but I would laugh if I were a venture capitalist or investment banker and heard a pitch that relied upon a third party keeping their service free and ad-free. I would say, "look pal, you're being set up, the moment a critical mass of companies rely upon that third party, the third party will tell you 'give us money or get stuck with ads', you're doing business with unknown costs, and you think I'm going to give you money?" And anyone who starts a business involving actual money on a "mashup" is a fool, or naive, or worse. Thanks, but I'd rather pay up front, and know what my costs are for the data, and be able to use it my own way.

Don't get me wrong, "mashups" can be neat, they can be cool, but I would never in a million years consider using one as a business or as a tool for my business. Personal site? Sure. Non commercial/non profit site? Sure. Business? No way.

J.Ja

Lately, the idea of "How" software works as opposed to "Why" users use software has been on my mind (https://www.techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1983228&id=2926438). Anyone who thinks that Web-based apps should take over the world is being naive at best. Web-based apps virtually never address the "why" that users use computers. How is having an application Web-based going to increase the user's satisfaction or their productivity in the slightest? I can think of dozens of reasons why Web-based apps are more frustrating, less easy to use, less functional, and less productive than a desktop app. I cannot think of any pain points that a Web-based application relieves for 99% of the applications out there.

Why would I even want to bother with a central, Web-based repository for my documents like this? The free 64 MB USB thumb drive that one of my customers gave me stores enough for 99.9% of users to put every document they will ever need on, and nearly every computer on the planet can open and edit an Office document, whether it be Microsoft Office, Open Office, etc.

In addition, what third party vendor do I trust with a sensitive business document, to the point where I'm going to permanently leave my data on their servers? Umm... none. If I have a VPN on my network at work (and nearly every corporate network does now), the problem is solved right there. At the worst, I can call someone and have them email me the document, or I can VPN into my network and open a Remote Desktop session to my desktop PC.

I have never heard a user state their needs as "I need to do XYZ through a web browser." I have heard "I need to be able to do XYZ from any computer I might find myself sitting at", but if I wrote a well written application that did not need to use an installer, and is small enough to fit on a USB thumb drive, I have accomplished that exact same goal without having to even involve a network! [Addendum 4/3/2006: sMoRTy71 points out (correctly) that USB drives aren't perfect solutions. This is an example of ways to not have to write a full Web-based app; another alternative would be to offer this same software (no installer needed binary) as a download. The point is, there is zero reason to write a Web-based version of an existing desktop application.]

These vendors of Web-based applications are not listening to their users, or even trying to put themselves in the shoes of their users. They are listening to the self congratulatory babblings of venture capitalists, Well Street investment bankers, techno-nerds for whom technology exists for the sake of technology, and so on and so on. Technology is a lever, nothing more, nothing less. If that leverage is not being applied to solve the problems the user has, it is a waste.

Every obstacle that you put in the user's path hurts their productivity. Making an application depend not just upon a local application, but having a constant Internet connection, the uptime of a third party's webserver, the performance of said server, and the end user having a PC that meets the requirements (including web browser configuration, a HUGE "if") just throws more obstacles in the user's path while giving them a second rate application that will ALWAYS be slower than native code looking at data on the LAN. This is "progress"?

This is the Object Oriented Programming Model gone to a hideous extreme. Let's just abstract everything, stick half the parts somewhere else, stop caring what is actually happening on the backend, and call it a day. I categorically reject this mode of thought. It does not help the user one bit. It just creates a nightmare for me (the developer), the user, and the people trying to keep the network locked down. Everyone a Web-based app touches is made unhappy.

Think ?mashups? are so hot? The real question is "if someone made this data store available to me on my local network, would my users be best served by having a ?mashup?, or something running locally?" The answer is almost always "a desktop application built to order". Software development isn't about "cool". It isn't about "nifty". It isn't about what language you are using, or whether or not you are coding to spec, or whether or not you followed "eXtreme Programming" or "Agile Programmer" or "Ten Thousand Monkeys with Ten Thousand Compilers Programming", it's about meeting the needs of the users. To think anything else is a bad case of "developer hubris" and even worse is a waste of your employer?s money and your user's time.

Web-based applications, except for rare occasions, does not address the user's needs, it strokes the egos of those involved with the development process. Google's ego is swollen to the size of a small country. They think because their fanboy base is so big, and because so many tech writers adore them (c'mon ZDNet, how many "Google Watch" type blogs do you need? Where is the "MySQL Watch" or "Oracle Watch" or "IBM Watch"?) that they are actually any good. The truth is, their software is in perpetual beta and exists merely for the sake of suckering people in to develop a critical mass of users, so Google can then plaster ads all over it.

Do you really want Google's servers indexing your critical business documents and injecting their ads throughout them? When you give a map to your church's special sermon about "Removing Lust from your Life", do you want ads for every adult novelty shop appearing on that map (https://www.techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1987268&id=2926438)? When you send an email to your therapist about tomorrow's appointment, do you want your browser showing giant ads to help you find a website for treating whatever it is that you're in therapy for?

I have yet to see functionality in a Web-based application that could not (and usually does) exist in a desktop application. Everyone is going ga-ga over ?mashups? involving Google Maps. I hate to share a little secret, but Microsoft has offered this functionality through MapPoint for years to desktop users as a simple-to-program ActiveX/COM object. The only thing that using Google Maps over MapPoint gets me is that it is free. Yes, that may be a big deal for many many people, but Google does not give anything away for ?free?. What they mean by ?free? is ?you pay us with your users? attention and gestures?. Do you want your users leaving your application or being distracted by Google?s ads? Neither do I. I am honestly surprised that Steve Gillmor (who understands ?attention? and ?gestures? better than anyone else) would support a mechanism where the attention and gestures are going to a third party in a process than actually subtracts value from your application.

Most users are fed up and frustrated with their existing desktop applications, which is why people are looking for a solution. The solution isn?t to start moving everything to the Web by simply replicating the existing, crummy apps with AJAX, but for programmers to change their mindset when writing code. Web-based, desktop, thin client, it?s all the same lousy software if the developers aren?t addressing their users? needs.

J.Ja

Want to see who's next On the Soapbox? Find out in the Blog Roundup newsletter. Use this link to automatically subscribe and have it delivered directly to your Inbox every Wednesday. http://nl.com.com/MiniFormHandler?brand=techrepublic&list_id=e131

All too often, I read a tech writer who seems to think that a Linux (or some other OS) that takes up a small amount of disk space is a "micro kernel." This is patently absurd. These are micro distributions. Most Linux and BSD based operating systems already have an extremely small kernel, small enough to fit on a floppy disk along with enough configuration files and utilities to get a system up and running and perform a restore.

If you compare these "micro kernel" OS?s like Damn Small Linux and PuppyLinux to a full blown Linux distribution like RedHat or SuSE, what you will see is that they really are no different. In fact, they are usually just a stripped down version of those "fat" OS?s! All that they have done is remove every piece of code that the distribution makers view as "unnecessary".

Indeed, you should be able to take the rc.d and other configuration files from one of these "micro distributions" and put it onto RHEL or SuSE or Mandrake or whatever, and have that OS run in an identical memory and CPU footprint as the "micro distribution."

At the end of the day, a "fat" OS is only "fat" by virtue of how much disk space it consumes. Most of these "fat" OS?s are simply loaded down with fifteen different open source versions of the same type of application. This is where we see RHEL or SuSE have more lines of code than Windows. Windows ships with one web browser, one media player, one basic text editor, etc. whereas a *Nix will ship with five different applications for each task and let you choose which one you prefer.

I have tried working with these "micro distributions" and to be honest, it is a pretty miserable experience. I have tried Damn Small Linux as well as PuppyLinux. It was extremely frustrating to not be able to install any software that was not available as a binary package through the system?s installer, simply because there was no compiler available. *Nix without a compiler is like having a car without a steering wheel. PuppyLinux did have a Perl package, but it was missing most (if not all) of the standard Perl libraries, rendering it useless to most programs (and without a make command and/or CPAN, very difficult to add new packages) that need it. PuppyLinux did not have cron (the standard *Nix task scheduler) so it was difficult to see it being used as the basis for any serious server application.

Anyone who thinks that these "micro distributions" are going to make a huge different has not actually tried doing anything with them that are trivial tasks on a "fat" *Nix. As stated before, the only difference is how much disk space they take up. If an extra gigabyte of disk space is going to make that much of a difference to you, you are in trouble anyways. And if you think that these "micro distributions" are going to help you reduce system resource requirements, you are wrong there too. Sure, many of them are compiled with a 586 or even a 486 target in mind, but at the end of the day, all *Nix distributions are pulling their kernel from the same place (within families, of course).

J.Ja

Writing code is a goal oriented process. Unfortunately, the tools that developers have do not assist them in attaining their goals. The tools are getting better, (as someone who has had to write COBOL in vi, I can attest to that), but they still do not understand just how programmer operate. The development tools themselves are still how oriented, not why oriented. Let us take a look at how the code writing process hinders rather than helps developers.

The documentation is predicated on the user knowing what they are looking for.

This is only improving, because the IDEs have glued ToolTips, AutoComplete, etc. into the editors. Coding now is a process of naming your variable, pressing the period, and then scrolling through the list of methods and properties to find what sounds like it does what you want.

But try starting off from a state in which you do not know what objects you need. In other words, try something you have never done before. You are in deep trouble. Language and API documentation is still dominated by how and not why. It assumes you know what object class (or variable type, or function, or whatever) you need, and then shows you what your options are. This is required information, but it is not very helpful, especially if you are not familiar with that language's terminology (or that library's terminology). It is so easy to not find what you are looking for, if the language has standardized .ToString() for everything, but what you are working with has .ToText() instead. More to the point, there needs to be more documentation like the Perl FAQs: goal oriented documentation.

The Perl FAQs are perfect. There are hundreds of "I am trying to do XYZ" items in there, and code that shows you exactly how to do it. The documentation asks the user, "what is your why and how can I help you accomplish that?" I use the Perl FAQs more than the actual reference most of the time; I already know the language syntax, but there are a lot of whys that I have not tried to do. Indeed, the Perl documentation contains so much usable code in a goal oriented layout that it is possible to write 75% of a program out of them. Just try that with Whatever Language In a Nutshell. I have only seen one programming book laid out in a "let us accomplish something" format as opposed to a "here is how we work with strings, here is how we work with numbers" format.

The tools are too focused on writing code.

I know that this is counter-intuitive. IDEs all about code, right? Well, not really. Writing code is the how. The true why is "creating great software." Writing code is simply an ends to that means. The reality is that too many pieces of software simply stink, not because the internal logic is no good, but because the programmer left out things like error handling, input validation, etc. out of sheer laziness or ignorance. An IDE that lets you try doing an implicit conversion when you have strict on with a strongly typed language is doing you no favors, especially if that block of code is somewhere that it only gets accessed once in a blue moon. A language or IDE that makes input validation "too much hassle to bother with" is not doing anyone any favors.

Here is a great example: too many web applications rely upon a combination of JavaScript and the maximum length specification in a form object to do their validation. Unfortunately, not everyone has JavaScript turned on, and many people use some type of auto complete software to fill out a form. And someone can always link to your application backend without replicating your interface. So no matter how much input validation you do on the client side (not saying you should skip it; users typically prefer getting the error before the form is actually submitted to a server), you still need to do it on the backend. Sadly, the concept of tying the input validation logic on the server side to the input validation on the client side is still pretty rare (ASP.Net with its Validator controls is good, but not great). So you end up with code that either is a hassle for the end user (no JavaScript validation) or vulnerable to all sorts of nasty things to occur (no client side validation), or you are forced to write all of your validation code twice, in two different languages.

This is all a by product of the sheer amount of effort that is needed to write this code. It is not brain work, it is drudge work. A well written program with a large amount of user interaction but little complex logic behind it, in a language with large libraries, can be 25% input validation. Let's be real, most applications are of the form "get data from a data source, display it to the user, allow the user some C/R/U/D functionality, and confirm to the user that the procedure was a success or failure." That is all most programs are. A significant portion of security breaches are caused by failure to validate input. For example, Perl has a known buffer overrun problem with using sprintf. "Everyone knows" that you need to validate user input before passing it to sprintf, to ensure that it will not cause a problem. And either through laziness or ignorance (note how I put "everyone knows" in quotation marks), this does not happen, so you get a web app that can execute arbitrary code. The WME exploit, zlib problems, et al all boil down to a failure to validate input.

Imagine if instead, the IDE (or the language itself), instead of being aimed at providing you with fancy indentation and color coding and what not, actually did this on its own? Perl does this to an extent with variable tainting; it will not let you pass a variable that came from the user with certain functions until you touch it first with other functions. More languages need a mechanism like this. But it is not enough. The idea that user input is always clean needs to be erased from the language and the tools, and replaced with a system that encourages good coding practice, through compiler warnings, and even better yet, handling it for you. Imagine if your language saw you taking the contents of a text input and converting it to an integer input, and had the good sense to automatically check it at the moment of input to ensure that it would convert cleanly? That would be a lot better than it is now; trying the conversion, catching an exception, and throwing an error back. This lets the programmer focus on the why, in this case, getting numeric input from the user.

Program logic is a tree, but source code is linear

This is a problem that I did not even see until very recently. Very few programs are written procedurally at this point. The event driven programming model has taken over, and for good reason. Unfortunately, our entire source code creation process is derived from the procedural days. Look at some source code. What you see is that you have a bunch of units of code, all equal to each other. Even when working with object oriented languages, the tools themselves treat the code writing process as a linear, procedural system. You write an object; within that object, all method are equal within the code. Navigating the code is tricky at best.

Even with an IDE that collapses regions, functions, properties, etc., when the code is expanded, it is still a plain text file. The way we have to write overloads is ridiculous. The whole process itself is still stuck in the procedural world, but we are writing for event driven logic. The tools simply do not understand the idea that some blocks of code are inherently derivatives or reliant upon other blocks of code. Too much code serves the purpose of meta data to the rest of the code (such as comments, error handling, function parameters, and more). It does not have to be like this, but it will require a major shift in thinking, both by the people who create the tools, and the people who use them.

Code writing is too separate from the rest of the process

Right now, the tools for completing a software project are loosely integrated at best. Even with the major tool suites, the tools within the suite are not all best of breed, and the better products just do not integrate well into the suite. For example, it would be pretty painful to write a VB.Net Windows desktop application in anything but Visual Studio. Even a simple ASP.Net application would be a hassle to work with outside of Visual Sudio. Sadly, Visual Studio's graphics tools are crude at best. Its database tools are not so hot either, especially for database servers that do not come from Microsoft. Adobe/Macromedia makes excellent graphics editors. But Photoshop, Illustrator, etc. simply do not acknowledge that Visual Studio exists. So the tools that the person making the graphics is using (Photoshop, Illustrator, Freehand, Flash, and so on) have zero awareness of Visual Studio, and vice versa. The graphics person has to do his work and then pass it to the programmer and the GUI person so they can see how it fits.

Microsoft is trying to address this problem with the upcoming Expression system, but I am not holding my breath. I will believe it when I see it. This creates a problem where the graphics artist does not realize that their vision cannot be implemented within the code. The systems architects have a hard time seeing that their detailed database layout is nearly impossible to turn into a usable interface. The project manager does not get an idea of just what is needed to make the workflow go smoother. And so on and so on.

It is great that the tool makers have brought testing and version control into the process. This helps tremendously. But these tools still are not perfect, and could use a lot of improvement, particularly version control. At this point, version control is still a glorified document check in/checkout system with a hook into a difference engine. It has no awareness of the program itself and it is still very difficult for multiple people to simultaneously work on the same section of code. Even then, as one person makes changes that affect others, the version control system is not doing much to help the team out. I worked at a place that used CVS; the system was so complicated that we barely used it. For what little it did, it was not worth the effort. Version control, even in a single developer environment, is a major pain point. I have some ideas on how to improve this, but this is not the time to discuss them.

The situation is not as bleak as I paint it

I know, I make it look like it is a wonder that programs get written at all. It is not quite so bad as that. But I think that it is time that the tools that we use to create software evolve to meet the why of the code writing process, as opposed to making the how easier. There are a lot of great things about the current tools, and I would not go back to vi and command line debuggers for any amount of money. But I also think that the tools that we have need to make a clean break from their past, and help us out in ways that they simply are not doing at this point in time.

J.Ja

This person likely has never worked with a SQL Server of any kind before. Pasting data into a table is easier than creating the table to begin with.

But even the most experienced database programmer would try a small sampling of data prior to trying to paste 27,000 rows.

I find it interesting that people are touting the benefits of open source for someone who does not know what he is doing to begin with.

When looking at the poster's profile he insuates he is a programmer. I know if his resume ever crosses my desk I will not be hiring him.

A recent TechRepublic discussion focused upon the idea of anticipation in program design. I answered that the designer should not try to anticipate the limit of the user's needs, and that the software should try to anticipate the user's actions. What exactly does this mean, and how does it relate to my recent theme regarding how and why?

Regular readers will be aware that I advocate the idea of the software developer viewing a project as a method of fulfilling the user's ultimate goals, not necessarily writing the software that the user originally had in mind when they requested the software. Look at the common spreadsheet. It started as a means of replicating what accountants, bookkeepers, and other number crunchers were doing with ledger books. Now it gets used not just for that purpose, but as a quick, easy to use, lightweight database. If the developers of software had it designed so that all it could do was perform basic numerical computations on columns of numbers, it would not be very useful at all. It would have fulfilled the original design request (replicate with software what was done with ledger books), but would not have met the true why. The real why was "we need to be able to put data into a Cartesian coordinate system and perform operations upon that data." As users push spreadsheets beyond their intended purposes, the software developers add in functionality to address the new uses, which allows even further innovation by the users.

This is one reason why I am such a big fan of interpreted programming languages. Interpreted languages allow the developer and the user to quickly expand functionality beyond the original specifications in ways that were never imagined. A piece of software that exposes its functionality to a macro or scripting language (always an interpreted language) is always more useful than a program that is compiled with whatever functionality the developer put in and is unable to do anything else without talking to the developer. This is not to say, of course, that all software should be written in interpreted languages, of course, but that they should support the use of an interpreted language within the software itself. Providing the user with a simple macro language within your application directly addresses the idea of not anticipating the limits of your users' needs.

One reason that HTML and HTTP are abused as application platforms is because the interpreted nature of many of the application servers (Perl, PHP, ASP, JSP), as well as HTML and JavaScript itself lead to instant results. It takes a small amount of time to crank out a pretty interface, only a little longer to get some sort of dynamic functionality going on, and everyone is happy until the trudge work of actually writing a quality application sets in. This is partly why VB got such a bad rap for so long; someone with little to no experience could spend a day making an interface through drag/drop, and then power it with totally garbage code on the backend. Before VB, Delphi, etc., you had to spend quite some time and know the Windows API fairly well just to get a basic window on the screen.

Especially when working with an interpreted language, it is extremely easy to separate the business logic from the presentation logic, even in a desktop application. I discussed a potential project today with my boss. As we analyzed the user's why (one user program), one thing that jumped out was that the user would want to have us make wide scale changes to the business logic as their needs changed, and that providing them with an entirely new installation with each change was going to be unrealistic to do. The solution that we are going to propose? The application itself will be written in VB.Net, but all it will do is pull data from the database and expose core functionality to a Perl interpreter that will eval() the contents of an encrypted file. The end result? Business logic can be edited and altered without requiring a full recompile/installation, and users with minimal programming skills should be able to make minor changes themselves. That is handing power to the user. They do not want to call us for every minor change, and we do not want to support them for every minor change.

Especially when developing software that will be used by a wide and diverse set of users, it is vital that the developer not attempt to anticipate the limit of the users' needs. Indeed, it is equally important when software is aimed at a very small, specialized set of users. The "large audience" software such as graphics editors, office suites, Web browsers, email applications, etc. can be used by so many diverse sets of people, that it is impossible for the developer to conceive of every possible way to use them. For the "small audience" program, the users tend to be extremely specialized and have their own particular way of working; what may be perfect for one user will be absolutely worthless to another user.

On the other hand, the application itself should respond to what the user is doing, and anticipate their needs. This is, in many ways, a matter of interface design. A piece of software that responds to a user's attention and gestures the moment it recognizes a unique pattern is one that will be more useful than one that doesn't. Photoshop, for example, shows not just a thumbnail preview of what the changes will look like as you adjust the values of the tool you are using, but also shows the picture itself changing. This saves a lot of time; instead of adjusting the values, clicking "OK," then having to undo the change and try again, you know if the results are going to be what you want before you even click "OK." It would be great if Office suite software did them same; mouse over the "Bold" button? Make the selected text bold while the mouse is over the button, and un-bold it when they stop hovering over bold. That will let the user see if bold is really what they want before they commit to it.

Prefetching data is another great way that software can anticipate user's needs and deliver extra value in the process. If the user is paging through a large data set, go ahead and start loading the next page's data in the background (resources and bandwidth permitting of course, no one likes an application that makes a computer slow when you aren't doing anything). The user will see instant results when they click to the next page, instead of waiting for the results. This is one reason why Web-based applications have much less potential than desktop applications; their mechanisms for caching stink, even when using AJAX methods.

Even the programming tools we need fail to anticipate. Developer's tools are unique; they are written by the very people who are the intended audience. Yet, they fall very short in terms of anticipation. Version control is especially bad at this; it does not let you know that another person changed code that your code relies upon in a way that breaks your code until you refresh your code. It also does not notify that person that they are about to break your code. This is a situation which causes a lot of problems.

I love the idea of code that anticipates the user's needs. This is one direction that I see Steve Gillmor headed in with the Gesture Bank. If developers can access an aggregated source of user's attention and gestures, they can write software that reacts as soon as the user begins to take action, not when they finalize the action. Really smart developers will have the software develop that knowledge on the fly on an individual basis. And that will let the user focus on why they are using your software, and not how they are using your software.

J.Ja

I am currently attending a "webinar" presented by MySQL and Spike Source (both are companies making money on open source). The "webinar" is about using open source Content Management Systems. The joke is that the "webinar" is being presented over Microsoft Office Live Meeting. I guess they are not yet ready to put their money where their mouth is...

J.Ja

As I have said in the past, the dual boot story on Macs just is simply not very compelling.

There is tons of buzz out there about Boot Camp. A lot of people are saying that this is the best thing for Apple since OSX. Others are saying that this is the worst thing for Apple since the Newton. Personally, I think this is a non-story.

Dual booting simply is not very useful! Both Mac OSX and Windows XP tie an extraordinary amount of their functionality to the file system. To dual boot, and have your data be usable on both platforms would mean that you are going to be putting your data on a monster FAT32 partition, and giving up the advantages of NTFS for the Windows XP installation, and HFC+ for the Mac OSX installation.

Furthermore, dual booting is a huge pain in the butt. Do you really want to interrupt your workflow, shut everything down, reboot, wait until that special moment to hold a button (to tell it to boot to the alternate OS), and re-login, just to start one application? Neither do I.

The one thing I see as being a Good Thing with Boot Camp would be to have a small XP partition used for gaming. This would finally allow someone to own a Mac and actually play a game. Not only that, but when starting a game, it is common practice to shut down every possible application in order to provide the game with the maximum possible system resources. Not many people multitask with a game either. The idea of giving Mac OSX the ability to play Windows XP games is a good one, as this is a major reason why many people will not go with a Mac.

On the other hand, do you really want to spend $100 on a Windows XP license just to play games? It is one thing to spend $100 on a piece of hardware to make your gaming experience better. It is another thing entirely to spend $100 to gain the ability to play games on a hardware platform that pound for pound is already significantly more expensive than a Windows PC to begin with. I can put together a decent gaming PC for around $800. That is only a tad bit more expensive than the cost of a Mac mini. And a Mac mini, even with the new Intel infrastructure, is hardly a gaming machine. Its graphics capabilities are not outstanding, its sound capabilities are not outstanding, it is only 1 GB of RAM for that price, and so on and so on. If you are talking about taking the Intel version of a PowerMac and playing a game on it, fine. But for the price of a PowerMac, you could be putting together The Ultimate Gaming PC (assuming you are not being stupid and convincing yourself that you need 500 watts of power supply to drive your computer). And even then, you would probably be better served by buying a Mac mini, a decent gaming PC, and a KVM switch.

Unless someone has a lot of money to burn in the quest to play Windows XP games on a Mac, there really is no reason to be dual booting into Windows XP from Mac OSX anyways. When the Mac mini first appeared, I investigated the possibility of switch to the Mac platform for my day-to-computing. What I discovered was that every single application I used my Windows XP computer for either had a Macintosh version, or an equivalent that is just as good. The only reason why I have not made the switch yet is for financial reasons. My at-home computer usage simply is not very complex or dependent upon a PC-only application. Indeed, with Mac OSX being able to run FreeBSD software quite easily, there is a large pool of free, open source software that often does the same thing as PC software, and often just as good. Outside of games, business environments, and software development for Windows XP, I just cannot find any reason why anyone needs to boot into Windows XP versus Mac OSX. And even then, the drawbacks are miserable. In fact, in a business environment, you effectively would not be able to use Mac OSX at all. So the Boot Camp software really does not help Apple penetrate businesses, and only a few people will be able to productively make use of dual booting.

J.Ja

MSN adCenter: WOW. I just acted on an invitation to MSN adCenter on behalf of one of my customers. We decided to try to enter the beta, since the Overture/Yahoo! ads are randomly not showing on MSN Search when MSN tests their new system, typically late at night. Since the site sells consumer goods, it is just as important that ads are showing at 9 PM as it is to have them up at 9 AM.

After the initial login, I was brought to an interface that just completely blew me away. Google AdWords and Overture/Yahoo! Both have cluttered interfaces. Google has an especially poor interface. The MSN adCenter interface is clean, fast, easy to use, well marked. I just cannot say enough good things about it. I have not reviewed all of its features, but it looks like it has everything that Google AdWords and Overture/Yahoo! have, while being easier to navigate.

Additionally, my customer in the MSN adCenter program is in love with the pricing structure, which is better than how they feel about Google AdWords or Overture/Yahoo! They are currently spending $150/month with Google AdWords, and they are hitting their daily budget cap by about noon everyday. We are not currently able to perform log analysis (the logs are not available through their current web host), but we are pretty sure that the clicks from Google AdWords are pretty useless. Indeed, we are pretty sure that many of the clicks from Google AdWords are actually click fraud, but without the logs there is no way to tell. They have the opposite problem with Overture/Yahoo! The bids are so cheap with Overture/Yahoo! That they are only incurring about $7/month in charges. But Overture/Yahoo! Has a $20/month minimum spend limit, so they are being charged for clicks they never get. Part of the problem is that this website is a Top 10 listing in the organic results for both search engines anyways for nearly every keyword they can think of. I know, it sounds crazy that being in the top ten search results (even for generic terms!) can be a "problem", but as far as Overture/Yahoo! is concerned, it is! With MSN adCenter, there is a $5 signup fee, the minimum bid is only five cents, and you get charged at first in $50 increments (or every 30 days, whichever comes first); the $50 increment slowly goes up as your time in the program increases. There is no minimum spend limit, so you only pay for clicks you get. My customer is delighted.

My only complaint so far with MSN adCenter is the system for importing keyword information. It took me about fifteen minutes to find a link to the spreadsheet, and when I found it, it did not match the examples or the otherwise well written instructions.

The help system is very well done as well. It feels like a Microsoft Office application, by shrinking the browser window to have the Help window fill the remaining space, with a tight interaction between the two windows.

I was also surprised that MSN assigned us a representative to help walk us through the process and evaluate our needs. The representative is actually calling us by phone; it is nice to hear a voice instead of sending emails and waiting for two days like you need to do with Google or Overture/Yahoo!

Overall, with the exception of the speed bump caused by the import spreadsheet, I am extremely impressed with MSN adCenter, and look forwards to exploring it in depth as my customers' needs require me to.

J.Ja

Richard Stiennon at ZDNet argues that Apache is inherently less vulnerable to attacks than IIS, because it makes less system calls over the course of serving an HTML page, and is therefore less vulnerable to things like buffer overflow attacks. The argument, while have some prima facie appeal, is specious. Let us examine in depth the truth about what he says:

Both images are a complete map of the system calls that occur when a web server serves up a single page of html with a single picture.

It is odd, but I cannot remember the last time a Web server was exploited on basic static HTML serving functionality. Why? Because there is nothing to attack! The serving of static HTML pages simply does not leave room for a buffer overflow, because the server is not running any arbitrary code; all it is doing is mapping the URI request to a local file, and streaming the file to the client with the appropriate HTTP headers at the top. That is it. How are you going to attack that, except for attacking the method that the server uses to process the headers, or maybe getting it to serve a file it should not?

The more system calls, the greater potential for vulnerability, the more effort needed to create secure applications.

I can agree with this. Except there is one little problem: Apache cannot be compared to IIS! Take a close look at what Apache does, out of the box: it serves static web pages. CGI is disabled by default. Even if CGI were to be enabled any vulnerabilities at that point are not in Apache, but with whatever is fulfilling the CGI request. IIS, on the other hand, has all sorts of functionality built into it, such as running ASP scripts, .Net applications, and so on and so on that Apache cannot do without the aid of third party (or non-default) extensions. What does the system call tree look like for the entire LAMP stack compared to the Windows/IIS/ASP.Net/SQL Server stack? I bet they look much more similar. Sorry pal, but you are using an apples-to-oranges comparison when comparing IIS?s system calls to Apache?s.

Furthermore, how often does the Web server itself get attacked? Not nearly as often as the applications running on the Web server. Poor programming habits (such as not properly validating data, misuse of routines line printf() on input that was not validated, and so on and so on) are the cause of Web application vulnerabilities. There are not many Web server vulnerabilities out there now, or ever.

Poor systems administration is another source of common attacks. I don?t care what OS you are running, when you have your Web server running as root or Administrator because that is easier than properly setting up permissions, you have a problem. A Perl script that is running as root outside of a chroot jail is much more of a problem that even the naughtiest ASP.Net application running on IIS as a restricted user. Period.

Ignorance and laziness are the root cause of the vast majority of security breaches, not the server?s OS or application stack. PERIOD. No OS or Web server in the world will protect you if a programmer sticks the input from a Web form into the WHERE clause of a SELECT statement against a SQL injection. No amount of anti-virus or anti-whatever will help you if you have a sys admin who lets the user upload a file to an area outside the acceptable area and then execute that file while the Web server runs as root. No firewall will save you if the programmer uses a function with a known vulnerability on data that has not been scrubbed.

Those are the facts. Mr. Stiennon, I suggest that you learn the facts. You may not be a journalist and just a blogger (I am assuming by that, you mean ?I write subjectively, not objectively? which equates to ?this is my opinion, not fact?), but you still have a responsibility as a representative (employed or not employed) of a publication that is well regarded.

J.Ja

I was recently subjected to an interesting new type of malicious code a few days ago, and I wanted to share it.

A friend of mine asked me to help him with a little bit of PHP coding a few days ago. He understands a bit about programming, but never did it for anything complex, and does not do it very often. He sent me the script he had written, and I started tinkering with it, and the more I started playing with it, it soon ended up being a ground-up re-write of his code.

The script itself had a fairly simple logic to it: parse the Apache access log, find other pages that have referred visitors to this particular page, and create a link page with the number of referrals. When doing some debugging, though, something odd happened. I was dumping the output of the raw log to the browser, and all of a sudden I was redirected to another web site!

Digging through the log file, I found the culprit: a site spider had put a chunk of JavaScript within <SCRIPT> tags to perform a redirect as its User Agent header. Obviously, someone had figured out that many people use Web-based log analysis tools, which will show you the user agents. I am grateful that the site which I was redirected to did not contain any malicious code of its own.

What made this attack extremely interesting to me is that it did not actually attack a particular piece of software, nor did it care what OS I used or anything else. All it needed was for someone to run code that did not validate data. Indeed, it is a very common developer misperception to assume that data, once it is in a database, is clean and does not need to be validated on its way out of the database. This is the real lesson learned here. I can put all of the input validation I want into my program. But if someone else's software also accesses the same database, and does not properly validate data, I might as well not be doing validation at all, if I assume that the data is valid when I use it.

This is another example of how ignorance or laziness on the programmer's behalf can become a major catastrophe. Imagine if a piece of software had been written before JavaScript had been introduced, and was still in use? The programmer would not have even known to be able to prevent this kind of attack.

This is yet another reason why I am down on Web applications; it is the only system that I can think of in which input by one user is presented to another user in a way that the second user's computer will parse and interpreted and maybe even execute the first user's input, outside of the control of the developer. In thin client and desktop application computing, the programmer has total and complete control over the presentation layer and what occurs there. In Web application, the presentation layer is a complete no-man's land. There is no telling what will happen there. Data that is good today may become dangerous tomorrow if some new technology gets added to the browser and creates a browser issue. One example would be to allow users to post videos online; if there is a buffer overflow problem in the user's media player of choice, then you (the programmer) are giving malicious users a tool to attack other users. Web services are just as bad, particularly when using an AJAX method that takes your software out of the loop. In those situations, you do not even control the third party website. It could be riddled with problems, and you would not even know it until users are contacting you and asking why your software infected their computer with malware or crashed their computer completely.

At the end of the day, I was able to complete the script. Naturally, I made sure to strip any and all HTML, JavaScript, etc. from the input as it was being read. But it was a great reminder to me that no matter how many external parsers, validators, etc. that a piece of data goes through, they may not be providing the validation that my application requires. Input that is healthy, acceptable, and possibly even desirable for one program is not necessarily so for another program.

J.Ja

David Berlind over at ZDNet recently responded to George Ou's piece on the possibility of media bias regarding coverage of Internet Explorer and Firefox.

Let us apply my patented Logic Analysis System on the concept of holding companies to different standards for the same type of product, using some of Mr. Berlind's arguments:

"Internet Explorer can be held to a higher standard than Firefox because it has been on the market longer. In addition, Microsoft has plenty of money and can hire the best engineers in unlimited quantities. Microsoft has been making bold claims about IE whereas the Firefox team does not. Therefore, when Internet Explorer has defects in terms of stability and security it is much more of a problem than when Firefox does."

Let's first parse out all product references and replace them with variables:

"{Product A} can be held to a higher standard than {Product B} because it has been on the market longer. In addition, {Company A} has plenty of money and can hire the best engineers in unlimited quantities. {Company A} has been making bold claims about {Product A} whereas {Company B} does not. Therefore, when {Product A} has defects in terms of {Defect X} and {Defect Y} it is much more of a problem than when {Product B} does."

Now, let's try filling in some new values:

Product A = "Ford Explorer"

Product B = "Kia Sportage"

Company A = "Ford"

Company B = "Kia"

Defect X = "engine fires"

Defect Y = "brake malfunction"

"Ford Explorer can be held to a higher standard than Kia Sportage because it has been on the market longer. In addition, Ford has plenty of money and can hire the best engineers in unlimited quantities. Ford has been making bold claims about Ford Explorer whereas Kia does not. Therefore, when Ford Explorer has defects in terms of engine fires and brake malfunction it is much more of a problem than when Kia Sportage does."

All of a sudden, this type of statement doesn't sound so great, does it?

What I find even more amazing is that the Web 2.0 cheerleaders seem to closely overlap the Firefox groupies (as well as the Google bootlickers, for that matter). They want to replace most of userland applications with Web-based applications, but they seem to have no problem if the web browser is filled with problems? It is fine to use a buggy, error prone product as long as it is GPLed? Especially when you want the browser to replace most userland applications? Get real.

Some argue that since you pay to use Internet Explorer (indirectly though an OS license) and Firefox is 100% free, that Internet Explorer can be held to a higher standard. This is an excellent point, but not completely correct. If you had a choice between paying for IE and not paying for IE (such as purchasing it separately, or as an add-on to Windows) then this might be a legitimate argument. Similarly, if the inclusion of Internet Explorer in Windows played a part in your choice in operating systems, then it could be said that you are paying for Internet Explorer. But in all honesty, if you chose Windows for reasons that have nothing to do with Internet Explorer, you did not really pay for it; you got it as gravy.

A lot of people also emphasize that Firefox is a new product, and where it is at this stage of development (better than Internet Explorer on some things, more features than Internet Explorer, not as good for other things) is amazing considering its age. This is a completely bogus statement! Firefox actually comes from an older code tree than Internet Explorer! How is that? Firefox is actually the Mozilla Web browser at heart, sans the Mozilla suite (originally it started off as a lightweight browser, but it is now just as heavy as Mozilla). And where did Mozilla come from? It came from Netscape, when Netscape open-sourced Navigator ages ago. Netscape was on the market before Internet Explorer. So to give Firefox bonus points for its age is simply ignoring history.

The real truth is, Internet Explorer and Firefox need to be held to the same standard, and that standard is not the one that Firefox is being held to; it is the standard that Internet Explorer is being held to, if not a higher one. It is downright shameful that Internet Explorer still has as many bugs and security holes as it does. I do not know if ActiveX is disabled by default, but it should be. Internet Explorer, to be frankly honest, is a dog. It is not standards compliant, its PNG rendering is messy at best and ActiveX is still filled with security holes, and so on and so on. If Internet Explorer needs to meet this standard, than so should Firefox. I do not consider either one of them to be particularly great products. I rarely use Firefox, except to test cross-platform compatibility, so I cannot truly judge it as a browser. But from all of the reports I read regarding its stability, I think I would prefer to avoid it for the time being. When it comes to web browsers, my personal choice is less features, probably less secure (I do not think we will be able to really judge Firefox's security for a while longer), and more stability. I rarely go to Web sites that I am not familiar with, I have locked down Internet Explorer fairly tightly, and I most definitely do not go to Web sites of a questionable nature. But I frequently have a web browser open, and cannot afford to have it crashing on me repeatedly.

There is no extra credit for an engineer who designs a bridge that only partially collapses. There is no curve for an auto maker who has a faulty product that kills only 25% of the people who own the product. There is no bonuses to give to programmers who write code that allows security breaches. Period. It does not matter who you are. So why give one product a free pass (or a reduce fare admission) and not another? Especially when both browsers need a lot more work to be ready to transition to the world of online applications replacing desktop applications?

J.Ja

I have spent the last three weeks of my life, more or less, trying to do what should be a trivial task: get a map out of Microsoft MapPoint 2004 (the desktop app, not the Web service) and save it as an independent image. There are all sorts of problems with this though!

It seems that someone at Microsoft decided to cripple the MapPoint ActiveX control, for reasons beyond my understanding. Functionality that exists within the MapPoint software, and is accessible via VBA just cannot be used from outside of VBA, such as saving the map as an HTML file. The solution suggested? Fire up an entire instance of MapPoint and programmatically command it to do a "Save As". For whatever reason, what is a 1 second operation through the MapPoint application becomes a 2 ? 20 minute (you read that right, 20 minutes for some maps!) operation when run from VB.Net. During this period of time, MapPoint like to glom 100MB of RAM and 100% CPU.

Every single method that I have seen suggested simply does not work. Even telling it to copy to the clipboard fails after about 1300 iterations (I am looping through a large number of maps). The only thing anyone can tell me about this error is to keep retrying it within a loop and eventually it will work. Code that fails at random is not code I think I want to be using.

What bothers me about this is Microsoft's decision behind this. I just cannot fathom why they only included basic functionality to the ActiveX control, especially when that functionality exists within MapPoint itself. Since I need to have MapPoint installed to use the ActiveX control, it is not like they would be losing sales or anything like that by providing full functionality to the ActiveX control. This reminds me a lot of the undocumented Windows APIs that Microsoft used to keep other companies from writing software as capable as their own software. If it were not for the fact that MapPoint costs a fraction of what my other options are, I would be more than happy to dump it.

This is actually my first time using an ActiveX control of an Office product. Up until now, all of my Office programming has been with VBA within the application itself. Has anyone else had these kinds of problems? If so, I may need to reconsider a few things in how I was hoping to do some future projects.

J.Ja

It is a commonly held belief that geeks do not need to be able to communicate outside of Nerdland. In fact, it is an outright expectation. Programmers who gets nervous around pretty girls, systems administrators who cannot give a presentation to more than two people at a time, and DBAs that stutter unless they are discussing Dungeons and Dragons are what many people envision when they think of IT professionals. These are all common stereotypes of IT professionals. Sad to say, many IT professionals buy into this idea, and sometimes even actively encourage it!

I am not going to pretend to be surprised by this. Up until the age of sixteen or so, reaching Level 4 as a bard seemed more important than reaching first base with a woman. Weird Al Yankovich was "romantic" in my mind and a "nice wardrobe" meant a closet full of shirts from hardware and software vendors, preferable ones with multiple years' worth of pizza stains on them to prove my "authenticity". I thought that if people did not understand me, it was because they were stupid, not that I was unable to communicate with them.

Thankfully, I changed. Mostly. I still think Weird Al is funny on occasion, and the ratty shirts are still there (though they now tend to be Metallica and Mr. Bungle shirts from my post-ubergeek years). The biggest change was that my communication skills improved significantly. I took classes in high school such as AFJROTC and Mock Trial that taught me how to speak to an audience, with or without notes. My classes in college (I will merely admit that I double majored in "cannot-get-a-job-ology" which is code for "the liberal arts") involved few tests, but endless amounts of paper writing. What few tests there were tended to be essay questions. In other words, I was learning a lot about communication skills.

What does this have to do with the IT industry? Plenty. If you want to know why your manager seems to be a "grinning idiot" with no clue what your job is instead of someone with technical skills, take a look at what that manager brings to the table. That manager is very likely to have an MBA or maybe an MIS degree. Their external learning is probably in "risk management" or Six Sigma, not the Cisco or Red Hat certification you just earned. The manager's job is to interface between "the suits" and the IT people. The manager does not actually need to know how to do your job if you communicate your needs to him properly. What manager does need to know is how your job relates to the business.

It has been my experience since I started blogging about IT issues on TechRepublic, that the majority of the time when I receive heavy criticism, it is because I failed to write clearly and properly communicate my message. Sure, there have been instances where someone climbed all over me for using one bad example or analogy in a 3,000 word post, or where someone was obviously unable to comprehend the topic at hand. But by and large, when I receive negative feedback, it is my own fault for not writing clearly.

At my current position, my manager does not understand much programming (he knows some VBA), systems administration, database administration, networking, computer repair, or any of the other tasks I do. He knows how to run the company, deal with customers, and so on. He really does not need to know the gritty details of what the project is hung up on; he just needs to know how long the delay will be. He does not care what brand of motherboard I buy or what CPU I select; he needs to know the price and business justification for the expenditure.

Many of the IT people that I have worked with simply do not understand this. They fill a proposal with technical details, and expect the person reading it to understand the benefit of the proposal from the technical information. In other cases, they write an email that is littered with typos and spelling mistakes. These types of mistakes do not help the recipient to understand why they should approve your request or give your project more resources, or otherwise help you with whatever goal it is that you are trying to accomplish. Tailor your message for the audience. If the recipient is a technical person, make it technical. If they are a non-technical person, use language that a non-technical person can understand. As I often do for programs that I have written, I pass it through the "Mom test." In other words, I ask my mother to review it. She is about as non-technical as it gets. If my mother can understand what I have written to the point where she can make an educated business decision, then it is a good communication.

Many of the IT people out there seem to think that this is degrading. These are the same types of IT people who make web sites that only display in one particular web browser, or require you to go find some funky external library, or insist that you recompile the application yourself without providing any documentation. These are the IT people that may be excellent at their jobs, but are hated by everyone that their job touches. You do not need to go this route. No one will criticize you or complain if you learn to effectively communicate with non-technical people. In fact, they will appreciate you even more. My experience has been that improved communications skills leads to better opportunities in life and in my career. If a manager is evaluating two candidates for a promotion, they are more likely to pick someone with less technical skills who communicates well than a more technical person who does not communicate well. Why? Because the person with good communication skills is able to show that they know what they are talking about, while the person without those skills simply cannot be understood.

If you feel that your communication skills may be lacking, there are things that you can do to help them improve. One suggestion is to read more books and magazines. If you already ready books and magazines, escalate the difficulty level of your readings or try reading about topics that you are not familiar with. I have found that crossword puzzles are great tools to expand your vocabulary. Try your hand at writing something, whether it be short fiction, how-to articles, or poetry. If you can, try to go to new places or talk to different people; sometimes we find ourselves in cliques with a shared mindset that makes it difficult to learn how to communicate outside of that group. There are lots of different ways to improve communications skills, but at the end of the day, they all amount to "increase the frequency of your communications, the diversity of the mediums, and the people that you communicate with."

J.Ja

Apparently, Oracle is seriously considering putting together its own full application stack. There seems to be a lot of debate about this, both positive and negative. Personally, I think I will have to side with the naysayers on this one.

First of all, the last thing the world needs is more confusion amongst the Linux distributions. I understand that Oracle is looking to purchase an existing distribution, not start their own. But do open source projects really manage well after being purchased by a large corporation? SuSE seems to be a bit unhealthy after being bought by Novell. Granted, Novell has "Fido's magic touch" where everything they touch turns to dog doo. WordPerfect. Corel. Their own products. And so on. Much of the open source community seems to be "personality driven." The movement of one or two key contributors to a project can cripple it. Not just because they were cornerstones of development, but if they leave, so do many other people. Forking is another common problem after an open source project gets purchased. This is actually the main reasons why I use BSD instead of Linux; I feel that there is too much churn in the Linux community. If  I were a Linux user, my biggest fear would be "what if Linus Torvalds gets hit by a bus?" I can imagine the power scramble if that were to happen, and it scares me. So the idea of Oracle purchasing or starting a Linux distribution of their own would worry me, particularly if they were to purchase one.

Another issue with the idea of Oracle having a stack, is that I am not sure if Oracle is a company I would want to have to deal with. Their website is a frightening place indeed; finding useful information in a usable format can frequently take hours. Just try to find the SELECT syntax on their website, I dare you. I do not think that Oracle understands how to interface with customers on that type of basic level well enough to want to have my OS coming from them.

Another arena where Oracle falls woefully short already is in their management tools. Everything about installing, configuring, and maintaining Oracle's database products is pure misery. Everything is done wrong, as far as I am concerned. They have visual tools such as Oracle Enterprise Manager that simply do not work right. For example, if you put the cursor into a field and start typing, the first character is usually dropped. The interfaces on their visual tools stinks as well. Oracle Enterprise Manager has "features" on the menu that when selected, tell you to use "Oracle Enterprise Manager Console." Isn't that the tool I am currently in? Even the GUI version of SQL Plus is a dog; it has a maximum line length, forcing me to wrap lines by hand, and does not even do my the courtesy of putting a vertical bare showing me where to wrap them. Oracle products do not install correctly; the DLLs needed for ASP and ASP.Net connectivity have the file permissions set incorrectly, a problem that has persisted through a number of major revisions. Even trying to get clients talking to Oracle is a pain. Oracle needs multiple hundreds of megabytes worth of garbage to have a desktop talking to an Oracle database, whereas MySQL and Microsoft SQL Server just need a tiny ODBC (or JDBC, or whatever the right method is for your purpose) driver. Overall, the last thing I want is for my OS to be delivered by a company with this mentality.

Oracle is also very, very bad about delivering patches, and they do not seem to have a handle on security. In terms of timely patch releases, they make Microsoft look like perfection. Oracle has a bad habit of outright ignoring critical security flaws for months or years at a time, even after being told about them. Their patch cycle seems to be quarterly; meanwhile, Microsoft gets criticized for monthly patches. Oracle also does not seem to understand automatic patching. Again, these are traits I simply do not want in the source of my OS.

As it stands now, a good portion of Oracle's stack is not even their own software. Oracle Application Server appears to be a hacked up version of Apache. They do not have any languages of their own (or even re-packaged/re-branded) outside of PL/SQL which you will not be writing applications in. Right now, the only part of the LAMP stack that Oracle can play a role in is the M. You can have a LAOP stack if you want. Oracle is considering grabbing the L. They are still missing the A and P. Indeed, when one looks at what Oracle does well (high performance, scalable database server), I would much rather prefer that Oracle go after the A and not the L! Web servers are more closely related to databases, in terms of how they get written. You simply do not try to start from the middle of the stack and work your way out like Oracle is considering. You need to start from one end or the other and go across. Red Hat had the L, they bought JBoss to get the A. They still need M and P. Oracle is trying to start at M and then go for the L. This just does not work. This is not a stack, this is patchwork insanity.

The idea behind a stack is that you have a group of tools that sit upon each other and play nicely with each other. Patchwork stacks just don't cut it. Components within a stack are often not best of breed by themselves, but the combination works great. Look at LAMP: the P is not so great (Perl is poor for web development, PHP is wretched in general, Python just isn't very popular), and MySQL is not quite top-tier yet (although it is still great). But LAMP works great. Oracle does not know how to make their software play nice with other software. The idea of them trying to build a stack is laughable, at best.

J.Ja

eWeek recently published a very interesting interview with James Gosling, the father of Java. Mr. Gosling's candor and honesty are to be admired, and it seems that he and I are on the same wavelength regarding many topics:

AJAX

"Creating [AJAX components] is extremely hard. Not because programming JavaScript is hard, but because all these flavors of JavaScript are ever so slightly different. You have to build your components so that they're adaptable to all the different browsers that you care about. And you have to figure out how to test them. None of the browsers has decent debugging hooks."

I have been saying this for some time as well. The discrepencies between various browsers' implementation of JavaScript make it difficult at best to write a fully cross-platform AJAX application of any complexity. Furthermore, the browsers themselves simply do not offer an environment to debug in; developers are stuck with write() and alert() to show the value of variables throughout the code execution. It is like working with BASIC code circa 1986.

"There's no ability to do cross-platform QA; you've just got to do them one by one. Right now it looks pretty hopeless to make AJAX development easier."

This is so sad, yet so true. I simply fail to see how anyone can realistically push AJAX as a platform for applications with the same level of functionality as desktop applications under these conditions.

Regarding Sun's business mistakes

"There are so many to choose form. And sometimes it's hard to say what's a blunder and what's just the case of the world being weird."

All I can say to this is "WOW!" Can you imagine Bill Gates or Steve Ballmer or Michael Dell or Steve Jobs or Larry Ellison saying something like this? Neither can I. Granted, Gosling is an engineer, not a business person. But it is this type of attitude that has hampered Sun so badly over the years. The fact is, with business sense like this, Sun's very existence is testimony to the quality of its products. Sun has indeed made more blunders than just about any major tech company out there, except for maybe Novell and Borland. Like Novell and Borland used to be, Sun is run by engineers. Their products are amazingly good most of the time, but they often simply have no good fit into the realities of the business world, and the rest of the company just does not know how to get paid for those products. Solaris is regarding by many, if not most knowledgeable people as the best UNIX out there, and certainly better than Linux. Yet Sun cannot manage to give it away! It is because Sun waited way too long to try to go open source with it. First they attempted to embrace Linux, then they open source Solaris. Sun changes its motto every year it seems like, that just shows how confused and directionless they are.

Overall, I like Sun. I think Solaris is a good UNIX, from what I know and have seen of it. Java, while being a dog in reality, is an innovative idea and did a lot to break Web development out of the stagnation of CGI. If the VMs were not so wretched, I would see it as a great competitor to .Net on the desktop. It is just a real shame that no one at Sun understand business.

J.Ja

Hear, Hear!!!  I have been saying the same thing for 25+ years.

Does anyone else believe, as I do, that Microsoft programmers do all their development work on Macs??  If they used Windows, it might work.

FLS

In response to a previous article (Geeks and Communications Skills), commenter Tony Hopkinson wrote:

"Now maybe I'm not business aware enough to realise why short term gains are preferable to long term success, may be one of these business types should explain it, then we can all row the boat in the same direction."

DirtClod also points out the connection between IT projects and research grants:

"Scientists who communicate get GRANTS.  IT people who want the boss to GRANT funding for projects might find the time to learn our language."

The two ideas are not unrelated. Tony?s complaint is a common frustration in IT. Even the best proposal in the world that shows great ROI numbers, productivity gains, reduced downtime, and all of the other things that a good IT proposal should show can be turned down. One would think that "the suits" of all people would jump on a chance to increase profits after overcoming a substantial upfront cost. After all, this is why companies build factories, invest in training, outsource workers, and so forth.

Unfortunately, increased profit is not the actual goal of many companies, particularly publicly traded companies. The actual goal of these companies is "to increase shareholder value." "Shareholder value" directly translates to "stock price." Look at the compensation plans for C-level executives (CEO, COO, CIO, etc.). Their bonuses are tied more directly to stock price than to profit, market share, revenue growth, or any other direct financial metric. In addition, a significant portion of C-level compensation is in the form of stock options. Additionally, the management of a publicly traded company has what is called "a fiduciary responsibility to the shareholders." That means that they are held accountable to the shareholders, not to the employees or customers. To put it in a more obvious way, "it is in management?s best interests to increase the stock price of a company at the expense of any other metric."

The end result is that a company acts in whatever way will be best for the stock price, which is not always best for the company. To make the situation worse, a C-level executive typically does not stay with a company for more than a few years. They have little incentive to worry about the long term health (or even the long term stock price) of a company. Shareholders now rarely hang onto a stock for the long term; they are looking to "buy low and sell high," which is hardly a recipe for having shareholders that care about the viability of a company?s business model or the sense of their business practices.

It is true that things like profit and loss, revenue growth, market share, and so on and so on play a role in the stock price of a company. This information gets released to the public once a financial quarter. IT projects, sadly, tend to be capital expensive. The inefficiencies that IT projects resolve are not line items on any spreadsheet though. Let me give an example. At one company I worked for, they computer that I was assigned was a Pentium 1 with 128 MB of RAM, running Windows 95. This computer was expected to be running the following applications throughout the shift: Microsoft Excel, Microsoft Outlook, Microsoft Word, Internet Explorer (two windows minimum, one of which contained a Java applet), a custom built Java application (using a non-standard Java VM, so I would have two Java VMs open at any given time), McAfee Anti-Virus, and a telnet client that was extremely heavy (it had all types of scripting, macros, etc. built in). Microsoft Word would be open about half of the time, as well as a few other applications. By the way, this was in the year 2003. To the best of my knowledge, that PC is still in use. This setup was so unstable, I had to start the applications in a particular order or face system lockup. Everyone had to come onto the shift 15 minutes early as well. So the company was paying 15 minutes of overtime per day, which comes to 65 hours of overtime a year. Even at our pittance of a wage, this inefficiency would have paid for replacement PCs within a year.

Why were those PCs never replaced? For the same reason that many IT projects never occur: the short term budgetary impact would have affected the stock price more than the efficiency gains. Inefficiencies simply do not show up in reporting figures. There is no line item in a quarterly report that says, "excessive staffing due to a process not being computerized," or "additional payroll because computers are slow," or "missed SLAs due to poorly trained users." In comparison, "three month project to automate a process," "replacement and upgrade of existing PCs," and "training classes for users," are all line items that Wall Street (or London, or Tokyo, or wherever) sees. It is sad, but it is true. This is why a great project can get shot down. The initial upfront cost is just too high and the ROI just does not come fast enough. I am not going to pretend to know what numbers "the suits" have in mind when evaluating an IT project, but off the cuff it seems to me that you need to deliver a 25% savings within a quarter of project completion, and 150% within one year of project completion on a one quarter long project to get approval.

This mentality hits IT everywhere you look. Projects get rolled out as "betas" that never seem to get finished because of it. Programs get written in "quick and dirty" languages like .Net that are just not appropriate for certain types of projects. In reality, if you want to write a highly scalable Web application, writing it in C++ in a CGI environment is your best bet. But now one will ever get approval for that project, because good C++ coders are expensive, and the project will take forever because you would need to re-write much of what JSP, PHP, and ASP already handle.

The only way to get the funding you need for your project is to do exactly what DirtClod says to do: learn management?s language. If you cannot show in words that management understands, in a format they understand ("Gentlemen, start your copies of PowerPoint!") that your project will more than pay for itself quickly enough to be palatable to the stockholders, it simply will not fly.

Do not think that this does not affect private companies, either. It does. Private companies with a small amount of ownership (a few partners) have a tendency for the owners to treat every dollar in the company as their own, which is understandable. The $10,000 you want to spend on servers is viewed by the boss as half a year?s tuition for his child?s college. Many, if not most privately held businesses think ahead to selling out or going public. A history of cost management helps them get the most return on their initial investment of time and capital. No matter how you cut it, IT projects that cannot be shown to have a big, quick ROI kicker are just not going to be approved, regardless of how well you write the proposal. I will discuss these kinds of "low hanging fruit" projects soon, stay tuned.

J.Ja

[5/2/2006] Edited to clarify for those who may have missed the original discussion. I am not against podcasts. I am against information being distributed as a podcast but not available in any other format. There is nothing inherently wrong with podcasts as long as that information is available in a text format in addition to the podcast, or if the podcast provides a unique value proposition.

This blog is written in response to the comment thread for Don't be lazy: Communicate with your end users.

I am with Palmetto on this one. I refuse to use podcasts (along with RSS and many other "Web 2.0" hocus pocus). I can read approximately 10 times faster than anyone (save the guy who did the Micro Machines ads) can talk. I can read the script for a 90 minute movie in about 10 minutes, typically. I can read a 1,000 page book in about 10 hours. Listening is the least efficient form of knowledge transfer for me. Reading is the most efficient. Like many others, I can read an article at my desk, even if on the phone or waiting for another process to finish. If I am interrupted, I just remember where I was, re-read the preceeding paragraph or sentence, and continue, as opposed to having to shuttle back and forth to jog my memory.

Furthermore, this is the Internet, not the radio. Text is the lowest common denominator. Satisfy the LCD first, and then worry about the high-end users or special need users. This is Reason #4,562 why I am against AJAX; it fails on the LCD test. If your information cannot be used within Lynx, throw it out, it is worthless. Even someone who uses a screen reader (such as the blind or vision impaired) is equally well served by a text document as they are a podcast. A deaf person cannot use a podcast at all, whereas they can read text. Do you mean to not have your message be accessed by the deaf? If I owned a store that a handicapped person could not enter for whatever reason, I would be in deep trouble as per Federal law. Your online business should operate the same way. No excuses. Call me silly, call me crazy, but I do not turn away business because I wanted a fancy widget that deprived 5% of my potential customers of the chance to give me their money.

The only time a podcast (or any other audio-only presentation of information) adds any value is when the voice itself provides information that cannot be easily or adequately transcribed (vocal inflection, information about music with sample clips, sarcastic remarks, etc.). I do not have an iPod or similar device, and if I did I might not have a way of hooking it up to my car stereo, where I listen to most of my audio stuff. What do you propose I do? Burn the podcast to CD to listen in my car? I will not do that, and neither will anyone else most likely.

In your article itself, you state:

"In this 5-minute podcast, I explain why there is no substitute for good communication and offer a little advice for using three common communication methods: e-mail, voice mail, and face-to-face contacts."

Offering a podcast without a transcript (or at least a summary of the salient points) is pretty lazy. I have a problem with my hands, wrists, and eyes. Even at my age, typing, especially at the end of the day, is extremely painful to me physically. Yet I do it anyways, because that is the best way to communicate on the Web, and I communicate via the Web. I would love to simply be a lecturer or a radio or TV personality, but I am not. I put up with the pain in order to provide the best possible service to my readers.

Remember, we (the audience) are the customer. If we are unable to use or consume your product, no matter how good it may be, you will not be able to sell it. Period. This is why I spend so many bytes in my blogs discussing basic usability. Poor user interfaces equal low market share, regardless of how good the product is (look at Linux in the desktop market). Of course, great user interfaces do not result in great market share (Macs in the desktop market), but a poor interface will always lose to a better interface, unless the product is so good that its value proposition after the hit from usability still makes it substantially more valuable than the more easily used product. It is that simple.

J.Ja

Every now and then, I will see a "dispelling the myths of open source" type of article, blog, discussion, or whatever come my way, and it always seems to come around to the "more eyeballs means less defects" idea. For whatever reason, many open source proponents seem to believe that there is this rear guard of closed source folks spreading FUD about open source (even Microsoft has toned down their rhetoric lately). I think that less than 10% of the knowledgeable people out there actually claim that closed source is inherently more secure than open source. It definitely seems that most people (at least amongst those that voice an opinion) believe that open source software is inherently more secure than close source software.

In reality, what matters much more than "open" or "closed" source, is who is writing and reviewing the code, why they are doing it, and how long they are doing it. If I compare OSS project "Project A" to closed source project "Project B", and "Project A" is being written by five 15 year olds who just wrote "Hello World" last week for the first time, and "Project B" is being written by twenty crusty old timers, and "Project A" has a three person "community" and "Project B" has zero community inspecting the source, I still guarantee that "Project B" will blow "Project A" out of the water. Open source, closed source, it really does not matter.

Another thing that I find fallacious about this argument is the continual assumption that "open source" means "free." The two are not mutual ideas, not by a long shot. Nor are they mutually exclusive. Historically speaking, UNIX is "open source," but hardly "free." Indeed, the original BSD386 project was due to the desire for there to be a free UNIX. One of the reasons why so much System V source code has ended up in various UNIXs over the years is precisely because Sytem V was open source, and SCO?s lawsuits exist because System V was not free! On the other hand, there is plenty of free software that is not open source. Just got to any shareware repository and find a piece of freeware that is pre-compiled and that does not include source code.

What really matters is who is writing and reviewing the code, and money tends to attract the continued writing and review of code much better than whatever it is that actually motivates FOSS coders. Sure, some FOSS projects (Apache, Linux, BSD, MySQL, etc.) attract top talent, but just taking a look at Source Forge shows that the vast majority of Open Source projects go nowhere. To decide that FOSS is the best possible method of development and quality control based on Windows vs. Linux or Oracle vs. MySQL or IIS vs. Apache or PHP vs. Java, or whatever is silly. That is like saying that "a Dodge will always be faster than a Chevy" based upon a comparison between the Viper and the Corvette.

One of the reasons why these projects are able to attract such a large pool of developers and testers has less to do with the fact that they are "open source," but the fact that they are free. Only a minute percentage of Linux users ever touch their source code, let alone look at it (or even care about it). They are attracted by its phenomenal price/performance ratio. The same can be said for any FOSS project. Thanks to the widespread usage of various package managers, it is fairly uncommon for most mainstream Linux users to even compile from source, let alone modify compiler flags or make changes to source code. If these packages were closed source but still free, most of their users would still use them and be testing them.

The vast majority of lines of code are written under the radar of most people and do not get any attention. Try comparing a small sample of each type of software. Take a few dozen random items from Source Forge that are in at least a "release quality" state and compare them to a few dozen freeware applications. Then evaluate the difference between closed source and open source. I really cannot tell you what the results will be, but I do know that many of the open source pieces of code that I have used, outside of the "big stuff" (various UNIXs, Apache, MySQL, PostgreSQL) are not so great. For a project that lacks glamour, it is hard to attract someone to spend a large amount of time seriously working on it. It is that simple.

Mind you, I am not against open source or free software whatsoever! I use it all of the time in my day-to-day life, especially FreeBSD, Apache, MySQL, and Perl. But I also use a lot of paid and/or closed source software as well, like Windows, IIS, Oracle, Microsoft Office and so on. Some of my favorite pieces of software are simple shareware applications: Notetab Pro and ThumbsPlus immediately come to mind. It is very rare that I have ever wanted or needed to "look under the hood" of a piece of software. Tomcat/Jakarta required me to do so to find out why it was not behaving as documented. Indeed, most of the time that I have had to look at source code, it was to compensate for poor documentation, not to actually make any change or satisfy a curious itch. I was grateful to be able to inspect the source code, but I would have preferred better documentation instead.

Many of the arguments that I hear in favor of open source compare Windows to Linux, or Internet Explorer to Firefox. Windows vs. Linux just shows that the Linux coders are better, smarter, and more well organized than Microsoft's Windows coders. Microsoft has had something like ten years to get Internet Explorer right, and they still have not managed to get it nailed down. This is not news. The fact is, closed source shops consistently crank out many products better than Microsoft?s too. One can just as easily compare OS/2 Warp or BeOS or MacOSX to the version of Windows from the relevant timeframe, and Windows still falls short on many (if not most) benchmarks like security, stability, usability, and so on. I note that it is rare for someone to compare MySQL or PostgreSQL to Oracle or Microsoft SQL Server in an "open source versus closed source" debate. Why do we never hear ".Net versus Mono?" Even comparing Apache to IIS is difficult, because IIS is a significantly more ambitious piece of software than Apache.

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.

J.Ja

Ed Burnette over at ZDNet likes to spend a lot of time writing about Eclipse versus NetBeans. He rarely gets into the technical merits of either piece of software, but he definitely seems to favor Eclipse. I have never used either one of these pieces of software, to be frankly honest. I tried to download Eclipse a few weeks ago, partially based upon Mr. Burnette's high ratings of it (he and I disagree on many things, but I respect and trust his opinion), but their website is bad to the point that I had no clue what files I actually wanted to download. What I just do not "get" though, is why it really matters.

I know, I know, it really does matter. But it should not.

If both NetBeans and Eclipse are creating "100% Pure Java" then both of them will be creating code that could be used in the other one. Both of them should be generating code that does not rely on a particular application server or VM to be installed. Was this, or was this not the "code portability" promise behind Java? To be honest, Java as a language offers very little if the code is not portable. Java code is supposed to be portable, but in reality it is not. Sun has a bad habit of breaking backwards compatibility between Java releases. It is bad enough that Java code needs to be targeted at a particular version of a VM from a particular vendor from running on a particular application server on a particular OS.

My last major experience with writing Java involved having to resolve differences between Tomcat/Jakarta and iPlanet. Bleh. If Java was just a slow (and it is slow) system with a miserable syntax (I love writing ten lines of code to take the place of just one line of code) I could accept it. After all, I do spend part of each day writing VB.Net and VBA code, and I can accept those languages, despite their myriad of flaws. But it is a broken system. The idea that if a user clicks on the "update your Java now!" icon, my application can/will break is horrible. The idea that if I prefer one IDE and another IDE cannot use or run my code is even worse.

The Java crowd just does not understand this. They are so busy fragmenting and fracturing the language that Microsoft is going to run right around them. If Microsoft (or Mono) can get .Net running properly on non-Microsoft OS's (admittedly quite a trick, considering how one of .Net's principles is to make the Windows API usable and expose as much of it as possible in a consistent fashion), then Java has no reason to exist. Java and .Net are both system resource hogs and slow, although my experience has been that .Net is a bit less of a pig. .Net has the advantage of letting you write in whatever language you want, provided there is a .Net compiler for it. And .Net is much better about framework versions and backwards compatibility than Java is. At that point, Microsoft will just have to convince people that they are not evil and that going with .Net will not enslave them to Redmond forever.

Personally, I do not want to see this happen. Microsoft is not a great company when it gains an overwhelming market share in a category. Microsoft is an awesome company when is has competition. .Net is a great example of this: I think .Net kicks Java with a set of spiked golf cleats "where it counts" on just about everything. I still do not think that .Net is great, but I would demand a raise if I had to spend any measurable amount of time writing Java code. But Microsoft needs the competition from Java to keep them honest. .Net would not have happened if not for Java, most likely. And the pressure from Java keeps Microsoft driving hard for improvements. As much as I dislike Java as a language, I love what it does for the IT ecosystem and economy. And I have little loyalty. If Java can show itself to be a superior system, I would not object to using it. Furthermore, I have a strong suspicion that I will be using Java on a regular basis in the near future to work with Cognos ReportNet. So it really is in my best interests to see Java be the best that it can be. To have two major IDEs producing incompatible code is not how to do that.

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

Writing code involves a mode of thinking that is foreign to most people. However, writing code is not a unique process. There is actually nothing very special about it. But most people are simply unequipped to think in the manner required of good programmers. That is not to say that they are unable to put together a piece of software. Anyone with enough knowledge of the right libraries can glue together a piece of software that accomplishes some sort of goal, whether it be taking a list of URLs, fetching the results, and saving them to a specified file location, or maybe queries a database and displays the results in a particular way.

One of the recent discussions on TechRepublic, "Has calculus enhanced your IT career?" highlights the problem with the way people think about writing software. Too many people fail to look outside of the immediate problem when writing code; they are so focused upon the trees, they do not see the forest. Writing code does not require "thinking outside of the box." It requires a view in which the box is gigantic. Too many people, when writing code, look at the tools that they are already familiar and comfortable with, and see every problem from that perspective.

One example of this is the passing of tabular data that is in a rigid format (such as the results of a SQL query) via XML. I have written all too often about the inefficiencies of XML as a format; it is particularly inefficient for this type of data transfer. A flat file format, such as CSV or a fixed length record format, would be created, transmitted, and parsed by the client significantly faster than an XML format. But programmers feel comfortable with XML; JavaScript has built in handlers for it, and the methods for working with it are well documented. In reality, it takes only a few minutes to write a CSV or fixed length file writer on the server side, and only a few more minutes writing JavaScript to consume it. But few people do things this way, because XML is a "chicken soup" format, it feels comfortable, it is known, and there is no work needed to use it. This is an example of the adage, "when you have a hammer, every problem looks like a nail."

For decades, programmers were scientists or mathematicians who ended up writing code. The mode of thought needed to write quality code is very close to the way physicists, biologists, mathematicians, etc. approach their problems. Interestingly enough, much of the literature in the field of Computer Science nearly always ends up in the realm of Philosophy. Any discussion on Artificial Intelligence is going to take about three seconds to become a philosophy discussion; there is no way around it. Some of the most interesting uses of computers for research purposes are being done by philosophers working with game theory. "Philosophy" simply means, "the study of something which cannot be quantified." As a particular topic becomes more rigidly defined, it becomes a subset of philosophy (such as psychology in the years of Freud and Jung). Eventually, someone finds a way to quantify the topic, and that is when it becomes a science (psychology after Skinner).

To be not just a good programmer, but a great programmer, you need to understand the scientific and philosophical ways of thinking. There just is no way around it. I worked for a company where most of the programmers had degrees in Physics and other similar scientific fields. They were excellent programmers. The programmers that I have met that came through a program where they were taught how to write code simply were not as good. Their education was based upon the syntax of a particular few languages, how to accomplish certain tasks. This is how oriented programming. These programmers simply did not understand the why of what they were doing. What Calculus (and other high level math courses) teaches someone is not just the math itself, it teaches a way of thinking about problems. This way of thinking is crucial for any programmer.

You can be a "shake and bake" programmer by going through something like DeVry or Chubb or Kumar, or whatever. But if you do not extend your knowledge, you will have a very hard time being more than just the type of programmer who glues libraries together. You will have a hard time working on the high level projects, like Artificial Intelligence, compiler design, languages, kernels, device drivers, and so on. No one wants to hire someone to be writing machine code or assembly, or some other low-level code who will be writing inefficient code, or who does not understand the principles of algorithms, and so on.

J.Ja

This is the first of a three part series regarding how to think like a programmer. In the next part of this series, I will discuss some techniques for expanding your thinking skills to be a better programmer. In the third part, I will cover the difference between shot term expediency and long term solutions.