Recently, I was looking at some documentation for LaTeX, specifically how the DVI format file was created. I found out that DVI was designed by a student of Knuth called David Fuchs around the end of the 70s, when the first laser printers were being designed.

The whole story of DVI design can be read on an interview by David Fuchs to tug.org. It is a fascinating description of the state of printing 30 years ago. However, the most interesting part of it is a story that shows how really good people work hard to achieve their goals:

I, of course, wrote the DVI-to-CRS software, which also required some tricky font caching (the algorithm for which is the basis of my only published paper, which was actually written by my co-author, guess who?). Those were some intense days of working together, getting it all to work. The CRS was in a cramped basement room, and I had to load and unload each sheet of photographic paper in the darkness, and feed it into the triple-bath developer. Any bug could be potentially in my code or Knuth’s firmware, and as I mentioned, debugging wasn’t easy. After a number of very long days, I came in one morning, and came into Knuth’s office just as he was arriving and handing a stack of legal paper to his secretary. “Here’s a paper I wrote, please type it in,” he told her. I was floored. We’d been working night and day; did he write the paper in his sleep?

It is not uncommon that, in the middle of an important project, you need to work extra hard. But Knuth, despite working all day to make his code work, still spent an unknown amount of time writing papers (maybe during sleep…), so he wouldn’t compromise his scientific output. It just reminds me that to be really good, it is not enough to have good ideas. You also need to work hard.

Next time you feel overwhelmed by your projects, think about this.

It only shows my academic background when I say that I use Latex for editing anything. From articles to grocery shopping lists, I like the polished result of a Latex document.

And all this started when, in school,  I started using Latex to do my homework. Sure, it used to take a little longer to have it done. But it sure looked much better than doing it by hand.

I always used vim do thinks like Latex editing, after a short period when I used Emacs + Auctex. Although Auctex is a fantastic system, with lots of nice options for Latex users, the simplicity of vim editing always struck me as the right way to do things.

In the last few days, however, I found an open source project that tries to bring many of the features of Auctex to the vim world. It is called vim-latex. From their web page [1]:

We attempt to provide a comprehensive set of tools to view, edit and compile LaTeX documents without needing to ever quit Vim. Together, they provide tools starting from macros to speed up editing LaTeX documents to compiling tex files to forward searching .dvi documents.

See the features page for a brief tour of the various features in LaTeX-suite. All these features can be tuned extensively using the included texrc file.

vim-latex has extensive support for math symbols, folding, Latex compilation, and entering Latex environments. You can compile the whole document, or just parts of it. It makes it easy to visualize what is going on, or fixing problems as they show up.

Even better, vim-latex works on Windows, so I can work on my Latex documents even when I am not working on a Linux box.

Links:

[1] http://vim-latex.sourceforge.net/

Becoming more productive is a major goal for most information workers. For this purpose, many methods have been proposed by productivity “gurus”. These methods include the well known GTD.

The reason why many of these methods don’t work is that they impose a lot of structure that helps, but that also can make life even more boring.

I think that many of these methods are overkill, so I use a simple technique that I believe is more effective. It is what I call the 5 min technique.

The first step is to classify tasks in order of importance. Your most important projects should come first. However, you shouldn’t spend too much time doing this, as you will see.

The core of the technique is to allot five minutes to work on one of your most important projects, while trying to do the most amount of work during that period.

While some people will think that the intervals of five minutes are insufficient to achieve anything useful, there are several advantages of doing this:

• Anyone can take five minutes of their time to do something. It is the same time it take to get a cup of coffee of use the restroom. However, if you use this time to do something of importance, if will add up.
• It gives you a starting point. If you started with five minutes, you could just as well work for more 10 or 30 minutes. It depends on your current schedule. Even if you can’t continue, you did something of high priority.

Using the 5 min technique is easy, and is addictive. With time, you will be continuously thinking about how to spend your next five minutes, and that is a good frame of mind. And if you don’t have a list of priorities, then you can just start now, by taking five minutes to list your most important projects and tasks.

Recently I decided to import some of my files stored on CVS repositories into Git. The idea is to make the files easier to maintain and update. Also, this way I don’t need to remember different methods to update files. Finally, it is nice to be able to use git tools such as git-gui.

The process is simple. You just need to use the git cvsimport command. This is my command line:

git cvsimport -a -v -d <location of cvsroot> -C newDir <module>

The meaning of this is as follows: the -a parameter is used to import the whole history (if you have a long history, maybe this will be slow). The -v option shows what is going on (verbose). The -d has the same meaning as on the cvs command, i.e., to show the where the root directory is. The -C option determines where the result will be stored. And finally you need to type the name of the module.

I really wanted to import all modules at the same time, but it seems that cvsimport doesn’t know how to do this. I tried to use “.” as a module name. That works with cvs to checkout everything, but cvsimport doesn’t like it. Anyway, I now can import my old files and use only git.

We use software all the time. Not only developers, but also non-technology workers. Everybody is interacting daily with software in its many diverse forms. If it is in a PC, Mac, embedded system, or iPhone, there is no escaping from the reach of software in our lives.

It is therefore with repeated sadness that we verify that most software is of very low quality. And almost everybody has noticed the poor quality of the programs that we have been using lately:

We would not accept a new house with sloping floors, holes in the ceilings, nails sticking out of the walls, and an outrageous price — even if it minimally met basic needs. We would not be content with the explanation: “Well, it has a front door, which usually opens. You can find your way to the kitchen, but watch out for the nails. The holes in the ceiling don’t really leak. And sure it ran 300% over budget, but houses often do.” Rather than crooked floors, the software manifestations of poor design are redundancy, unnecessary performance bottlenecks, intertwined bugs that cannot be fixed, impenetrable code, and other ills. Unfortunately, we often accept software in just such a state. Regularly, companies release code like this to external and internal customers. And customers accept delivery. Businesses pay billions of dollars per year for this kind of software during mergers and acquisitions.

Among all classes of software, it seems however that what is known as business software seems to be the most plagued by quality problems. Rare is the business software that is created on time, under budget, and with minimum quality.

As software developers, it is educative to stop and try to understand why most business software completely sucks. It is probably not just for one reason, but I have my opinions about some of the culprits:

Most business software is not written for end users: in many companies, software is written for the needs of administrators. For example, many business administrators decide about features without talking to the real people who will use the feature. It is a serious miscalculation, but it is also a symbol of power that they want to maintain.

Many decisions are taken for reasons other than engineering: it is not uncommon to learn that a platform was chosen for a project because of a business decision. For instance, a company may use a completely unsuitable tool for a software task, just because it is provided by a well known supplier. This is the kind of disconnect between engineering and business that make like very difficult for developers.

Lack of design: software that is written simply by “collecting requirements” really lack a central design, which will make it always a bad choice. Good software emerges from a fundamental design decision. For example: a web browser, a spreadsheet, or a video game has a central design that makes it easy to use and even develop them. Most business software is created as an “aggregate of features”, instead of a tool that can solve a unique problem.

Given the attitude and the execution behind business software, it is not hard to see why it fails so often, even when it is delivered. Maybe it is not just an engineering issue, but a social issue that needs to be addressed by current and future generations of developers.

[Picture by thinkpanama]