Archive for July, 2008

Dreaming In Code

Wednesday, July 30th, 2008

I just finished reading “Dreaming In Code” by Scott Rosenberg. Here are a couple quotes from the book:

“Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative–and they’re why you’re building it in the first place.”

And here’s Rosenberg’s Law:

“Software is easy to make, except when you want it to do something new. And then, of course, there is a corolllary: The only software that’s worth making is software that does something new.”

Quality and Speed

Thursday, July 17th, 2008

I think that for most software development projects, quality should be a higher priority than speed. If speed is your top priority you get neither speed nor quality. If quality is your top priority you get both quality and optimal speed as well.

What I mean by quality is building the right thing in the right way. This doesn’t mean that compromises cannot be made as to feature set. And I don’t think that every car needs to be a luxury car. It is okay to make economy cars. It’s just that if you are tasked with building an economy car, build the very best one you can.

And I also don’t mean that we should not consider the speed with which we build things. The time to market is obviously an important factor. It does matter that we are able to do things in a timely fashion.

What I’m getting at can be summarized by the old adage that “Haste makes waste.” When we hurry we tend to make more mistakes than when we do things in a focused, measured way. The best way to work is to be focused on doing the right thing in the right way. And if we do we’ll often do things better and faster than if we hurry and are only focused on speed. I guess this is true for lots of things in life, and never more true than for software development.

Managing Complexity

Thursday, July 17th, 2008

If I am asked about my profession, I say that I am a software developer. For most people, that is all they want to know. But sometimes the conversation continues into what I actually do. Then I say that, primarily, I manage complexity. I think this answer surprises people because it is not how they think of software. My longtime boss, Jeff, used to say that “Complexity is preserved.” What he meant was that the complexity was moving from the person into the software that they used. Or to put it another way, the job of the software developer is to understand the complexity and to create an application that simplifies things for the users. Even though the software might seem simple to the user, behind the scenes the complexity is preserved. The complexity is still there–it is just in the code now instead of in someone’s head.

Software can become very complex very quickly. This is due to the fact that the problems we are solving are usually complex. The simple problems have been solved. For example, if you want to add some numbers together, you don’t need to write a program to do that, you just open your spreadsheet, type in the numbers and click the “Sum” button. And in the world of business applications things are only becoming more complex. In addition to the primary uses of an application there are increasing requirements surrounding industry rules and regulations, audit requirements, security requirements and so forth.

There are many ways to manage complexity in software development. Two primary tools that I think most important are object oriented design and layering. They both help in the same way: by helping the developer focus on only part of the problem at one time. With object oriented design and with layers we create abstractions that help us sub-divide code into meaningful chunks.

One of the problems that I frequently see in development efforts is a focus on the shortest path from the database to the screen and back again. This causes the code to be structured in very procedural ways. It is a vertical perspective on coding. And for small applications, it might work well. But it does not scale well into large, enterprise applications. In an object oriented design, the perspective is more horizontal–primary importance is placed on the relationship of the objects to each other. And layers are added to help with things like moving data to and from the database. But by focusing on the relationships of objects with each other we better represent the real world. And by doing so we better understand and mange the complexity of the application.

Using an object oriented programming language is not sufficient. To truly achieve the goal of managing complexity it is also important to understand object oriented design. I don’t know that this is a prerequisite for enterprise application development, but I think it will always help.

Reusable Software

Wednesday, July 16th, 2008

From Dreaming in Code by Scott Rosenberg:

“Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative–and they’re why you’re building it in the first place.”

Hello World

Friday, July 11th, 2008

I ran across an interesting web site. It shows the classic first program written in several hundred different programming languages.

http://www.roesler-ac.de/wolfram/hello.htm

I was glad to see they included my all time favorite, and somewhat obscure, programming language:

http://helloworldsite.he.funpic.de/hello.htm#Prograph

The web page also links a site with “99 Bottles of Beer” in different programming languages:

http://www.99-bottles-of-beer.net/

Basic Standards

Thursday, July 10th, 2008

I have lately had opportunity to review other people’s applications and source code, and there’s something that I just don’t get. After all the books, magazines, blogs, thinking and discussion about best practices, standards and the like, why in the world do so few developers actually pay them any heed? Why, why WHY!?! And I’m not talking about having a very heavy development process with all kinds of long written documents. I’m just talking about having some kind of program specification, some kind of testing plan, even writing code comments.

One of the excuses that I hear a lot is that “we don’t have time for that.” But in several ways, time is a lame excuse. Take code comments for example. If you are only thinking about typing extra characters, it makes some sense to say it takes longer. But typing is not the hard part! The act of writing some code comments for a function or a class can help the developer to clarify the design. I think it is more an issue of habit than of time. Once in the habit of writing code comments, it doesn’t really add more time. If anything, writing the comment first can help to structure the code and can actually speed things up. The other factor is of course that having good comments can make code more understandable to users and hence more valuable in the long run.

Another good example is unit tests. Sure it takes a bit more time up front to write a unit test. But in the long run it can save time. And not only that, but it improves the quality of the code and gives much more confidence in the application. So to use time as an excuse not to write unit tests is really hog wash.

Again and again I meet coders who shun all process, standards and best practices. They think that only the running application is what matters. In a very limited way, they are right. But this is really what separates a hobbyist from a professional developer. The professional developer is interested in the full application life cycle. When considering the full life of an application it is hard to justify NOT writing code comments, unit tests, and a minimum of supporting documentation. These are just the starting point for a professional. I don’t mean to be disparaging of other developers. But I’m tired of seeing sloppy work, poor quality and lame excuses. I want to have pride in what I do, and I could never take pride in some of the code I have seen recently. I thank that sounds harsher than I mean it to. It wouldn’t bother me as much if there were an accompanying desire to improve and learn. But when sloppy work is compounded with a smugness and arrogance it aggravates me.