Since its release, Chrome has provided several ways to improve user experience on the web, including an easy-to-use interface, short start up times, and advanced features for developers.

One of the features that has made life even easier for users is the introduction of extensions to the platform. With extensions, Chrome is now able to add features that might be of interest to users, without requiring them to be programed by Google engineers. In fact, extensions will work without even requiring the browser to restart?—?a big advantage when compared to Firefox standard behavior.

An extension that was recently introduced allow users to have much easier access to PDF files. PDF is the standard format for files that need to be printed, and is used everywhere. However, viewing PDFs has always been less efficient than viewing HTML, because PDF files require an external plugin, such as Adobe Acrobat reader. Although the plugin is easy to use, it doesn’t behave exactly like the browser, which may be a disadvantage to many users.

A new Chrome extension has improved this situation. The Docs PDF/PowerPoint Viewer extension allows PDFs to be displayed in an HTML page, just like any other document. The service is provided by Google, and the result is very easy to use.

The main advantage of using this extension to Chrome is that it will open PDFs much faster than calling a PDF reader. Also, once the page is loaded, it can be easily manipulated as any other HTML page. It doesn’t behave as a separated application inside browser: it is just the browser natively displaying a document.

If you install this extension and want to get the real PDF (for archival reasons, for example), you can still save it to the hard drive. The process is the same as for other documents: right click on the link, and select the file name where Chrome will save the document. That is all you need to get a copy of the PDF on your computer.

One of the biggest issues in developing software is how to write programs that have robust design. Robust design, of course, can have different meanings, and won’t be the same thing for everyone. However, there is the intuitive notion that software that can withstand the test of time is based on robust design.

My experience in software development has shown that many of the common notions of robustness in software design are false. For example, the idea that software has to always be reusable is a major source of problems for software architects and developers. It is a fallacy that has been promoted by vendors of new technologies, and in some way continues to be accepted without criticism.

A Few Personal Guidelines

Here is a set of guidelines that I follow when writing software, and that have proven to be much more useful in generating programs of high quality.

Implement only what you need: one of the things I try to avoid is creating software that is more general than it needs to be. If you are trying to be ahead of the development curve, there is always the risk that you will be going in the wrong direction. This happens because we can rarely be sure of the future needs of your organization.

Avoid useless abstractions: this is related to the previous topic, but deserves to be treated separately. Abstractions are useful if they simplify the way a feature is implemented. However, some abstractions exist only to satisfy the needs of developers.

This happens a lot when people start to treat everything as a design pattern, for example. Clearly, even the simplest development problems can be solved with design patterns, but they don’t need to?—?specially if this is going to turn the program into something more complicated.

Make it easy to change your implementation: at the same time, implementations should be easy to change, or even swap completely, if possible. Big abstraction can make this task harder too, so you need to be aware of the repercussions of using a more complicated data structure.

Address the main issues, avoid what is non essential: one of the big laws of programming should be: avoid doing what you don’t need to. Many developers are tempted to add features that are non-essential, but “nice” to have. The problem with this line of thinking is that nice features also takes time to test and maintain. Testing and maintenance are the biggest costs in software development, not the initial time spent on developing the feature. Anything that we can do to reduce testing and maintenance is useful, specially if we are still meeting the requirements of the project.

Avoid using components that will require effort to understand/change: Finally, although it goes contrary to the wisdom of most project managers, there are cases in which you don’t want to use a component for a project?—?even if it already exists. Some components are not written to be reused, and trying to do so only make the project more difficult to manage. If that is the case, don’t try to reuse for the sake of it?—?it is just a pointless exercise if it is not improving the productivity of the team.

Further Reading

A book that explores many of these topics (presenting real numbers) is Facts and Fallacies of Software Engineering, by Robert L. Glass.

It is interesting to notice that when most media outlets discuss the world of startups, they mostly address the issue of fund raising. In some way, it looks cool, especially to magazines and newspapers, to brag about millions of dollars being raised from VCs by a new company. However, what is often not said is that raising money is usually a consequence of making a cool product, and not the other way around.

It is just like the way people look at successful people and see only the money they have. Money is only the consequence of success, not its cause. It is something that comes along with success. There is plenty of people that have large sums of money but unsuccessful (and unhappy) in their lives. By focusing only on the money, there is no way to understand the process that is really going on.

Focus on the creative side

I prefer the strategy used by some new startups. Instead of focusing on the funding part of the equation, try to put your effort on the product and team building first. This has two advantages: (1) it is a more relaxed way to work, since you are not putting pressure on the creating process; (2) it creates value immediately, instead of a debt that has to be repaid with future value.

Now, there is the issue of feasibility for this approach. It clearly depends on what kind of product you want to create. In more traditional industries, product development takes massive amounts of investment. This is not the same in software: one person or a small group can do a lot, if they are experienced and determined.

In the software industry, getting external funding may be more of a hassle than an advantage, because of all the strings that are usually attached to an external investment. Is that what you want to your starting company? Starting with a low profile reduces risk and increases the upside for the founders.