One of the main problems small companies face is trying to figure out what their users need. In the desire to create a new business or improve it, they create products that could possibly be of interest to their market.

Despite their interest, many such companies fail because they spend too much time and energy in the process of building a product.

Instead, I believe that most of the time should be spend learning about the market, and listening to what users need and want to spend money on.

On the bright side, there are lots of ways to learn about users needs. For example, a simple way to learn what the market wants is to create a simple, focused product and market it to the people you think are interested. This can be a simple way to see if there is interest in your idea.

Devising the Perfect Product

Sadly, a lot of time is spent trying to find perfect ideas for software products. While there is merit in bringing something innovative to the market, most products that work commercially are based on simple ideas that are already being used somewhere else. In fact, even Google started with an existing idea, searching for keywords on the web, with a twist that made it faster and easier to use.

The way you can create a good software company is gathering ideas that already work, then releasing a product that satisfy these needs in a different way. For example, you can create a product that is easier to use, or that target a different segment of the market than the existing offers.

By doing this, you can try to evaluate if the product will be received successfully and improve it as necessary.

On the other hand, if a product is not successful, you can always try to change course if you didn’t invest too much time and energy on it. Success then becomes a matter of using the market as a earning tool, instead of going against it.

Text editors are a pleasure for developers. A good programmer uses the text editor as his main working tool. After all, programmers spend most of their day typing away code on text files.

That is why text editors are so important for a good programmer. And learning a new editor is like learning a new language, giving you a lot of possibilities on how to accomplish certain tasks.

That is the reason why I like to try new text editors from time to time, in order to see if they provide any useful features that I might be interested in adding to my toolbox.

One the latest editors that I tried out was wily. Wily is a relatively obscure editor, but it comes from the same tradition of ed, vi, and Sam. It is a version for UNIX of the acme editor, that was designed and implemented on plan9.

What is really different about wily and acme is that hey are text editors for programmers that are completely based on use of the mouse.

The Mouse and Programmers

Almost every programmer out there hates to use the mouse. This is an issue because most of us are faster using the keyboard, and the keyboard provides far more combinations of commands than the mouse.

Therefore, coming to the wily world is not as easy for a programmer as using other editors such as Vim.

Essentially Wily uses the mouse to activate a number of functions, such as running commands, searching, and of course, cutting and pasting.

While the idea is interesting in theory, it has the big drawback that it requires people to learn to use the mouse in ways that they are not used to do. For example, most user interfaces require users to click or double click in elements of the screen. On wily, however, one has sometimes to do “mouse chords” a sequence of left, right, and middle-button clicks that performs some action.

This is not only unusual, but it is also really painful. And the worse, in my opinion, is that there are several options that may be used to avoid doing these operations with the mouse.

The main reasoning for this behavior used by wily/acme users is that the mouse is the easiest way to select text in a GUI.

I agree that it may be an easy way, however it is not the best one. In vi, for example, there are at least two ways that are easier: using search or jumping to a specific line on the screen using the keyboard. And these are just two methods, there are many more available for Vim users.

For example, on wily one can search for the next selection using a middle click on the desired text. However, in Vim one can perform the same search using the * command, with is several times faster if you can touch type.

Another problem with wily is the limited set of features. The proponents of the software think that this is a strength, because the total amount of source code is small and easy to understand. However, there is no advantage is a code base that is easy to understand if you are not willing to extend it. It is the same as saying that you like to have a clear kitchen because it makes it easier to cook, and them refusing to cook because it is going to mess up the kitchen.

Therefore, my impression is that wily/acme is an interesting experiment and that some people would become used to it. However, I don’t think it provides anything really better, compared to other programmable editors such as Vim or Emacs. In fact, due to its views of software development, the writers are convinced that it is OK to offer much less features, without really providing a better alternative.

Hi, this is the 12th part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

---

Coding is a fun activity. But in the middle of creating interesting algorithms and user interfaces it is easy to lose track of the main context of the application we are writing. Getting the global picture, however, is not only important, it is essential to create a software product that really delivers what customers need.

The problem is that it is really easy to get side tracked while completing peripheral features that seem interesting for us, but are ultimately useless for clients. How many times have you spend a whole afternoon optimizing an obscure part of your code, or creating a more elegant class for something that is not all that important?

Although implementing the ideas you like most is a fun activity, it contributes little for the success of a software project. On the other hand, the results of getting side-tracked are not fun, and can cause major problems during the development of a large application.

Here are some tips to avoid missing the focus while writing a major software component:

Keep in touch with customers: The best way to understand the main focus of your application is to keep in contact with users. They are the ones that can help judge if a feature is important or not.

Work from a to-do list: It is always useful to have a map when travelling. When working, the closest thing to a map is a to do list. You can decide ahead of time what the plan is for your application, so you don’t get distracted by superficial details.

Avoid the unnecessary: sometimes we try to add features just because they are nice or fun to have. Avoid doing this always. It doesn’t add value to your application, and at the same time creates complexity that you don’t need. Always limit your features to what you really need and you will have more solid products.

Iterate fast: a good way to avoid losing context is to be pragmatic. Iterating fast gives you the focus necessary to keep the main context of your application in your head.

XML is a generic format for data storage that has been widely used by the industry. That could be all that there is to XML, if were not for the importance of data in programming. One of the things you learn when using Lisp is that data can also be viewed as code — we just need some way to interpret it using a programming language. This is the secret that make s-expressions so powerful.

It turns out that using C++ or Java to interpret data in XML format is not terribly complicated. Many people have made a good life just doing this kind of thing, using one of the many libraries available.

It is possible to use data encoded as XML as code and use a standard XML parser to interpret that data.

There are several examples of how this strategy may work. Ant is a well know case, where XML has been used to encode not only data about the building process but also other programming-like actions.

XML and Domain Languages

Using a textual language to express commonly used actions has always been a powerful way of creating software. For example, whole systems have been implemented using a domain language.

Think for example of Emacs, which was implemented in a simplified version of Lisp. Or, in a more specific domain, troff was implemented using a special-purpose language.

The advantage of using XML, though, is that one doesn’t need to use yet-another-parser for a domain-specific language. At the end, using a generic format such as XML is almost as good as the s-expressions used by Lisp.

In a sense, XML unleashes the possibilities of domain-specific languages for everyone else who doesn’t know how to write good parsers. You still need to implement the semantics of the language in Java or C, but this is a great step towards improved support for domain specific languages.

Further Reading

To Understand how Lisp leverages the power of DSLs, the best reference is Paradigms of AI, where this and related techniques are discussed.

The idea of code reuse has been a gospel for many years among advocates of modular technologies: first structured programming, then object oriented as well as other types of programming methodologies.

While it is a good thing that we are able to separate concerns and make our code more modular, there is also a downside is requiring that all our code become
reusable.

If too much emphasis is put on reuse, It is possible that a perfectly good solution just becomes something super complicated. In that case, it can quickly degenerate into a generic piece of code, which requires major efforts to interoperate with other parts of the application.

Design Mistakes

Reusable code can also lead to big mistakes in design. By reusable code, people have the idea of creating code that can be applied in another scenario by doing small modifications. This is how inheritance is used by some developers.

And it becomes tricky because real programs don’t work this way. If you write code that is generic enough to be reused in different scenarios, it may be that it doesn’t solve any particular problem well.

A Better Way to Go

The other way to get code reused is to design it to fit a particular problem well. When that happens, we will start noticing a pattern that can be applied not only to the problem that it immediately solves. Thus, such code can help us finding a more generic interface that could (and should) be used in other situations.

Looking at that aspect of programming, it might be better to talk about the sharing of algorithmic strategies, instead of simple code.

Reuse and Black Boxes

It is hard to reason about an algorithm when all you have to work on is a set of black boxes.

Reusable modules as we have these days work pretty much as a black box. Although they are available in source or binary form, they cannot be easily changed if necessary. Sometimes is true even when we’re working with open source software, due to the difficulty of making changes to a library.

I feel that when we reuse code just as a way of creating more black boxes, we have a less flexible toolbox, that is not easily amenable to algorithmic changes. Several layers of such libraries can make our code to look brittle and inefficient.

Maybe we should look for other ways to create software that is easily modifiable. I think that generic programming, using meta constructs available in languages such as Lisp and Prolog could provide a better solution. Maybe we will see more of this in the future.

Further Reading

Knuth talks about some of these issues on his interview for coders at work.