In Theory

They say that to a man with a hammer everything looks like a nail. And this seems particularly true if that hammer is really pretty and has a lot of features. Web based applications are the current technology hammer.

As an avid user of the web I have been frequently frustrated by the way applications operate. Too often, entering information into the required fields is cumbersome and less than intuitive. The applications typically require absolute precision and generally do a poor job of leading the user from one field to the next. The question is, why is this?

My experience has led me to three possible explanations; 1) web based programmers lack the skills necessary to develop a good user interface, 2) web based programmers are lazy and arrogant and don't want to be bothered with usability, or 3) web based applications are not capable of real business data processing.

The truth of the matter is that all three of these explanations apply to various degrees.

First, the skill set of too many programmers is shallow. This is due to a variety of reasons; poor education, limited time in an apprentice position and the prevalence of prefabricated components.

It is surprising with the growth of "computer" or "technology" degrees how little is actually taught. Twenty-five years ago, a student in information technology learned multiple computer languages, operating system theory and design concepts. This broad based exposure provided a comparative environment that allowed the student to see solutions from multiple perspectives.

After interviewing many candidates with college degrees I have learned that languages are often optional or of minimal emphasis. Based on the output, it appears that information systems programs encourage students to do "really neat stuff," but do not give them a solid foundation for advancing their skills.

Historically, there were Junior Programmers, Senior Programmers and Lead Programmers each with a higher level of experience and presumably skill. Outside the line of programmers was the Systems Analyst who was responsible for the design and implementation of the system. Over the years this structure was phased out by the hybrid known as the Programmer/Analyst(P/A). This evolution has not provided a better IT world.

The P/A was encouraged by both programmers and those responsible for budgets. In a small shop, this may be necessary, however, it should not be viewed as optimal. Anytime two functions are combined, both lose definition and effectiveness. A systems analyst who is simultaneously a programmer can rarely concentrate on the needs and operation of the system without being distracted by the technological implementation. In other words, it difficult to mind the appearance of the building when you're concentrating on the stability of the structure. And, truth be told, most P/A are programmers and lack business insight to adequately design a system. Thus, system tend toward technical rather than operational considerations.

Finally, the increase in the number and availability of prefabricated components that claim a "plug and play" implementation leads to a short-circuit in the technological assembly of a system. While componentization has many advantages it does lead to an increase in ignorance. Programmers who advocate the high use of plug-in components often produce systems that resemble a Lego car rather than an effective business solution.

The shallow skills of too many programmers has lowered the expectations of users and conditioned them to accept flat, barren and restrictive interfaces. Somehow, this does not appear particularly progressive.

Second, it is surprising how lazy and arrogant many web programmers are. In my experience this attitude has been encouraged by the hype of the web. Businesses are frequently told that if they are not on the web then their business is falling behind. While there is some truth to this, it has grown into a practice that allows web programmers to believe that they are the most important part of the business. Thus a "you get what I give you" attitude held by too many programmers.

What businesses end up with is a web application that lacks ease of use because the programmer couldn't be bothered to place the cursor in the first field of the screen. Or input rules that require absolute accuracy and format, because the programmer either could not or would not edit the input data. The most unfortuate part of this is that too many businesses accept this type of product.

In addition to shallow knowledge and inflated egos, there is a good chance that web based applications may not be the best choice for business processing. The truth of the matter may well be that putting an application on the web, or making an application browser based might just be a bad business decision. If the business operation has to change to accommodate the software application, there is a good chance that bad software is involved. If a programmer says something cannot be done, there's a good chance that he is either lying and doesn't know enough.

The web is a great resource and should be utilized as much as possible by every business. Yet, it is not the only solution and like a hammer, is not always the best solution.

Peripheral operations are the key to successful systems.

As software has become more of a commodity and core business processes have become more predictable and standardized the differentiating factor in many systems has become usability. Consider word processing, accounting, invoicing and inventory; these are the basics of business and are readily available in a variety of off-the-shelf products.

Across the various vendors, these products effectively do the same thing in pretty much the same way. The functionality required for accounting or invoicing or inventory is, for the most part, static. There is little opportunity or need for embellishment. What separates each product is what's on the outside, not what's under the hood.

While it is important that the core processes work correctly, these functions do not make the system useful or desirable or comfortable. It is the ability to make use of the core processes that wins the hearts of users. And, it is this aspect of system development that is often pooh-poohed by developers.

The windshield wipers on a car appear pretty simple and straight forward, until you attempt to devise an alternate operation. On most cars, the wipers are aligned with one at the edge of the windshield on the driver's side and one near the middle of the windshield. Both move in the same direction at the same time at the same speed. This clears the windshield parallel to the edge on the driver's side, but leaves an untouched corner on the passenger side.

Now, you could change the passenger side wiper to operate opposite the driver side wiper and thus clear to the edge of the passenger side. However, then you've moved that uncleared triange to the middle of the windshield, which is probably not so very good.

But, if you were to overlap the areas that the two wipers cover, you could possibly eliminate a large part of the uncleared area. Of course, then you'd have the problem of synchronizing the two wipers so that they didn't collide. They could not move at the same speed or even in the same ryhthm since that would put them in contention with each other for the overlapped area.

There is a solution, but it's not simple.

The windsheild wipers are not integral to the operation of a car, but they do make the operation easier under certain circumstances. It's worth noting that an selling a car without windshield wipers, or with those that didn't clear a significant area of the windshield would probably be rather difficult.

Software is not so different. What makes one piece of software more desirable than another is not how well it adds numbers, but rather in how it displays those numbers, or makes them accessible. We're not talking grand and glorious bells and whistles here, but smooth edges and straight lines.

The folks who use software want to be able to complete their tasks with as little complexity as possible. Users typically what as much information as they can get with the fewest number of steps. Software that provides these things makes their jobs easier. There is little worse for a user than having to struggle with an uncooperative program. It slows them down and creates unnecessary stress.

Developers need to be ever aware of the fact that the purpose of their product is to allow others to do their jobs more effectively and more efficiently. Software is a tool to be used and while it may be a craft, it is not an art.

As common as this perspective seems to be it is remarkable how many developers remain indifferent and sometimes hostile to those who use their software. By the same token, it is surprising how many users will tolerate cumbersome software believing it's the best they can get.

On the other hand, users should be aware that there is a cost in making their software easier to use. Whatever is seen on the screen requires a programmer somewhere to put it there and to write the code to make it meaningful. Just like there is a fair amount of engineering involved in windshield wipers, there is always complexity behind the simplicity the user sees.

In the end, however, the system that is in harmony with the needs and practices of the user is the best product. Software that helps rather than hinders can allow users to do more work in less time. The end result is greater productivity, more accuracy and better decisions. Cheaper is not always better and the (apparent) little things do make a difference.

A business without technology is standing still at best, and too often, waiting to die. In this day and age, that should be painfully obvious even to the most casual observer. And, most businesses do employ technology at some level. However, too often, it's at the wrong level.

It is surprising how many businesses continue to see technology as a cost center; a necessary expense. When techology is evaluated in the same way as office supplies it demonstrates a limited understanding of the potential of technology as an active contributor to the growth of a business.

"We're not in the technology business," is a common sentiment. Maybe not, but technology is in your business and it can bring growth if done right and death if done wrong. Technology is not passive like a typewriter or adding machine. Technology is active and influential, much more like a good employee.

In earlier times, techology was grouped with office equipment such as typewriters, adding machines and copiers because it was new and most folks didn't quite know what to do with it. Combine that with the limited capabilities of technology and you have a cost center.

Today, the capabilities of technology are limited only by imagination. The performance of the equipment and the availability of software combined with the interconnectedness provided by the Internet make technology a tool waiting to be used.

Still, old habits die hard. Too often, technology is viewed as a solution to a specific task rather than an integral component of the business. Technology is still seen as the single function hammer rather than the multi-purpose Swiss Army knife. In many businesses technology is restrained, not by inability, but by ignorance.

Ignorance of technology should not be news, but it often is. Rapid Application Development, Agile Systems and the nephew who's a wiz at computers have given the false impression that technology has become a commodity. This erroneous belief causes many business people to think that they know everything they need to know in order to effectively use technology.

Many, if not most, business people are wrong. Technology is complex. Technology makes use of intricate techniques (some might say magic) to make tasks appear simple. "Just click on the button and your order is complete," seems like a simple task to perform. Yet the technology behind that button takes into account numerous variables and conditions in order to effectively and efficiently complete the order.

Simply getting the job done is not good business, yet that is how technology is often used. A hammer can drive a screw, but a screwdriver is a better tool because it makes use of the unique characteristics of the screw to make a more secure bond. Technology and business are no different. Matching the right technology to the current business plan can make the difference between a leader and a business that merely says, "me too."

Technology, to be effective, needs to be part of the business planning process. The days where business objectives could be identified and then thrown over the fence to the technology department are a thing of the past. Technology needs to be at the planning table. Just as there are complexities in business management that require expertise, there are complexities in technology that require the same level of expertise. And just as it's mistaken to expect technology people to know all the nuances of business, it's foolish to think that business people can know the nuances of technology.

Technology has grown and matured to the point where it belongs at the adult table. It has knowledge and insight to contribute to the conversation. Technology is more than a typewriter and the wise business will use it to its fullest potential.

They say that numbers don’t lie. However, I’ve found that they can be pretty cooperative when there’s something you really want said.

AberdeenGroup has recently published a Supply Chain Finance Benchmark Report exploring the various mechanisms available to make supply chain financing more effective and efficient. The report presents the advantages of creatively financing the supply chain compared to the problems that have arisen from historically attempting to get blood from a stone.

The details of supply chain cash flow are pretty well covered in the report and I won’t restate them here. Suffice it to say, that it is clear that financing in the supply chain needs to be a strategic consideration as opposed to a supporting task.

Within the wealth of information contained in the report, there is a statement of the type that has always struck me as a tad misleading. The report says:

Although early discount programs are a short-term fix for cash-constrained suppliers, they come at a heft cost. For instance, a “2% 10 net 30” term is equivalent to a 36% annualized return on cash. While this is a risk-free use of cash for buyers with a great rate of return, many larger suppliers will find the rate unacceptable.

On the surface, this sounds fantastic. A 36% return on cash is, without a doubt, good money if you can get it. The question is, who gets it? The statement would have you think that buyers are getting significant savings, and the suppliers are giving up significant profit. Is that really the case?

Before continuing it might be best if I say that I don’t know how 2% becomes 36% in the above example. I cannot make those numbers work with any math I’m familiar with so, we’ll change the 2% to 1% giving us “1% 10 net 30.”

So, paying every 10 days over the course of a year gives us 36 payments with 1% savings on each payment totaling 36%. That seems to be the simple an obvious interpretation. And, the math could work if a couple assumptions were valid.

Assumption 1: The buyer pays 36 invoices a year every 10 days. While this is surely possible, it’s typically not going to happen. The report says that the industry average for days payable outstanding is 49, which makes it difficult to get 36 payments in per year.

Assumption 2: The buyer uses the same funds to pay every invoice. This is the only way in which discounts can accumulate. A lender may lend funds and have them repaid every 10 days which means that they can use the same funds 36 times, each time gaining 1% and having a return of 36%. A buyer on the other hand does not have the ability to reuse funds to pay invoices. Once the funds are deployed, they are gone. The discount stands alone.

Effectively, what we have with discounts from sellers to buyers is a simple opportunity to pay less for products. The buyer who takes a discount saves only the discount amount. Taking 1% off every invoice paid does not increase savings beyond 1% no matter how many invoices are paid. Paying 10 invoices of $100 minus 1% is 10 payments of $99 for a total of $990, while paying 1 invoice of $1000 minus 1% is $990. The end result is the same; the buyer has saved 1%.

By the same token, the seller who offers a 1% discount does not lose any more than 1%. Again, regardless of how many invoices are paid. At the end of the day or the end of the year, the seller has 1% less than the invoice amount.

The perspective of the report is that receivables financing, through early payment or factoring, is expensive. It may well be when compared to what some sellers can get as a cost of funds. However, those rates are not readily available and it makes no sense to compare what can be had to what cannot.

Mike Semanco, a very competent factor has this to say:

“If a company is looking to land a $1.2 million / year contract and can only do it by using receivable acceleration and paying 2% for 30 day use of $100k that means they would pay $2k per month to finance $1.2 million of new business. $24k is a cost, just like labor and other variable expenses, that is necessary to make the contract work. The alternative is to say “no” and forget your profit on $1.2 million of new business and potentially never see a piece of business from this customer again. Let’s just say that the margins are 25% on $1.2 million. To pay $24k in return for the opportunity to net $276k is a no brainer.”

The potential loss is greater than the actual cost. And, the actual cost (2% in the above example) is less that the perceived cost (24% according to some). The bottom line seems quite simple, if you pay 2% on every transaction, no matter how many transactions there are, you’ll still end up with 98% of what you expected. Don't let imaginary numbers make decisions, it's the real numbers that give you something you can work with.

Why we certainly do! InStream Financial performs extensive unit and system tests to verify each major release prior to its introduction to the real world. Before we delve into how we actually test the software at InStream Financial, lets get some terminology/misconceptions and definitions out of the way first (this is the really boring stuff, but it helps later). Lets start with Software Testing and Software Quality Assurance…….

Software Testing and Software Quality Assurance are not one in the same

These two functions are about as related as Hillary Clinton and George Clinton (and the P Funk All Stars). Software testing is actually a part of the software development team and performs the function of comparing the software’s actual output against what is expected. Software Quality Assurance (SQA) documents and audits the processes and procedures used by the development team to create the end software product. SQA would never report directly to a development team (definite separation of church and state here!).

So let’s get back to testing (that SQA thing sounds totally unnecessary), how are tests performed?

Whoa, hold on there pilgrim!! SQA is as critical (if not more so) to a successful software release as software testing. SQA at InStream is a bit less stringent than you will find at other organizations. The reason for this is simple, due to the both the quality and number (or lack thereof) of resources we have here, the majority of bureaucratic paperwork overhead is completely unnecessary. Each release, whether it be a hot fix (hold onto that question till later), or full release, is sufficiently documented to know what was released and why.

Without this process, the releases would take longer to get to production, and what made it to production would not be pretty (see our early releases back in the fall of 2004).

OK, so SQA has it’s place, but what about testing?

InStream performs Unit (White Box) and System testing (Grey Box). The reason we use Grey Box as opposed to Black Box is to better see what the system is doing……………

Black Box, White Box, Grey Box...huh?

With apologies to Dr Seuss, these terms in software testing relate to how much of the code the software testers can actually view. In White Box testing, the testers can view the code/database they are testing against. In Black Box testing, the testers will be testing against the requirements of the system (with little or no view into the code/database). Grey Box testing allows for some view into the code/database they are testing against. InStream uses a combination of White Box testing (unit tests), and Grey Box testing (system tests).

Unit Tests, System Tests?

Unit testing looks at the code in detail and verifies each individual piece of the software separately (sorta like putting the code under the microscope). System testing brings all these pieces together and verifies that the software functionality matches with the base requirements of the business or user (makes sure money is advanced, payments are taken, etc). It essentially recreates what is done in production over a series of days to verify that everything is in working order.

Both testing methodologies are best served if a library of tests that is constantly added to is kept (regression testing). You would be absolutely amazed at how many times a change is made to the system, and that change breaks another function or rule within the system.

This sounds way to complicated and lengthy, can’t we just grab a copy of the production database and verify the reports?!?

Yes you could, and this form of testing is known as “suicide”. As amazing as this might sound, the reports are actually on a lower priority to test than the day to day batch jobs that load data, advance money, and accept payments. That’s not to say the reports aren’t tested and verified, but if any of the batch jobs fail to perform their assigned task, the reports (and system) are worthless.

OK, but doesn’t all this testing take a long time?

Not necessarily. Once again, automation and standardized processes save the day (had to slip that one in). All of the unit tests are completely automated. The system test is a standardized process that can be completed in less than a day, assuming there are no issues. If you know what’s going in, and what should come out, and have that documented, the process goes quick!

This is getting kinda interesting, is there more?

Ah yes, there is much more, but that is for another time.

I've often found that learning how not to do something is just as valuable as learning how to do something correctly. I was reminded of this after reading an article in DB2 magazine given to me by a co-worker. The article, titled XML Programming with PHP and Ajax, explained how one could quickly develop web applications using Ajax, PHP, and the new XML features of DB2 9. As the developer of a web application built in PHP I figured the article would provide me with some insight into how I might bring our application into the world of Web 2.0.

After reading the first few paragraphs explaining all the benefits that this new blend of existing technologies would provide I was eager to get to the examples showing how this all works in “the real world.” The article uses a web-based insurance policy request form as an example. But before we get to the “really cool” stuff, let me outline the old fashioned, Web 1.0 implementation -- in other words, how our application in its current form would go about such a task.

First, the web browser makes a request for a web page called newPolicyRequest.php. On the server the script instantiates a new InsurancePolicy object. Because this object knows it isn't based on any data from the database, it must be a request for a “new” policy. Since the object is also able to present itself in HTML, it knows how to generate the form elements for all the required data. This generated HTML is sent back to the browser where the user fills in the necessary information and hits the “submit” button. Input is sent back to the server, where the InsurancePolicy object parses the input fields and builds the necessary stored procedure call to send to the database.

In summary: the browser requests a page, a form is generated, the form is filled out, the data is sent to the server, and the information is written to the database. Although this is very straightforward, it is, nonetheless, far too Web 1.0. The aforementioned article proposes a much “cooler” way to achieve the exact same thing. It must be cooler because it uses Ajax.

Now let's examine the Web 2.0 method. The web browser makes a request for a web page called newPolicyRequest.php. This page generates some HTML that represents the policy form which is sent back to the browser. This HTML also contains some JavaScript which instructs the browser to immediately make an Ajax request back to the server for XML that represents the new policy. This XML contains all the elements -- initially empty -- required to represent an insurance policy. The user then fills out the same form as before but this time, upon hitting the “submit” button, JavaScript grabs the form data and populates the previously empty XML elements using the DOM API. Another Ajax request sends this completed document to the server where a PHP script inserts the (now complete) XML into the database. The column where this data goes is of type “xml” so that it can be queried using XQuery later on. Never mind that we're still working with a relational database underneath.

In summary: the browser requests a page, a form is generated, the browser requests a blank XML document, the form is filled out, the XML is populated on the client-side, the XML is sent to the server, and the XML is written to the database. Not only is this more “service-oriented” and Web 2.0 than the “old” way of doing things, but it has the added benefit of extra HTTP requests and more dependence on the client. Awesome!

The bottom line is that we've now found a way to make a perfectly sound process much more “brittle.” We're now relying on the client to support the latest and greatest JavaScript specification (XMLHttpRequest, DOM, etc.). We've added at least one extra trip to the server and back. We've encapsulated one data structure (XML) inside another (RDBMS). And the client doesn't notice one bit of difference in their experience – unless of course something doesn't work as it should.

I first noticed this movement towards unnecessary complexity in the excessive (mis)use of JavaScript on the web. All too often developers seem to use it because it's the “cool” way of doing something – not because it's required or adds any sort of functionality. Why do we need to simulate a simple, proven, and well-supported feature of HTML like hyper linking with JavaScript onClick() events and browser redirects?

I'm not arguing that JavaScript and its cousin Ajax don't have their place on the internet. There are some very slick and well designed Web 2.0 applications out there (Google Maps is one of my favorites). But these applications achieve things that would not otherwise be possible. Put another way, they use Ajax to enhance the user experience rather than simply replace something that already works.

So when is it appropriate to make use of these (or any) new technologies? My boss often says he won't upgrade or patch existing software installations until there is a “compelling reason to do so.” Web 2.0 is no different.

I spend a fair amount of time helping out in various newsgroups on the internet. Most of my activity takes place in PHP forums, but, because of the strong ties between PHP and MySQL, I find myself answering a lot of MySQL questions as well. Because I don't use MySQL on a regular basis, I often need to refer to the documentation to find the answer I'm looking for (well, really the answer that somebody else is looking for). More often than not I come across a feature of MySQL that is unique to the platform in addition to being just plain cool.

After finding enough of these gems, I feel compelled to share some of my favorites. Some are extensions to the query language, while others are broader features of the server itself. I'll admit that many of them violate some basic rules of the relational model, but -- unlike some people -- this doesn't bother me. This is particularly true when the additional functionality provides a convenient solution to a common real-world problem.

In no particular order, here are my top ten favorites.

1. You don't need to group by every single non-aggregate column

Anyone who's been writing SQL for a little while can appreciate this one. Standard SQL requires that every non-aggregate column in the select list also appear in the GROUP BY clause if you are aggregating even one column. Forgetting to list a column in both places produces less than desirable results -- usually manifested in the form of a cartesian-style join with millions of rows in the result. Consider the following query, where we want all the columns from a payment table and the sum of it's payment lines from a child table. Standard SQL requires the query to be written as follows:

select p.paymentKey, p.payorName, p.payeeName,
p.effectiveDate, p.depositDate, sum(pl.amount) amount
from payment p
join paymentLine pl on p.paymentKey = pl.paymentKey
group by p.paymentKey, p.payorName, p.payeeName, p.effectiveDate, p.depositDate


Notice that every non-aggregate column in the select list also appears in the GROUP BY clause. But, being a human who is familiar with the database schema, you know that those five columns all come from the same underlying row. MySQL produces the same result with the following query:

select p.paymentKey, p.payorName, p.payeeName,
p.effectiveDate, p.depositDate, sum(pl.amount) amount
from payment p
join paymentLine pl on p.paymentKey = pl.paymentKey
group by p.paymentKey


In addition to being much less tedious to write and maintain there is a performance improvement. This is because the database is free to choose any value from the group instead of computing each group individually (espeically since each group only has one member anyway). Of course this feature should be used with care -- if the additional columns are not truly "one-to-one" with the column in the group by clause, the results will be unpredictable.

2. Distinct counts on multiple columns

Standard SQL supports the use of COUNT(DISTINCT col_name) which will count the number of distinct values in the column col_name. MySQL supports the couting of distinct tuples such as COUNT(DISTINCT col_name1, col_name2, ...).

3. The REPLACE keyword and alternatives to duplicate key violations

MySQL has a REPLACE keyword that eliminates the need for a separate "existence" check. REPLACE is similar to an insert statement but will automatically perform a delete first, if necessary. It works like this:

1. Insert a row into a table
2. If a primary key or unique constraint violation occurs:
   1. Delete the row who's unique columns match the values from the inserted row.
   2. Insert the new row.

A similar and equally cool construct is the ON DUPLICATE KEY UPDATE clause which can follow a normal INSERT or UPDATE statement. If the INSERT or UPDATE fails because of a duplicate key or unique constraint violation, the ON DUPLICATE KEY UPDATE is performed instead. The columns specified here can be different from those specified in the original INSERT or UPDATE and can even take on different values.

In our case, when we load payables, we first check if the payable already exists. If not, we insert it, otherwise we simply update the payment date. The SQL currently looks something like this:

select payableKey
from payable
where payorKey = @payorKey
and reference = @reference

if @@rowcount = 0 begin
insert payable (payorKey, payeeKey, reference, amount, payableDate, paymentDate)
values (@payorKey, @payeeKey, @reference, @amount, @payableDate, @paymentDate)
end
else
update payable
set paymentDate = @paymentDate
where payableKey = @payableKey
end

Using ON DUPLICATE KEY UPDATE these three statements can all be combined into one:

insert payable (payorKey, payeeKey, reference, amount, payableDate, paymentDate)
values (@payorKey, @payeeKey, @reference, @amount, @payableDate, @paymentDate)
on duplicate key update paymentDate = @paymentDate


4. Functions, functions, and more functions

MySQL provides a lot of functions that other DBMS do not. While there are too many to list here, some examples are:

• Math functions like cos, sin, log.
• Aggregate functions (stdev, variance, bitwise operators). Try computing the standard deviation of a column using standard SQL.
• Encryption, hashing, and compression functions
• Tons of string and date handling functions.

Check them out at http://dev.mysql.com/doc/refman/5.1/en/functions.html.

5. Modular Storage Engines

MySQL implements a "pluggable storage engine" model. Several different storage engines are included, and you can even write your own (the API is publically available). Some engines are optimized for transaction processing while others are optimized for data warehousing. Some even store the data completely in memory, and yet others use CSV files to store the data.

Perhaps even more important is that storage engines can be assigned to individual tables within a single database. This allows tables to be physically stored in a way most optimal for their role within an application.

6. DATE and TIME datatypes

Most relational databases offer several datatypes for storing temporal information (usually DATETIME and SMALLDATETIME). But these types store both date and time information, regardless of whether you actually need both. In addition to wasting storage space, this often complicates queries and decreases query efficiency by requiring the use of various functions to make comparisons and assignments.

MySQL offers the DATE type (which stores only a date) and the TIME type (which stores only the time). Of course, the traditional DATETIME is also available.

7. GREATEST, LEAST, and INTERVAL

Standard SQL doesn't allow the use of normal aggregate functions (such as sum, min, and max) on lists of items. MySQL provides the GREATEST, LEAST and INTERVAL functions which do just that. So, SELECT GREATEST(5, 2, col1, 7, col3) returns the largest value out of that list. LEAST does the opposite. INTERVAL will effectively perform a binary search on a pre-sorted list of numbers. So INTERVAL(N,N1,N2,N3,...) returns 1 if N < N1, 2 if N < N2, etc.

8. The ENUM and SET datatypes

Standard SQL doesn't provide a straight-forward way to create a datatype who's values must be an element of a pre-defined list (the alternative is to create a type and add a check constraint). MySQL allows you to define a column in this way using the ENUM type, then refer to the values either by the underlying integer or the "friendly" name assigned. The SET datatype extends this idea by allowing a single column to include any number of items from the list. Functions are provided to easily count the number of items or check if a single item exists in the list.

9. Everything that everyone else has

In addition to offering all sorts of language and server extensions, MySQL provides all the functionality that you'd expect from any other DBMS. Explicit transactions, foreign keys, defaults, views, triggers, stored procedures, and clustering are all supported.

10. MySQL is open-source

MySQL is freely available as is its code. You can hack it up and change it as you see fit. API's are published for things like storage engines so you can extend the system as necessary. The online documentation is complete, up-to-date, and contains myriad user comments. Along with the open-source comes the open-source community. I'm not surprised that MySQL provides the functionality described in the previous nine points while other "commercial" DBMS do not.

There is a customary progression of responsibility in the software development world that appears quite reasonable on the surface. This progression starts in customer support, moves into development, then to analysis and design and eventually lands in technical management. Now, after 30 plus years in the industry in a variety of businesses and environments, I’m no longer persuaded that this is the most effective deployment of resources.

It is difficult to argue with the value of development experience prior to analysis and design responsibilities. A good design requires a working knowledge of the tools and resources available to accomplish the task which is best acquired through experience.

And, there is little to debate in placing technical management as the final destination since, again, the knowledge and insight gained through previous experience is a valuable commodity. Any technical manager without a technical background is at a distinct disadvantage because ignorance is a dangerous vulnerability.

Development moves to design which moves to management. This progression is as natural as learning to walk before trying to run. Each step builds on the experience of the previous and results in a more effective resource. The step missing, or misplaced, in this progression is customer support.

Customer support is the red-headed step-child of the software business. It gets little respect, minimal funding and is often devalued and frequently ignored. To some extent this distain is justified because customer support is often quite dismal. When users voice their dissatisfaction it is rarely with development or even design. The prevailing complaint is, “support stinks.”

Business does not exist without customers. These customers may be either external consumers or internal users; both provide the justification for a service or product. In the current context that product/service is Information Technology.

As any good business person knows it is important to keep the customer satisfied. The danger of a dissatisfied customer is a loss of revenue from external customers and process sabotage from internal users. Customer discontent can be disastrous to your return on investment.

Some may think that the word sabotage is a bit harsh to apply to unhappy users, but what else is it? If a software system is designed to guide and assist a business process and a user circumvents that process because they cannot get the help they need in a timely manner, what else could it be other than sabotage? Malicious or not, unsupported or poorly supported users can be very creative when it comes to getting around a problem. And, this practice can cause the entire business process to become unstable, unreliable and unproductive.

Enter Customer Support.

The common practice of putting the most inexperienced and least knowledgeable people in customer support is possibly the main reason customers cry, “support stinks.” How else could it be? By placing junior personnel in such a volatile position the credibility of any system is compromised and the belief that “support stinks” becomes a self-fulfilling prophecy.

There are two main arguments for initiating the technology progression with time in customer support; educational and financial. I have come to believe that both are unpersuasive.

Those presenting the educational argument claim that customer support duties introduce junior personnel to the workings of the system. They learn about flaws and misuses first hand from less than happy users. From this experience, the argument contends, those coming from customer support have insight into how to make the system better.

There is an obvious truth in this view that overshadows other considerations. That customer support people learn about flaws cannot be denied, but it is important to realize that this education comes from people who are not predisposed to providing insight into the system. People who contact customer support are people who want their problem fixed. These are not people who are looking to educate someone on the values of the system or to offer objective suggestions on improving the system. Customer support people are presented with vastly more negative than positive input.

Additionally, those in customer support as an educational experience often lack sufficient knowledge of the system to allow them to offer alternative solutions or to accurately recognize if the complaint is the result of a problem or misuse. This ignorance significantly contributes to the perception that “support stinks” and actually diminishes the educational value of customer support experience.

The financial argument is a bit more straightforward. The less experienced person may take twice as long to resolve an issue than a senior person, but they cost less and thus are cheaper in the long run. Again, the truth seems obvious, but the math is not quite right.

Consider this math. A junior person costs $25 per hour and takes 1 hour to resolve an issue. A senior person costs $50 per hour and takes a half hour to resolve the same issue. On the surface, you can pay $25 to resolve the issue, or $50 to resolve the issue. Of course, you choose $25. However, if you do that you’ve missed the fact that since the senior person only took half the time to resolve the issue, the cost is the same. And you’ve also missed the fact that while the junior person is still working on resolving the initial problem, the senior person has already moved on to another issue, thus providing more support. So, from a cost standpoint, you can pay a junior person $200 to solve eight issues per day, or you can pay a senior person $400 to solve 16 issues a day. The cost per issue is the same, but the number of issues is drastically different. To maintain the same productivity of the senior person you’d have to hire two junior people and as a result you haven’t really saved a thing, you’ve simply increased your head count without increasing your productivity.

An insightful colleague or mine maintained the belief that every developer should be forced to use any system they develop. This practice is designed to foster insight into the business application and a bit of sympathy for the end user. A developer that claims to have solved a problem but has never experienced the problem is a lot like claiming to walk on water without ever leaving the boat. There’s a certain lack of credibility.

Based on my experience, I am convinced that customer support should be placed after development in the progression. This provides the users with people who are knowledgeable and allows developers to experience their work in action. From this sequence the step into analysis and design becomes more natural since experience with the use of the system is more recent and thus more current with the business process.

Some with argue that starting in development without support experience is a detriment to productivity. Experience says otherwise. Development is always under the direction of more senior personnel regardless of previous experience. And, as mentioned earlier, customer support experience is predominately negative and rarely provides insight into the context of the system. To move from customer support to development wastes much of what little knowledge is gained, whereas to move from development to customer support capitalizes on the previous experience.

Customer support is the interface between customers/users and the developers. It not only provides the ongoing relationship between the two, but also is best positioned to learn the direction of the market. As such a pivotal service, it is best not to staff it with those least experienced and knowledgeable.

There is an adversarial relationship within businesses today that refuses to go away. Depending on your orientation and position this conflict expresses itself as either, “The tech group is uncooperative and unresponsive,” or “Users are stupid.”

Yes, we’re all on the same team and we all have the same goal, but its time to admit that when we’re each in the safety of our own kind, in the protection of our own group, we believe that if “They” would just see things our way thing would go a lot better.

The tech group needs to understand the fact that without users, they would be out of a job. Without a consumer, there is no reason for their product. Users, on the other hand, should remember that without technology they would be doing their jobs with pencil and paper. The amount of work they do would be impossible without technology.

It’s about time we crossed the dance floor, picked a partner and started to dance. The view of the others as an enemy, or a necessary evil, needs to be put aside and replaced with appreciation for the part that each side plays in a successful enterprise. Users need to realize that not every error is a “computer problem,” but sometimes is actually a mistake in the use of the program. Technology folks must give up the notion that they know what’s best when it comes to computers.

Users, generally, know their job. They know what they need to do to accomplish the task set before them. More often than not they also know the most effective way to do their job. It is users who are charged with getting things done. It is users who are accountable for the accuracy of information. It is users who have to interact with customers, both external and internal.

Unfortunately, users often don’t fully appreciate the interactions between the steps they take to do their job. As a result, users frequently have a difficult time explaining why a certain part of the process is necessary. This causes frustration when dealing with technology folks because they cannot always translate their jobs into identifiable processes.

Additionally, users often forget about information that they “just know” when describing processes. This information includes things like customer credibility that they’ve learned over time, or a subtotal in a calculation that they’ve written on a scrap of paper somewhere; information that allows them to make decisions that is not obviously apparent.

The familiarity users have with their work often makes them blind to much of the complexity involved what they do. This intimate knowledge causes requests that seem simple on the surface to be met with a bit of resistance from the technology group. Just as moving a window in a house, moving a field on the screen requires some re-engineering.

Now, technology, contrary to the belief of some, is not mechanical. Technology is not an art. Something mechanical follows specific rules and is repetitive. The rules dictate what action will be performed each and every time a situation occurs. Art, while also having rules (of some sort), is never repetitive. It is a unique expression in every occurrence. Technology is a craft.

Like a mechanized process, technology can be repetitive. The difference is that the repetition is by design for efficiency and not defined by the rules. Like art, technology is an expression but the reason for the expression is effectiveness. Technology is a craft that, when done correctly, allows users to effectively and efficiently perform their required tasks.

As with any craft, those who work in technology need to maintain some rather exotic knowledge such as, “How big is an integer,” or “How many characters are in a name.” To a user this appears to be inconsequential information, yet in the world of technology this type of information could be the difference between success and disaster.

When a user asks to have a field moved on a screen, all they generally see is a box disappearing from one place and showing up in another. In the technology world, that simple move requires a series of modifications that not only define the new position of the field, but also modifications to every part of the system that may access that field. The levels of complexity beneath the appearance of a field on the screen can cause a cascade of modifications throughout a system. As a result, technology people are often resistant to moving things without some justification.

As it turns out, technology is not really uncooperative and unresponsive, but concerned with making unnecessary changes in a carefully balanced and complex environment. And, users are not stupid. Instead, they are looking for the best way possible to get their work done with accuracy and confidence.

Because users generally know their job and know what they need to do their job they are the best source of functionally requirements. A user can say with confidence that they need such and such information and it is used for such and such and it comes from such and such. However, for a user to say that a certain technology should be used, or to attempt to define the effort involved is beyond their scope and knowledge.

Technology is best equipped to design and build the tools required to provide the information that users need. It is their natural environment and they have the knowledge and skills to identify the most effective method for providing the required information. It is somewhat arrogant if technology replies to a request by saying that the information is unnecessary. Without the demand to perform the functions of the users, technology is in no position to declare a request invalid.

It is quite remarkable that with the prevalence of technology in business today that there still exists a noticeable divide between users and providers. Yet, recognition of the necessity of both parties and an understanding of the motives of each will go a long way to a more production relationship.