Sample Code on Programming Books Considered Harmful

I am an avid reader of programming books. I think it is important to benefit from the experience of other fellow programmers, and one way of doing this, other than reading other people’s software, is reading books that collect some kind of development experience.

Although it is interesting to read about programming, there is a big downside on programming books: the programming examples that they present.

Coding samples are given on books to exemplify techniques. They can very well perform this task, but they also carry with them several problems that make them a tough sell:

Most code examples are of low quality: one of the reasons for this is that coding samples in books are not directly checked by a compiler. I know that most writers in fact check this before publishing something. But in reality there is no guarantee that between final edition, changes requested by the editor, etc., the sample code will still be correct. Authors and editors try to be careful, but by the very nature of the process there is the possibility of mistakes that wouldn’t be allowed by a compiler.

Sample code is tied to the author’s environment: a very frustrating scene is to open a book on some technique, then type the sample code and find out that it almost works. That is, it compiles, but for some obscure reason it doesn’t perform what it was supposed to do. This is a problem that everyone learning to program has encountered at least once. Probably the main reason is that sample code, by its brevity, is tied to the environment in which the author is working. Most modern programming technologies are too complicated to be reduced like that.

It promotes bad programming habits: The worst habit, which is also rampant on programming forums, is programming by copying and pasting. While it is simple to directly copy and paste a piece of code, it rarely works the way you immagine. You are also making your own code more complicated, and it is just like adding a strange body to your house: you don’t really understand what you are doing.

It always lacks encapsulation: by the very nature of coding samples, it has nothing to do if your application domain. By using such code, you are programming in the authors level of abstraction, not in your level of abstraction. A classic example is someone creating a Windows program using the Win32 or .NET API. The code is usually littered with Win32 or .NET terms. By doing this, you are programming at the level of abstraction of the Windows API: windows, forms, handles, callbacks. Such a programmer is not doing a good job in representing the level of abstraction of the application. The level of abstraction of your code should be based on the elements of your domain, not on windows and dialog boxes. These elements should be encapsulated as part of the objects used by your application.


Conclusion

My advice on this area is: read as many books as you can, but don’t bother using any of the sample code included. Prefer online resources, that are much easier to check. Prefer also the documentation from your vendor, that should be easier to read now that you (hopefully) know how the technology works (if the author did a good job). Use sample code from a book only as a last recourse, but be warned: it may be bad for you.


Further Reading

  • Desing Patterns: this is THE book you can use to start thinking about abstraction at your level, instead of the abstractions others want you to use. This book is has very high rate of ideas per lines of code. Also check this one on the same subject, but much easier to read.
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • HackerNews
  • Reddit
  • StumbleUpon
  • Twitter

What all programmers have in common

I have been working on software development for some time, and have seen a lot of different styles of programmers. There are the ones that clearly have a lot of talent and produce a lot of output. Others don’t have much talent, and are also not interested in improving their skills.

Experience has shown that there is a large gap between developers in terms of productivity. In some cases, it has been found that the best developers can produce software ten times faster than mediocre ones. This result has been validated independently of the language or tool used to develop software — which shows that the productivity gap cannot be easily fixed.

However, there is one trait that seems to be unchanged across programmers, the good and the bad ones. And this trait makes most of the schedules for software development to be late by some margin. The feature is that all developers are essentially optimistic when it comes to the time needed to create a new piece of software.

Bad programmers are clearly easy to blame on this area because they are slow and the software they create is of low quality. However, even good developers suffer from this problem. This mostly happens because of our tendency of overlooking critical aspects in the development process.

For example, although the programming time to finish a feature is 20 hours, this does not include the time necessary to attend meetings with a customer, or to optimize a database, or even to enter issues into the bug tracking system. All of these activities also count towards the working time of any developer, and need to be taken in consideration.


Fixing the Gap

The good news is that good or bad programmers can do something about their time management issues. Here is a quick list of things that I tried myself with good results:

Maintain a log of how your time is spent. It is amazing how we usually don’t have a clue about how we spend our time. As a result, we just spend a lot of our time on areas that don’t provide enough return. By keeping a log, we can start to see where we need to cut some slack and where can we put some additional effort.

Increase your estimates by a factor. Once you get some experience on where your time is spent, you will be able to estimate what percentage of your time is spent on software development, and what time is spent in related activities. This factor is different for each situation. For example, companies that have lots of meetings will require a bigger factor compared to the ones where such formalities are not needed. Find a factor for your situation and apply it to your development estimates.

Learn to say no. A big problem in schedule estimation is that what you’re supposed to do might increase, while the time allotted to the task doesn’t. In this case, you need to say clearly that you think the time is not enough for the planned feature. Saying so is better than having to cope at the end with a late project.


Conclusion

Programmers have a common tendency to schedule less time than necessary to finish a set of features. It is a natural tendency that we have, and it happens because we don’t take the time to think about the extra tasks that everyone needs to go through. By carefully understanding your personal work flow and by learning to say no to things you can’t do, we all have is a big opportunity to improve the accuracy of our programming schedules.


Further Reading

  • Mythical Man Month: an earlier view on scheduling issues for software development.
  • Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software.
  • A proposal for better software schedules, by Joel Spolsky.

Related Posts

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • HackerNews
  • Reddit
  • StumbleUpon
  • Twitter

Recent Twitter Links and Updates

Here are some topics I twittered about during the last week

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • HackerNews
  • Reddit
  • StumbleUpon
  • Twitter

Why Learning Prolog Can Make You a Better Programmer

In Computer Science programs, there is a tradition of having a course of two that represent the watershed between people that can Grok CS concepts and the ones that can’t. Although anyone can do some programming in a language like Java, where anecdotal evidence seems to show that the most complicated concept is class, it takes real intelligence to do something useful in C or Lisp.

At my alma mater, a course in Prolog was the division line between the hopeful and the real CS guys. The reasoning is that if you could get your head around a Prolog interpreter written in Prolog, then you can probably handle any programming concept.

These days however, schools are more interested in teaching marketable languages such as Java or Python. It seems like that they are looking for ways of getting people through the program as quick as possible (maybe before they realize where they are really going into).


A little of Prolog

Prolog is nowadays not as trendy as it used to be, although at one time it was the main competitor of Lisp (at least for AI-people living in Europe). However, it is often said that it is an advantage to learn Lisp even if it is just for the learning experience.

I think it is just as fair to say the same of Prolog, and here are some of the reasons why Prolog still has something to teach most programmers.

Prolog is a pure functional language. In fact, it is so pure that the only values it returns are the literals true or false. In Prolog, everything happens as a binding of parameters, so there are no variables to update — only method calls.

The language provides a simple mechanism for accessing databases. Databases are viewed in Prolog as a set of facts that can be consulted by the rules. In this way, access to external data is treated in a logical fashion, instead of requiring imperative actions to fetch and read data. The Prolog model provides reduced impedance between code and data, which is good.

Provides a simple way to represent declarative programs. Prolog is based on matching rules in a way that is transparent to developers. It tries to satisfy the requirements of each boolean function using its internal rule-matching engine. It is easy to think of this as a non-deterministic machine that just does the right thing as needed, without programming intervention. Of course, this machinery won’t solve any problem without some additional help, but by necessity it frees the developer from thinking on how things are done, and concentrate instead in what is being done.

In summary, I think that good programmers should explore alternative ways to create software. Learning languages with a different paradigm, such as logic programming, is an excellent way of challenging traditional thinking processes. Understanding how things could be written in Prolog may provide better solutions to practical problems, even if you need to write the resulting code in C.


Further Reading

There are not many new books devoted to Prolog, but there is a classical one called The Craft of Prolog ( Amazon link ). I haven’t touched that book for several years, but it was the source of a lot of fun when I first started playing with the language. That is still the best source of wisdom when working with Prolog.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • HackerNews
  • Reddit
  • StumbleUpon
  • Twitter

A First View of Microsoft Solver Foundation

In the last few days, I started playing with the new framework for optimization (i.e., business decision making) by Microsoft. It is called Microsoft Solver Foundation, and encompasses a number of technologies that make the connection between traditional optimization and mathematical programming and business-oriented tools, such as databases and spreadsheets.

The premise of MSF is that it is a framework is necessary to integrate the several areas where decision make technologies are required. Also, the tools used for optimization are varied, and it is useful to have a framework capable of doing the connection between these services.

Of course, from a strategic standpoint, MS is interested in offering solutions in an area in which IBM has already a good position. Particularly after the recent acquisition of Ilog, the leading producer of optimization software.


Some Features of MSF

The product is clearly still not mature, but it has some interesting features that play into MS core competencies:

  • Support for most commercial solvers
  • Unified programming paradigm for connecting mathematical decision into commercial computing services.
  • Integration with Office – this is important if spreadsheets area used by your company to make decision base on OR models.

However, some deficiencies are also apparent:

  • Lack of high quality solvers for some classes of problems. This is probably the biggest initial problem for Microsoft. They have a partnership with Gurobi, the new solver by the same guys that created Cplex. However, despite its potential, it still isn’t as fast as Cplex, and who knows how long its gonna take to catch up on that speed. Solvers for classes of non-linear optimization are also necessary.
  • High licensing costs: The license for MSF is by CPU, and it looks like it is in the 5 digits range. This may be a huge investment for some customers, specially the ones that still need to pay for an Ilog license. I really expected something at a lower cost and targeted at a larger demographic group, coming from Microsoft. Let us see how this issue plays out.

Conclusion

I am still learning MSF, and it matches very nicely with C#. Many people will also use the product as a plug in for Excel, with works just fine for simple optimization models. In future posts, I will provide some concrete examples of how MSF works within a C# or C++ application.


References


Related Posts

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • E-mail this story to a friend!
  • HackerNews
  • Reddit
  • StumbleUpon
  • Twitter