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]

Developing commercial software is an activity that many companies have to do. Sadly, the results of such efforts are usually misplaced, as a lot of software that is created by companies is either inadequate, or takes an order of magnitude more time and resources to build than it should take.

Assembly Line Thinking

One of the big mistakes of commercial software development is not realizing that building software is very different from building a traditional product such as a car. There is no industrial line that can be used to create a complex software.

Companies that are used to the assembly line methodology believe that you can just assign different people to do small pieces of software, and then combine everything. While it is true that people have different skills in the software world, programming is best done when someone is able to reason about the whole functionality of the program, before going to the details.

Ideally, you want people to be assigned and responsible for creating large pieces of code, and let them think hard about it. If you don’t have people that is completely involved in the creation of software in this way, what you end up is with a few pieces of software here and there that, while solving the original problem, have no clear relation to each other. Therefore, the product will miss cohesion and an inner structure that would allow an easier development strategy for future changes.

Lack of Proper Design

Another reason why commercial software is so frequently bad and expensive is that the design process is not done properly, or when existing, puts emphasis on aspects of the software that are not essential for a high quality product.

One of the ways in which this problem occurs is in the lack of a general strategy for software design, with decisions made by people that really don’t understand the underlying problems that are being solved.

Maybe a simple rule that could fix this issue is the following: don’t let business people decide what goes into software. Listen to their opinions, but leave the options open so that the designers of the software have a real decision on what features will be included and how.

One of the big issues faced by software writers is that business people that approve the software think they understand something about how to write it. This is akin to patients thinking that they can give orders to a doctor about what treatment to follow. Many of these power users like to give a lot of recommendations about what the software should look like, mostly based on a superficial knowledge of the problem. They lack the knowledge of software design or user interface design that would be necessary to make the recommendations valid. However, due to the realities of business organizations, these ill conceived suggestions are frequently taken as requirements for the software.

If we really want a software system to be successful, it needs to be designed by people that really understand not only about the problem domain, but about proper software design techniques.

The other problem is having a design done by committee. This happens when, while defining the requirements of a product, analysts go to a large number of people in order to define the features of the application. In doing this they, frequently for political reasons, adopt the disparate suggestions of several people. The suggestions may even be individually sound, but if you let software to be designed this way it will completely lack a unifying approach, and will certainly be more complicated than it really needs to be.

The best way to avoid this kind of problem is to have one person, or a small group of people, responsible to define the main architecture and features of the software. Whenever there are conflicting requirements, it would be up to this group to determine how the situation should be handled, in a way that it doesn’t damage the main functionality of the application.

It is also interesting to make sure that owners of the application are informed of design decisions, so that there will be no surprises on the customer side. Every design decision should be careful explained, so when something is not included, there is a reasoning behind it. Most of the time, users will be satisfied when the application provide what they want, even if it is not in the same way that they initially imagined. It is just a matter of proper communicating with users about how the application is supposed to behave.