4 Things That are Almost like Programming, but not quite

Do you sometimes struggle in explaining your work to others? Especially at project planning time, I sometimes reach for metaphors to explain why estimating can be hard. Here are a few of the metaphors I've used in the past, and a few reasons they aren't adequate.

Building a house or bridge
This is a common analogy, and one often used by those that believe programming is 'engineering'. It's true that you can break the problem down into smaller pieces, then plan constructing the pieces. Repeat this cycle, going into ever greater detail, until you have your 'plan'. In this way, construction is similar to traditional 'waterfall' methodologies. There are similarities to 'agile' practices, too. A house is built iteratively-- you pour the foundation, then put up the framing, then the roof, etc. At any point along the way you can evaluate and make small changes as you go.

But.... a building is a lot more like other buildings than one computer program is like another computer program. We've been building houses and bridges for centuries, and there are only so many variations among them. Programs, on the other hand, have only been built for about 50 years and they have a lot more variables that can change. Programs also have temporal issues to deal with-- the order of things happening must be considered. (A bridge, on the other hand, mostly just stands there and lets things go over it.) For these reasons, I don't usually like this analogy.


Writing a book
In both cases, you're using text to build your deliverable. You have to break things into smaller pieces (classes, layers, etc. in software, chapters in books). You follow style guides, and have an ordering of things. All the little details you conjure up have to be consistent. In books, your characters should have past experiences that 'fit' in the context of the story. In programming, you need to make sure the data you need is available to all facets of the application that require it.

But.... I think writing a book is probably a lot less restrictive than programming. You have more freedom in the way you express things, for instance. (I don't think most editors are as picky as compilers.) In some ways, this makes programming easier-- once you have your goals defined, the ways you can go about achieving them are narrowed down. The degree of creativity is high in both cases.


Painting a picture
Painting a picture can be like programming because you're making something creatively, and you're building it in a sort of iterative manner. This is somewhat like the book argument, except the painting seems a little less constrained in places. You can choose your medium-- oil paint, water color, chalk, etc. much as you can choose your implementation language in programming. Programmers can also bootstrap projects by copying the work of others. ('Hello World', anyone? It can be seen sort of like paint-by-numbers.)

But.... paintings don't have to be exact. Their 'goodness' is found in the eye of the beholder. Oh, if only programs were that way!


Assembling a child's toy
Have you put together a bigger toy lately? They usually come in a cardboard box with about a hundred different parts in it, with an instruction sheet written in half a dozen languages. The assembler (you) reads the instructions and attaches part A to part B. The instructions (like documentation in software) are sometimes good, sometimes not. Sometimes you have to refer to a picture of the toy to see how to do it. This is like studying design patterns or reference implementations. In today's programming world, (especially Java) we have a lot of frameworks that make programming seem like this.

But... You never really fabricate anything by yourself in the toy scenario. You're using parts somebody else made. So I don't think this one is exactly right, either.

Those are some of the metaphors I've used. If you have any better ones, please share!

Happy Coding!

Book Reviews on the Way: CodeIgnitor, Groovy DSLs

The good folks at Packt Publishing are about to release 2 new books with interesting subjects.




CodeIgnitor 1.7 Professional Development
The book's available here.
Have you noticed that PHP development is red-hot? Check the web statistics-- the majority of web development is done with PHP. (Based on today's data, found here.) This title promises to teach sound PHP practices, including REST style web services. I look forward to reading it!



Groovy for Domain-Specific Languages
This book can be found here.
DSLs are little languages written in the business terms your users are familiar with. I've often written DSLs (even before they were commonly called DSLs) but never stopped to think about best practices in doing so. Coupled with the easy-to-use Groovy language, this book has the potential to increase my productivity, so it's another one I look forward to reading. Another great topic!

Watch this blog for reviews as soon as the books are out. 'Till then, Happy Coding!

9 reasons I like cubicles better than offices

Sometimes developers get offices, sometimes we get cubicles. I'm not convinced in office is always a better choice, though. Here are 9 reasons why I think cubicles are better, and 2 reasons they are not:

1) You're part of the Dev Network. Hopefully, your cubicle is in a row with other developers and architects. If that's the case, you get to listen in on and take part in all kinds of conversations about a wide range of work topics. In turn, this lets you benefit from other's opinions and experiences.

2) You have a face. Unfortunately, I've worked at places that have had layoffs. In fact, I've seen some good technicians let go before less effective counterparts-- because the guys who were kept were more familiar to everyone. Once you're in an office, you become a little less known to your local work group. (Along the same lines, I've known top-notch technicians who were given less 'street cred' by the senior techs in the shop because the guy worked remote. Had that guy been a local cube-dweller, I'm sure his opinions would have carried great weight.)

3) You're the first to know about food carry-ins, where cube-dwellers gather and share treats. 'Nuff said.

4) If you're single, you have an excuse to mingle. It worked for me-- I've been married for 12 years to the hot chick from across the wall.

5) It helps keep the amount of clutter in check for us pack rats. I for one would have TONS of old developer magazines, books, printed tutorials, etc. if I had an office. As it is, I probably only have half a ton in my cube.

6) You can easily ask a co-worker for a second set of eyes on a problem. Two heads are better than one-- it would be much more difficult to leave the office, pull someone from the cubes, etc.

7) You can build on your all-important social/work network. So maybe it's not the best use of your time to talk about World of Warcraft or sports once in a while. It does help you form bonds with your co-workers, though, and that can later pay off when you need to leverage the network (i.e. referal for a new job).

8) You won't lose face if your work area gets moved. If you work in a big building and your work team gets moved, it's no big deal if you go from a cube to another cube. But if you had an office and got moved to a cubicle, it might seem like you 'lost something'.

9) You're on the right side of the Dilbert labor/management spectrum when you're in a cube. Once you get an office, you're more like the pointy-haired type than the engineering type.

And a few reasons you'd really rather have an office

1) It gets you out of the noise when you need to concentrate. On those occasions, it's nice to be able to close the door and get lost in your code. If you're in a cubicle, headphones might be the next best thing.

2) You can make phone calls without the whole world listening in. Business or not, sometimes there are calls you'd rather not have overheard. Luckily for cube-dwellers, vacant conference rooms can help fill this need.

3) Good old hubris. Let's face it, an office just carries a little more prestige, doesn't it? But that's not a good motivation, IMHO.

Happy Coding!

Book Review - "OpenX Ad Server: Beginner's Guide"

Do you have an interest in online advertising? Are you a blogger or website administrator that would like to monetize your workspace? If so, I know of a book that might be of interest to you.

Packt Publishing has just released "OpenX Ad Server: Beginner's Guide". True to the title, I found this book can guide the reader from zero knowledge of online advertising to capable user of the popular OpenX Ad Server. (An open source platform for configuring and running online advertising campaigns.)

The author assumes the reader has no previous knowledge of online advertising, so the basic concepts are clearly explained in the opening chapters. Advertisers, Campaigns, Banners, and Zones are all given high level introductions, then later deep-dives as you are exposed to all the configuration and minute details associated with each. The book is set up in a very logical manner, with a nice template used for the detail chapters: Explain the component in a high level, then walk the reader through Open X's implementation of the abstraction in step-by-step detail. (The steps are accompanied by many useful screenshots, by the way. The high level theory is accompanied by understandable diagrams.)

All things considered, I believe this book delivered on it's promise. OpenX is made clearly understandable to the reader, no matter how much experience the reader had before cracking the book open. I wish every technical book were this straightforward!

The book can be found here.

Happy Coding!

Comfort Words after a Bug

Last week a good friend of mine stopped by my cubicle*. He was upset because a bug had been found in his code and the code was now delayed in going to production. Here are the things I said to him then, and I will hope to hear back in the future when I have a newly found bug:

"It's your turn in the hot seat."
I told him "I was to blame when we found that bug I wrote in the Locator service, so now the heat's off me. Don't worry, I'm sure I'll claim it back again after a while."

"Even the very best developers write bugs."
It's true. This is because software development is just plain hard. Look at 'Quick Sort', for instance-- it's been around for decades, yet new and subtle bugs still crop up once in a while. No matter how smart the author, no matter how well understood the task, there will be bugs.

"If you're not breaking something, you're not doing anything."
I first heard this one when I worked a summer on a golf course. A tractor had just been driven over a sprinkler head, causing the sprinkler head to break off it's pipe and causing a big water leak. The boss told the disheartened tractor driver that these things just happen and the only way to avoid breaking things was to sit frozen and not do anything. Likewise, the only way to completely avoid writing bugs is to stop writing code. (Which nobody wants, of course.)

That's what I said then-- he'll probably be echoing it back to me next week. What do you say to your friends in this situation?

Happy Coding!

* I'll write a future post about why I think senior developers should work in cubicles, not offices.

Performance testing tip -- Visualize your data to help reveal patterns!

When you're doing performance testing, take a little extra time and examine your data for patterns. Sometimes the patterns aren't easy to see, but with the help of some tools they'll jump right out at you. Let's look at an example.

Here's some sample data that represents the amount of time it takes for a test driver to invoke the server. Do you see the pattern?

latency
0.7630
0.0626
0.0662
0.0705
0.0833
0.0631
0.0656
0.0712
0.0841
0.0623
0.0671
0.0699
0.0840
0.0619
0.0659
0.0720
0.0835
0.0630
0.0659
0.0706
0.0835
0.0619
0.0671


I can't see the pattern immediately. So let's have a look using 'R', the excellent open source statistical language. (If you're not using R yet, you might consider looking at it. It really is easy to use, and it gives you excellent statistical capabilities. There are lots of nice web tutorials on how to use it, as well as the excellent Manning title "R in Action") Here's the R script:

timingticks <- read.table("/home/rick/Blog_Temp/My.dat", header=TRUE)
attach(timingticks)
'Count'
length(latency)
summary(timingticks)
plot(latency, col='blue')
axis(2, tck=1)
q()


The script is pretty self-explanatory, but what we're saying is roughly this:
- Use my data file.
- Get me the number of records (length) of that file, call it 'Count'
- Give me a statistical summary of the file
- Make a plot of the file, using units of '1' on the left axis. THIS IS THE PART THAT SOMETIMES MAKES THE PATTERNS JUMP OUT!

So let's run the script then have a look at the results. First, the statistical output:

[1] "Count"
[1] 23
latency
Min. :0.06190
1st Qu.:0.06435
Median :0.06710
Mean :0.10036
3rd Qu.:0.07765
Max. :0.76300
> proc.time()
user system elapsed
0.732 0.028 0.747

This alone makes using R worthwhile. With almost no effort, I got some good information about my application timing performance. But that's not the real pay-dirt in this case! Let's have a look at the plot:



Now that's more interesting! Let's ignore the top dot, which represents a 'first transaction'. These are often much longer than the following entries due to 'warm up' issues. But look at the little repeating saw-tooth at the bottom! This is indicative of some sort of repeated behaviour.

In a real-world scenario, this was exactly what I saw when we found some server-side code that was trying to improve performance with a cache. The code was caching a value in a list, then when the list got to a certain size it tossed the cache and started over again. (In this case, the list size would be 4. See how the data goes in patterns, the timing gets a little longer each time for 4 cycles, then it 'busts' and starts over again?) It turned out our "performance-enhancing" cache was actually costing us performance! We removed the cache.

This is just one sample of how data visualisation can be used to help you find patterns in performance data. It doesn't take much time, and it can lead you to valuable insites. It's also fun!

Happy Coding!