The Diablog - it's Diabloglical™

Technology can make you or break you.

– Robert Kruger

26 January 2010

Technology is inseparable from business. It doesn’t matter what business you’re in - you need technology. Back a few generations, all a ditch digger needed was a shovel, a strong back, and an equally strong will. If you dig ditches today, you probably use a laser level to measure the grade. If you want to grow your ditch-digging business, you’ll also need a backhoe. Or would a frontend-loader be a better choice?

I can’t answer that question, so I’ll ask another. How do you choose?

Business decision-making is closely tied to business success, and technology impacts many of those decisions. Here are some suggestions for making good technology decisions.

Only invest in technology that is appropriate for your business.

I recently remodeled the kitchen in my home. The company that installed our granite countertops is an example of how you should not invest in technology. The company makes countertops out of stone, so they invested in a very expensive machine that cuts stone with water. The owner thought that it would shorten the time needed to cut each countertop. He told me that he has owned the machine for over a year, but has only used it a couple of times. It turns out that the set-up time to cut each piece takes as long as it takes to cut a piece of stone manually. Here’s what went wrong. The machine was designed to cut multiple pieces of stone to exactly the same size and shape, including wildly non-rectilinear shapes. If you’re wrapping the outside of a 40-story building with granite panels or creating an ornate floor in a train station, the set-up time is offset by the efficiency gained by quickly cutting hundreds of identical pieces. A company that makes granite countertops rarely cuts two pieces with exactly the same dimensions, and most of the cuts are square. The technology of a waterjet cutter sounded cool, but it was intended for a different industry.

Never allow low-level or short-term employees make long-term technology decisions.

Here is an challenging situation for a business owner. If you micro-manage employees - or make every decision that comes along - your business won’t thrive. People need to feel like they have some turf that is theirs to defend. You don’t want employees sitting on their hands waiting to be told what to do. Successful companies commonly have decision-makers at all levels within the staff. However, high-level staff or owners need to make the long-term decisions. I can’t count the times a business owner has told me how their company’s website doesn’t work and the low-rung employee who built it is no longer with the company and no one knows how to fix it. In the American work environment, more career advancements occur by changing employers than occur by working up through the ranks at one company. That bright, young newbie in the I.T. department will probably become a manager, but the odds say they will be a manager for someone else. Technology that could affect business operations for longer than the current year should be specified by people with a stake in the company.

If your company is growing, utilize technology that can grow with you.

You don't need to buy if you can scale. Don’t spend your money up front for technology you assume you will need in the future. Look for solutions that allow you to buy only what you need today, but can be scaled up efficiently and effectively as needed. If you’re considering a high-dollar technology purchase, before you sign that P.O., look around for a scalable alternative.

Make consultants prove themselves.

Many years ago, I went to work for a new company. Several months before hiring me, the company had hired a consultant to help them transition a paper-based distributor network to an online-based operation. One of the projects managed by the consultant was a training video. On my second day with the company, I was invited into a meeting with the consultant. The meeting was slated as a video pre-production meeting - the video was due to be presented at a national sales meeting in two weeks. The consultant presented some general topics in a Powerpoint presentation. At they end of the presentation, they asked for feedback. I asked if they had ever produced a video before. My boss was shocked that I would say something like that. He was then even more shocked to learn that the consultant’s answer was, “No.” I was the only person in the meeting with video production experience, so I was the only one who knew that by that point in the schedule, there should have been a tight script, if not raw footage in the can.

More recently, I was in a meeting about a website project. My contribution to the meeting was to provide information about Dialogs to the team. The site owner had hired a variety of experts to work on the project. One was an SEO expert. I had no prior knowledge of this particular agency, so after the meeting I did a little research. I ran the SEO expert’s URL through Website Grader (www.websitegrader.com). The expert's own website scored less than 50 (out of 100).

The point of these stories is not to imply that all consultants are ignorant charlatans. The point is: some are. If you don’t know enough about a technology to make a solid decision, you need to get help. Getting the right help can be a challenge. It is easy for a consultant to claim expertise, particularly to someone who has no experience of their own. It’s hard to prove expertise if the consultant doesn’t have it.

Finding a trustworthy source of information can be as difficult as making the technology decision itself. Here are a few tactics that may help.

• Interview multiple consultants for the same issue. You may gain insights from one consultant that outs another.
• Review portfolios and case studies. Ask to see examples of solutions that match your issue.
• Ensure that the firm you hire has the expertise you need at the time you hire them. Past successes don’t necessarily mean current capabilities. If you see a case study you like, confirm that the people responsible for that project are still with the firm.

Make the right choice every time.

Technology decision-making needs to be a clearly defined process. Don't leave technology choices to chance.

Our experience building Dialogs-powered websites has shown that today, you need internet technology to survive. Let us show you how Dialogs is not only a creative tool but also a powerful, scalable business solution. Plus, Dialogs Professional Services is a proven, reliable source for information about how to work the web, and we can prove it.

Sometimes it's OK to break the rules.

– Charlie Brown

12 January 2010

Website content in Dialogs is defined by information structures we call “Lists”. Each List corresponds to a MySQL table within the Dialogs database. Dialogs presents a simple interface to the developer for List creation and maintenance so developers don’t have to directly interface with MySQL unless they want to. For those more technical developers wanting to understand how to optimize content maintenance and website performance, some basic SQL skills and some insight into how Dialogs List Templates are used to map database fields into rendered pages goes a long way.

It is quite common for data in one Dialogs List to be related to another. Imagine a List of Artists and a companion List of the art they’ve created. Relational database theory defines a certain way to manage that interrelation according to something called third-normal-form (3NF). Among other things, 3NF states that no information should be duplicated in both tables. Is that really a rule that shouldn't be broken? In the days of expensive storage and crude data handling tools, it sure made sense. Adhering to 3NF, however, makes for unnecessarily complex SQL within Dialogs List Templates, something that for efficient development and ongoing maintenance we'd like to avoid. Here's an example to illustrate the problem. Lets say you have these two tables:

Artist
item_id	item_name
1	Vermeer
2	Rubens
3	Michelangelo

Art
item_id	item_name	artist_item_id
1	The Milkmaid	1
2	Hippopotamus Hunt	2
3	David	3
4	Sistine Chapel ceiling	3
5	Pieta	3

The relationship between the tables is obvious. The 'artist_item_id' field 'links' to the item_id of the 'artist' table.

If you want to display the art that's easy:

SELECT * FROM art

... but if you want to include the name of the artist it's this mess:

SELECT art.*,artist.item_name AS artist_item_name 
FROM art LEFT JOIN artist ON art.artist_item_id=artist.item_id 
WHERE artist.item_id IS NOT NULL

Yuck!! And it's worse than that. If you want to specify a sort you can't just say

ORDER BY item_name

you have to remember to prefix the table name and the same goes for anything in the 'WHERE' clause as well.

It's time to go off the reservation. If we break from the 3NF rules and add the artist's name to the art table we would get this:

Art
item_id	item_name	artist_item_id	artist_item_name
1	The Milkmaid	1	Vermeer
2	Hippopotamus Hunt	2	Rubens
3	David	3	Michelangelo
4	Sistine Chapel ceiling	3	Michelangelo
5	Pieta	3	Michelangelo

Super! Now we're back to

SELECT * FROM art

... and we have the artist's name! The only problem is, if Michelangelo's name is misspelled, and someone changes it in the 'artist' table, it will still be wrong in the 'art' table. This is where Dialogs shines. All we have to do is add one line to the list automation script which gets run for every edit to a list item. This one line will update the art table and keep the artist's names in sync with the 'artist' table:

$this->query("UPDATE art LEFT JOIN artist ON art.artist_item_id=artist.item_id
  SET art.artist_item_name=artist.item_name");

Cons:

1. Causes baldness in database purists.
2. Wastes hard drive space.

Pros:

1. Easy to implement: add one more field to the list, add one line to the automation script.
2. Dead simple list templates because all the fields you need are there.
3. CSV and XML exports have all the fields you need too.
4. Hard drive space is beyond cheap.

Dialogs is a real-world development tool for the professional web developer. We developed Dialogs with the belief that successful deployments either follow best-practices or define them. So go ahead, break the rules. We won't tell your database theory professor. For more detailed description of how to do this in Dialogs see the Knowledge Base Article.