L-P Huberdeau's blog

I just caught this term out of an article by Adam Bosworth, out of Joel Spolsky‘s Best Software Writing 1. Everyone heard the KISS acronym: Keep it Simple and Stupid, or the less friendly Keep it Simple, Stupid. The article discusses abusive complexity and why sloppy things succeed.

At some point, he compares PHP to some hammer that can be suited to any task, simply because it allows developers to be sloppy. Doesn’t this make sense? This is basically the way I always saw PHP: a quick way to do the job. Scalability is a weird concept. Java people will build a huge architecture to support their application. In the end, they will be able to instantiate objects from an XML configuration based on a DTD or schema. Everything is so scalable, because all you have to do is modify a configuration file. The part they will never tell you is that understanding that configuration file requires skills similar to those used in calculating quantum physics.

PHP uses an approach where you can do anything the way you want it. Shoot yourself in the foot a couple of times. You will end up not making mistakes. PHP can be scaled to simple scripts that will only be used once because it’s used to import data to business critical applications. In the end, PHP is not really scaling, the developer behind it is. Going back to the hammer analogy. If the final goal is to nail two pieces of wood together, it’s the final result that counts, not that you used a hammer to do it. Hammers are dangerous tools. When you are as manually skilled as I am, you have as much chance of hitting the nail than anything else, including fingers (which does hurt, but I’m lucky enough to have skills bad enough to actually hit away from my entire hand). You could use nail holders to prevent any damage and make sure it’s nailed straight. This is mostly what frameworks do, they are supposed to prevent damage by providing extra tools to keep you away from danger. Have you ever seen a construction worker using nail holders? I have never seen any. It’s simply a waste of time, and with experience, you can learn to keep fingers undamaged.

In the end, what really makes the difference of the people working on the software. Discipline is what makes secure and robust applications. Use any tool or language you want, if your goal is to cut corners to go a little faster, you will end up with a problematic application. What if changing the tool could be replaced with re-orienting the efforts based on the requirements?

Being sloppy in development gives you the flexibility to adapt the efforts based on the changing environment. If you lock yourself into a framework, chances are that you will end up having to change the framework, and all that code written for it, as the project evolves. I’ve seen application frameworks build for a specific situation way to often. At some point, the reality it was developed for simply no longer exists, and the core is adapted to new needs, causing terrible bloat. A framework to suit all needs is probably what computer scientist would refer to as utopia. If that’s what you’re looking for, you might as well replace your development crew by a thinking machine and solve all those world peace and equality problems.

Webservices tried to solve all problems at once, and this is an other major topic discussed by Bosworth. Why is RSS succeeding while RDF barely picks up? Why is REST so popular while SOAP/WSDL is only used by very large corporations? It’s very simple, they allow people to be sloppy and to get things working without having to bother about piles of specifications. For every REST web service, you need to implement the format that’s going to be used. There is no way around it as REST does not define any format. Using SOAP is easy, but by the time you understood how to write a WSDL file, you could have written dozens of REST services. RDF is one of those specifications that attempted to be catch-all. Instead of writing tag names, you defer the singularity to namespaces, which makes the file unreadable by human beings (this is only the way I see it, after all those attempts to understanding).

When you add up all the elements defined in the WS_ stack of standards, you end up with a multi-layered monster communicating with XML to oblivion. The only people who could ever come up with such a solution is either a large corporation willing to build and dominate a market by defining and implementing standards no other independent vendor could ever reach, a government subcontractor trying to raise the final bill by adding buzz words and complex schematics or a hardware vendor trying to demonstrate you need more processing power.

Keeping things simple and sloppy prevents from getting buried under technological overhead and focus on the real problem.

By the way, if you don’t know exactly what to read, I highly reccommand Best Software Writing. It’s only a gathering of articles you can find on the web, but they are cherry-picked. All of them are good. Some are hilarious. I didn’t know exactly what to expect when I bought it. The title was interesting, it’s well rated on Amazon, and the author is reputed, even thought very little is written by him. I got a copy anyway, and I don’t regret it at all so far. It’s a great book to read in public transits as it’s composed of multiple short articles on varied topics.

When I left the office yesterday, I was stuck on one of the weirdest problem I had ever encountered. Errors I had fixed days ago started appearing. Debugging procedures, functions and triggers can be quite a pain. The reported errors can be about anywhere and have mostly nothing to do with the line of code which makes the call. At best, you get an error message and with some luck, you can guess which trigger is causing the problem. In my case, the error was referencing to a field never mentioned in any procedure, function or trigger.

I solved the problem 5 minutes after I got back in the office in the morning. Stepping away from the problem and getting some sleep did help. The problem was actually with the query cache. In some cases, pre-compiled queries were stored and kept using the old versions of the triggers. I had tried restarting the MySQL server yesterday, and it didn’t solve the problem. This morning, I restarted the Apache server and everything started working again. Working is a bold statement. I had made multiple small changes in those procedures in the past few days. When I tested them, they were working. In fact, the previous version was indeed working. The new one never ran. Basically, once I restarted the service, I got to solve a dozen minor problems.

So, was it query cache or prepared statements? I don’t really know. I doubt the problem was in the database server as I restarted it a couple of times. It might be PDO, the PDO MySQL driver or the MySQL library. No matter where the problem is from, from now on, I systematically restart the Apache server after each change in the stored procedure code.

I have been using Konqueror as my primary browser on my laptop for quite a while. Back when I was using Gentoo, I was using KDE 3.4 (Gentoo is getting slow at moving packages to stable) and used Konqueror simply because it loaded faster and suited my on-the-road needs. I could read news and do most common operations with it. Some websites had problems with it and some did not recognize it as a modern browser. Even with these minor inconveniences, it remained a very decent browser. Now that I switched to Kubuntu as my primary distribution (ever since since I installed it on my laptop, which became my primary PC after a 50 foot long network cable connecting my desktop decided to die for a yet-to-be-identified cause), Konqueror appeared to be an obvious choice.

KDE 3.5 brings many minor improvements, but makes the overall system better. Today I discovered features I never bothered looking at before. Most of these were probably present in previous versions as well. As I write this post, I realize how neat the automatic spell checking in form fields can be.

Tabbed browsing has been present in every acceptable browser for a while now. Konqueror has options to make sure every new requested window actually opens in a new tab, no matter if it’s called by a target attribute or a JavaScript call. It also has pop-up blocking. It had it in previous versions as well, but now it actually notifies that a pop-up was blocked (which is a little annoying, but reminds you to hate the website you are visiting). An other nice feature you can enable is the Ad-Block, which prevents adds from loading based on a series of customizable filters. The default list is quite extensive. I never really bothered with adds before, but removing them on this wide screen monitor does leave more space for content. In terms of ad blocking, it also accepts the fact that you don’t want to install a Flash player. I remember Mozilla bothering me about it on every single mouse over until I finally surrendered. Konqueror has this nice Do not ask again checkbox. Finally, no more unwanted moving stuff on my screen. Basic stuff, but it does make browsing more comfortable.

Beyond tabbed browsing, Konqueror actually allows you to use the powerful features from it’s file browsing vocation. View > Split View > contains options to divide the screen and display multiple web pages at the same time without having to bother about window sizes. I configured mine to have a permanent vertical and horizontal split ready to use just by dragging from the bottom or side of the window. Permanent because Konqueror allows you to save the current state (content, size/position or both) under a named setting, easily reloaded. Now, how can these splits be used? Ever needed to write something and had to switch to a reference or had to compare elements from two listings? The end result is not much different from moving and resizing windows around, but it can save a few seconds once in a while.

One of the features that impressed me the most is related to the integration with the desktop environment. Once you enabled the setting to load requests from external applications in new tabs, any KDE application loading a page will load it in a new tab from your browser. One exception to this: if the browser is in a different desktop, it will open a new one in your current desktop. That’s not something Firefox would understand so easily. But that’s not the interesting part. KDE has an Alt-F2 shortcut to run commands or open a URL (quite similar to that Win-R). Using the search shortcuts, all you have to type in that box is gg;your search and it will open a new tab with your Google results, or wp:other terms for wikipedia, or php:array_key_exists in case you forget the parameter order. There is a long list of predefined search engines you can enable, from web search to dictionaries to API documentation, and you can add custom ones too. I added amazon.ca, because I end up searching for books all the time. It also has that search box next to the URL bar which does the exact same kind of search, but I never like to have to go click in that box and select the search engine. It always stayed on Google due to my laziness. Search shortcuts are available everywhere in KDE, which makes it very efficient in development.

Of course, Konqueror is still not recognized as a modern browser by some websites, but it’s fairly easy to change the browser identification and it will remember your preference for the website across sessions. The rendering still has some glitches, but I have not seen so many. Give it a try, it’s worth switching to KDE by itself.

Getting the user interface right is probably one of the hardest step of development. Building an interface that looks good is easy enough. Building an interface that handles every possible action the user in front of the keyboard can think of combining is challenging, but good validation can save the day. Things get harder when the idea is to build an interface that the user will actually appreciate. One side, you have the managers with the idea of collecting a lot of data to produce all kinds of reports the world still has to invent. On the other end, you get to see the developper who’s greatest will is to spend as much time as possible not interacting with the software at all to perform some actual work. In the middle, you have the developers willing to keep things as simple and generic as possible. Of course, some companies developing software for an external client without a fix bid contract have the opposite objective of keeping things as complicated as possible in order to extract more money, but that’s an entire different topic.

Once again, technology is not really a problem. Even for a web based application, AJAX now allows to perform some dynamic transactions and get significant improvements on usability. The problem come from the fact that there are too many different objectives. Since not having any users is not realistic and not having managers is not likely to happen, we’re still stuck playing the middle man. Depending on the domain, the data requirements might not come from management, but that’s not really important as long as you know where the requirements are coming from. If you can’t trace a requirement, chances are you are collecting useless data and have a crowd of angry users.

Basically, what has to be done is attempt to collect all the information you need without having the user enter it. Work process is a good way to do it. Since most reporting-required information is related to entry time, making sure you application collects the information according to a process and keeps the workflow linear enough, you can probably manage to get all these dates without too much efforts. The problems that arise from this is that your application also becomes linear and unless you can find a way to tailor it to different needs, chances are the end users will end up feeling the process. Being driven by a static process instead of work requirements is not a good thing. It’s not so bad when they perform the actual work, but the training part gives them such a bad feeling that they end up hating it before ever using it.

The main issue I have is that I keep forgetting they actually make mistakes once in a while. Filling in the information ends up being not so bad, but correcting mistakes is a real pain. This is something you really need to think about. Even if the data collection is process-driven, it has to be possible to hack into the workflow to fix something afterwards. Might it be the need for freedom?

An other useful way to keep data entry low is to get the information straight from the source. It’s not uncommon for source information to be located somewhere else. Even if you can only partially import the data, half is better than zero. In the same way, filling fields with common values is a good way to reduce the burden. Even if the value makes no sense, if it’s the one that’s entered most often, it should be easy to enter it. The main inconvenient as a developer here is that you are likely not to know this information until the application has been in production for a long time.

Data disposition is also a very important aspect. You need to be able to make as much information as possible available on screen. Any information they are likely to need for decision making should be available quickly. For this aspect, web interfaces have a huge advantage, mostly due to the fact that people expect to see a scrollbar. Keep common information close, make less-common information available lower in the page. Of course, it will take more of these SQL queries, CPUs will spend more cycles rendering the page and network traffic will be higher. Who cares on a local network? Having the information a scroll away is much better than a few clicks away. Focus on relevant information and avoid printing useless data. Saving a few clicks won’t help if replaced by a long listing scan.

Knowing the objectives of the different stakeholders is the key to interface design. I’m far from a master in this discipline. In fact, a year ago I never thought I could formulate an actual idea about it.