jamesladdcode.com

I stumbled across the http://tumbl.us/ web site recently and I love it. Little snippets of stuff with excellent design elements. I can’t wait for new posts each day.

I am passionate about every aspect of design, and not just software or user interfaces, but other areas too. Architecture, Industrial Design, Clothing and many other aspects are of interest to me. This is why I read the book “Sketching User Experiences, getting the design right and the right design.” by Bill Buxton.

The book is inspirational and educational as well as long and with small print. It makes you think about the role of design the the importance of taking the time up-front to do designs. It also takes you through many practical approaches to designing for different mediums, including the User Interface. I practice Agile XP software development and I think there is still a need and a place for design, but I wont discuss that now. If design and the process of designing is important to you, then please get this book.

There are some quotes from the book which I just have to share:

In reference to spending time on Design -

”

Let me end this section by addressing a comment that usually comes up at this stage:

This is all well and good, and in an ideal word this might be fine. But in the real world, we have to meet deadlines and work under limited budgets. We simply don’t have the time or money to add this kind of process. Shooting for the ideal is just not realistic. ‘Good enough’ is all we have time for.

My standard response to such comments nearly always takes the form of the following two counter-questions:

How is it that we can never afford to do proper planning and design, yet we always seem to be able to afford to pay the cost of products being late as well as the cost of fixing all of the bugs that inevitably result from inadequate design, planning, and testing?

How can this be when the cost of design and planning is nothing compared to the cost of being late to market or having a defective product?

”

Sketching User Experiences goes on to show how Design as a profession is as rich as math or medicine, and I totally agree. Here is another nice quote from the book to drive this point home:

“Being able to add up your grocery bill does not make you a mathematician. Likewise, decorating your home does not make you a designer.”

Design is everywhere, but not all design is good and not everyone can design although they can play a part in the process of design. The Design Files is a nice blog about the design in different products and industries. The content and imagery may move you, and that’s by design.

At the recent Melbourne Patterns Group (that I blogged about here) Gian Lorenzetto lent me a copy of the book Implementation Patterns by Kent Beck and Chapter 4 of the book is called “Motivation”. This chapter is a great description of the “costs” of software development and I wanted to share it with you. If you can find a better description then please let me know about it.

“Chapter 4 Motivation

Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design. Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of maintenance:

cost _total = cost _develop + cost _maintain

Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of implementation patterns from those presented in the remainder of this book.)

Maintenance is expensive because understanding existing code is time consuming and error-prone. Making changes is generally easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made, they need to be tested and deployed.

cost _maintain = cost _understand + cost _change + cost _test + cost _deploy

One strategy for reducing the overall cost is to invest more in initial development in hope of reducing or eliminating the need for maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to meet the future needs often interfere with the unanticipated changes that turn out to be necessary.

Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle and implementation strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take immediate benefits in preference over possible long term benefits. While this may sound like an license to hack without regard for the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of future development.

My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier sharing of code, and smoother development.

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts.”

There is a nice bar / cafe at 200 Little Collins St in Melbourne called Stellini, and Frank has allowed me to start a book seat there.

The book(s) are free with the requirement that if you take a book, then you leave a book behind. It would be nice if you signed the books so we all have some history of how often they are returned etc etc. If you felt like sending me an email about the book you take or leave this would be good.

So when your in town, drop into Stellini, say hi to Frank and pick up a free book.

The current book is: Programming Collective Intelligence, Building Smart Web 2.0 Applications

UPDATE: It turns out this is a common idea and there is a web site for tracking books here.

All living souls welcome whatever they are ready to cope with; all else they ignore, or pronounce to be monstrous and wrong, or deny to be possible.
- George Santayana

A new an innovative recruitment web site has gone beta. Its called Hoojano. Rather than the usual ‘job list / apply’ site, Hoojano takes a different approach where the contacts you have come into play and the ‘bounty’ for placement is yours. Referring jobs to your friend can now make you money. Check it out.

Gian Lorenzetto presented an insightful and thorough review of “Implementation Patterns” by Kent Beck last night at the Melbourne Patterns Group and it reminded me of discussions I have had with the development team on making code more understandable and therefore more maintainable. What follows is the gist of the discussion ….

The systems we build are ore more organic than they are mechanical. Brent said this better than I and described software systems as having an entropy.

This is a very good analogy, since we grow applications and maintain them over time. When left neglected they take more time to maintain and bring back to life or move in another direction. Like a garden.

I think it is worth pondering the above for a little while.

Related to the above is this code I saw in an application:

void setMessage(String message) {
    if (message.length() > MAX_SIZE) {
        this.message = message.substring(0, MAX_SIZE);
    } else {
        this.message = message;
    }
}

I have the following observations about this code and suggested improvements to make it more clear and therefore more maintainable:

(I know it is a simple setter but this shouldn’t remove the need to make more clear)

1. It is surprising that a setter also truncates

2. MAX_SIZE of what ?

Here it is applied to the message length, but can it be applied to another place, maybe.
A name that would be more clear would be MAX_MESSAGE_SIZE. When someone sees it declared as a constant at the top of the file they will immediately know what size we are talking about and that they should not use it when dealing with the maximum size of a subject line.

2. The complexity of the setter is higher than it needs to be and in solving this complexity we can also make the method more clear. Currently there are two paths through the method, meaning we need more tests around it and it is harder to understand.

Here is a suggested alternative that I think is more clear and reduces complexity:

void setMessage(String message) {
    this.message = truncateTo(message, MAX_MESSAGE_SIZE);
}

String truncateTo(String thingToTruncate, int sizeToTruncateTo) {
    if (sizeToTruncateTo < thingToTruncate.length()) {
        return thingToTruncate.substring (0, sizeToTruncateTo);
    }
    return thingToTruncate;
}

The method truncateTo() probably belongs elsewhere in a String utility class, making the code in this class simpler again. I haven’t just moved the conditional elsewhere, since it doesn’t have multiple paths through the code, so the npath complexity is lower.

Even simple setters can be made more simple and more clear, which helps us understand and grow our garden.

Good presentations are very hard and that is why I am reading “Presentation Zen” by Garr Reynolds, which is excellent in its presentation and reasoning. It would be rather strange if it wasn’t.
I take notes as I read books to drive into my mind the important themes, advice or facts and with this book I have taken more notes than ever because it is full of excellent guidance. I simply can’t wait to be able to present again and put the information into practice. The principles outlines by Garr can also be applied to code and other areas of life.
One chapter of the book is about simplicity and Garr shares a letter he received with a wonderful story on reducing the nonessential:

When Vijay opened his store, he put up a sign that said: “We Sell Fresh Fish Here.”
His father stopped by and said that the word “We” suggests an emphasis on the seller rather than the customer, and is really not needed.
So the sign was changed to “Fresh Fish Sold Here.”
His brother came by and suggested that the word “here” could be done away with — it was superfluous. Vijay agreed and changed the sign to “Fresh Fish Sold.”
Next, his sister came along and said the sign should say “Fresh Fish.” Clearly, it is being sold; what else could you be doing?
Later his neighbor stopped by to congratulate him. Then he mentioned that all passers-by could easily tell that the fish was really fresh. Mentioning the word fresh actually made it sound defensive as though there was room for doubt about the freshness. Now the sign just read “FISH.”
As Vijay was walking back to his shop after a break he noticed that one could identify the fish from the smell from very far, at a distance form which one could barely read the sign. He knew there was no need for the word “FISH.”

There are important lessons in the book “Presentation Zen” and I recommend you get a copy, if improving your communication is important to you.

The web sites and coders that appeal most to me are the ones that really understand the nonessential.

Steve has another great piece on Lisp here.

If you have even the slightest interest in Lisp then this post is for you, since it jumps right in with a style that is Steve Yegge.

Bill Birch (local in Melbourne Australia) has released Genyris, a new language, derived from LISP.

Lisp is great, Bill is local and also great, so check it out here !