Reflections on Programming

Moving

2007-01-17T09:03:00.000-08:00

I have decided to consolidate my blogs into a single one at http://john-dunne.blogspot.com/

Quote of the Day

2006-07-20T09:07:00.000-07:00

Watch where the footpaths go before you lay down the sidewalks.

Grooks

2006-01-26T08:34:00.000-08:00

By way of Tim Berners-Lee, I found this wonderful collection of Grooks by Piet Hein. They have a wonderfully whimsical character, like this one:

BUDGETING: THE FIRST LAW 

If you want to know
where your money went,
you must spend it quickly
before it's spent.

Great Quote

2006-01-24T10:58:00.000-08:00

Darren Hobbs: Agile Answers

Developing incrementally does not (in my opinion) mean taking your brain out before starting.

What happens when you don't "get it"

2006-01-20T12:05:00.000-08:00

PragDave

Without exception, these early attempts at imitation failed: the car companies replicated what they saw Toyota doing, but only on the surface. They didn't really understand what was behind these practices. It was like trying to become an artist by copying the angle and velocity of the brush held by a master.

You see this happen often with various "agile" practices, like test driven development, XP, or Scrum. If all of the participants don't grok the practice, then they blindly execute a series of steps, and say, "See. It didn't work!"

There are two possible resolutions to this problem.

You can tighten up the process. Unfortunately, if you didn't "get it" in the first place, you are likely to cause more harm than good. At its pathological extreme, your team works like the staff of a McDonald's, with each person following a carefully prescribed methodology. If you are building the software equivalent of a Big Mac, then this might be perfect for you.

You can invest in your people. The old saw about giving a man a fish versus teaching him to fish applies here. For even the most simple project, it is nearly impossible to prescribe everything. At some point, personal judgement has to kick in, therefore it makes sense to equip the team with the mental tools needed to make the right decisions.

I don't mean to "dis" process, but I think you reach a point of diminishing returns, with "process improvement" whereas "people improvement" will always pay off handsomely.

Design by Contract is trademarked!

2006-01-03T13:40:00.000-08:00

I was reading this article called Contract Programming 101, when I ran into this little gem:

Note: the term Design By Contract was trademarked in 2003 by Dr. Meyer, so all the little free software pixies are dropping the term like a hot coal. The latest favoured term is Contract Programming, as suggested by Walter Bright in 2004 and used in the recent proposal by Thorsten Ottosen and Lawrence Crowl to the C++ standards body.

That is not cool!

Index Cards

2005-11-11T14:45:00.000-08:00

Extreme Programming has this strong tradition of using index cards to track user stories, or to aid in design through the use of CRC cards.

Now, I have always had a strong preference for Excel spreadsheets.  You can print them, e-mail them, share them, and save them.

But there is something wonderful in the very nature of index cards.  Their very constraints create interesting feedback loops.  Think of all the objections that you might have against them:

Index cards are too easy to lose.

Yes – but why are you writing anything important on an index card in the first place?   At the end of the day, the only important work product is the code.  Requirements and any other models exist to facilitate conversations about the code.  If you have been writing tests along the way, when the coding is done, the requirements don’t need to exist anymore.  The requirements aren’t sacred.  The only thing that is sacred, the desires of your users, cannot be captured in any format, but must be discovered through a constant dialog.

Index cards are too bulky.

If you have more index cares than you can manage, then your user stories are either too fine grained or your scope is too ambitious.  Either way, the cards are telling you that you need to change.

This is a pet peeve of mine.  Quite often, when you are doing the wrong thing, it will be difficult.  The correct solution is not to make it easier to do the wrong thing, but to change what you were doing in the first place.

Only one person can “own” an index card at a time.

So what?  Distributed ownership is the worst thing that can happen in project management.  If everyone owns a task, then no one is really responsible for carrying it out.

Having said all that, I am still mulling over the use of index cards in my process, and have started collecting links about index cards in del.icio.us.

Holistic thinking is disruptive

2005-11-08T03:56:00.000-08:00

In the November issue of the Atlantic Monthly, there was a brief article about the heuristics used by the US intelligence community to detect spies.

They may also take a "holistic view of world affairs" that could lead them to believe espionage is "morally justifiable."

You can read this any number of ways, and I won't debate the ethics of making decisions to support particular policies of this adminstration in spite of common sense (or holistic thinking) telling you otherwise.

But I would like to touch briefly on his this might affect your organization. When it exceeds a certain size, every organization begets a hierarchy of departments. While the organization, as a whole, might wish to move in one direction, each department has its own incentives, which sometimes contradict the organization's larger goals.

In such a world, to think holistically is to think about disruption, as any move to re-align the departments with the organization's goals will result in disruption to that department's practices.

Behavior Driven Development

2005-11-07T08:04:00.000-08:00

I recently read an interesting paper by Dave Astels, entitled A New Look at Test-Driven Development, which suggested that Test Driven Design is overly focused on testing, which gets in the way of reaping the true benefits of TDD.

I agree that using the word “test” when describing TDD definitely gets in the way, when explaining it to other people.  Management asks, “Why are we hiring testers if developers will be writing tests?”  Developers ask, “Why should I write unit tests for code that will get tested by the (manual or automatic) acceptance tests?”  And so on.  You get the usual objections to TDD.

So I am down with giving TDD another name, but what threw me was the suggestion that we ought not to use the word “test” when actually writing the tests.

In Behavior Driven Development, tests are called “specifications.”  Fixtures are called “contexts.”  And instead of assert, one would say “should.”  (Dave’s essay has examples of their usage.)

Initially, I was fairly dismissive of what seemed like a cosmetic change, but I decided to give it a go for the past week.  Here is what I found.

I wrote more, smaller test fixtures.  Whereas I used to write test fixtures with names, like CustomerFixture, I found myself creating many little contexts, with names like CustomerWithOverdueBill or CustomerWithoutAddress.

I wrote more asserts per test.  Each test started with a particular context, invoked a particular operation in that context, and then verified the expected resulting context.  That verification often took multiple asserts.

The tests naturally had better names.  In the past, when writing tests for a Customer class, I might have tests with names like testSetAddress.  Now, I find myself thinking in terms of scenarios, so that the CustomerWithoutAddress context might have a specification like settingAddressForFirstTimeSendsNotifcation.

In summary, this change in perspective has proven extremely useful, so I am sticking with it.

Could You Pass 8th Grade Math?

2005-10-30T05:05:00.000-08:00

You Passed 8th Grade Math

Congratulations, you got 10/10 correct!

Could You Pass 8th Grade Math?

Planarity.net

2005-10-10T13:22:00.000-07:00

A way cool game that tests your facility with spacial relationships:

Planarity.net

Are iterations hazardous to your project?

2005-09-12T09:58:00.000-07:00

Are iterations hazardous to your project?: "That surprise experience helped open my eyes to why 'iterations' may be hazardous to your project: Danger grows when the results of the iteration are not directly linked to delivering the product to the end user. Without that linkage, iteration results hang in the air just as badly as the old, pre-agile forms of wandering in the wilderness."

This could be filed under the general heading of "Don't let the process become the goal," which is a disease that strikes nearly every organization.

Here is how it happens:

Management wants feedback that the team is making progress towards a particular goal, so they add instrumentation to the process to gather metrics. The team responds by trying to improve those metrics. If management chooses the wrong metrics, the end effect is that they drive the team away from its goals, rather than towards them.

I think that all of Alistair's observations and recommendations are dead-on.

Laziness Driven Design

2005-08-11T08:32:00.000-07:00

I have become fanatical about writing unit tests for every method on every class, regardless of how trivial that method first appears. ( "But it's just a getter!" )

This leads to an interesting laziness driven feedback loop. Here's what happens:

I am implementing a feature, and think that the shortest distance between two points, is to add another dependency onto one of my classes, but then I realize that this new dependency would further complicate all of my tests, requiring large changes. Ugh! I don't have time for sweeping changes to my test suite.

So, in my laziness, I skip over the initial, obvious solution, think a little bit harder, and come up with a truly simpler solution.

The PO-STAR Movement

2005-08-08T08:06:00.000-07:00

In the past year, I have seen an increasing number of "Plain Old *" abbreviations:

POJO - Plain Old Java Objects
POCO - Plain Old CLR (.NET runtime) Objects
POX - Plain Old XML

At this point, I think it qualifies as a crypto-movement, and the clue to the genesis of this movement is in Andy Smith's "Why Frameworks Suck."

Frameworks hurt sharing. I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.

The alternative to PO* is to buy into some framework, which inevitably prevents code reuse as your classes become riddled with framework junk.

You know a library is really a framework when:

It requires you to derive your classes from some library class.
It requires you to use their main() function.
It requires you to use their Application class.
It requires your classes to depend on some third party library.
The setup() and teardown() methods of your test suites become really complex.

Nearly every time that I have written framework-like functionality into an application, I have found that I was able to factor it out in favor of simple library classes that are themselves PO* objects.

I Heart Python

2005-08-07T08:58:00.000-07:00

I have been playing around with Python at home, developing a simple web application, and I just wanted to say that I think that Python is awesome.

Fear of the Domain Model

2005-08-07T07:58:00.000-07:00

Did you ever notice that many programmer's tend to shy away from developing a domain model?

This is a pretty reasonable reaction. We want to exploit our strengths, and leave the domain to the domain experts. We want to continue to improve our knowledge of computer technology, because this translates into a personal asset.

I think that the ability to elicit domain knowledge from a domain expert and convert this into a viable domain model is a more important skill than the knowing the latest technology that your tools vendor is trying to push at your CIO.

A rich domain model is truly fertile ground for developing applications, and building working, valuable applications is way more important than extending one's knowledge of the solution domain.

The Garden

2005-08-05T11:42:00.000-07:00

Originally uploaded by Jennifer Dunne.

This is picture of a flower in my wife's garden.

Thoughtless Interfaces

2005-04-12T13:37:00.000-07:00

Here is a great write-up on how to not create an interface: IFoo as Foo's interface is evil and should be punished.

It's all about responsibilities, people!

Toothpaste

2005-04-11T09:06:00.000-07:00

Originally uploaded by Jennifer Dunne.

My wife took these wonderful pictures of toothpaste, which had quietly extruded itself from the tube in the middle of the night.

Trust is an essential deliverable

2005-04-07T14:11:00.000-07:00

From Exploration Through Example:

Sometimes teams are jumping into Agile to avoid the horror of the previous release. The code was too buggy, or too late, or cost too much per feature, or all three. In such a case, the programmer team is probably not trusted by the business people. If so, trust is an essential deliverable. It's not enough to be better; you have to be visibly better soon. Delivering tested, working features at frequent intervals is a key way to get trust back. Another way is close cooperation with a product owner that demonstrates that the team's orientation is toward helping her meet her goals. But more generally, the team should pay active attention to how well they're doing at building trust, not just at building code.

A Perfect Recipe for a SOA Failure

2005-03-22T12:00:00.000-08:00

From SOA is a Business-Driven Architectural Style:

"It means that for SOA to be successful, it must be a 'top-down' approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure. "

I will go a bit further and say that any architecture that isn't bent on solving a particular problem is a recipe for failure.

Searching Google for Books

2005-03-21T13:22:00.000-08:00

I had heard about Google Print a while back.

I hadn't realized that the Google Library project would mean that public domain books, like Huckleberry Finn, would now be searchable via Google.

You just enter "book" followed by the book title in Google.

Yahoo has acquired Flickr

2005-03-21T09:26:00.000-08:00

Thoughts on Flickr and Yahoo (by Jeremy Zawodny)

I hope they don't mess it up. :-)

Being Careful Is Not The Solution

2005-03-02T09:55:00.000-08:00

Sometimes, when you touch a piece of code, or a build script, or a configuration file, you might feel the urge to be very careful, because your change might break the overnight build, or result in a subtle bug.

Being careful is not the solution. You cannot be careful all the time. Sooner or later, you will let you guard down and make a mistake. It is inevitable. If you are lucky, this mistake will occur when you have loads of time to diagnose it. If you are unlucky, you'll get a bad build at the 11th hour.

When you find that you need to be careful, you should ask yourself, how can I change this situation so that mistakes are either impossible to make or discovered immediately after making them?

If you think about it, you probably already know a few strategies for achieving this right now:

Unit tests insure that your classes behave as you expect them to.
Asserts (Design by Contract) achieve the same thing from a different direction.
Code generation eliminates duplication, so that you only have to make a change in one place.
Static type checking catches mistakes at compile time.

Jellyfish

2005-03-01T19:27:00.000-08:00

Jellyfish
Originally uploaded by JohnDunne.

This is a jellyfish that we saw while poking around the aquarium at the Mandalay Bay hotel in Las Vegas.

Tips for Google Maps

2005-02-25T12:12:00.000-08:00

Some neat tips from Mike Clark

Need Driven Development

2005-02-17T09:44:00.000-08:00

In "Mock Roles, Not Objects" [1], Freeman, Pryce, Mackinnon, and Walnes say:

A core principle of Lean Development is that value should be pulled into existence from demand, rather than pushed from implementation: The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.

This is the flow of programming with Mock Objects. By testing an object in isolation, the programmer is forced to consider an object’s interactions with its collaborators in the abstract, possibly before those collaborators exist. TDD with Mock Objects guides interface design by the services that an object requires, not just those it provides. This process results in a system of narrow interfaces each of which defines a role in an interaction between objects, rather than wide interfaces that describe all the features provided by a class. We call this approach Need-Driven Development.

I recently experienced the opposite of this approach. I had done some initial design, and come up with a list of classes and their responsibilities. I picked the most important class and started implementing it.

So how did I mess up?

You need to start at the edge of the system, from the external interfaces and work your way in. My "important class" was not nearly as important as I thought it was, and certainly was not more or less important than any of my other business objects.

When I finally got around to implementing my external interface, which was a messaging layer, I found that some of my earlier assumptions did not hold true. I had over-implemented some of the business objects. It is easy to fall into this trap with TDD, because you can implement your objects before anyone actually needs them.

If I were to do it over again, I would not forgo that initial design, because it certainly helped the process along, but I would always start my implementation with the classes that are closest to the business requirements.

[1] http://joe.truemesh.com/MockRoles.pdf

We’ll ship when the product is ready.

2005-02-15T13:02:00.000-08:00

From the Internet Explorer team:

I’ve gotten questions about the ship date. Yes, we have a date in mind. I’ll talk about the date after we get feedback from customers and partners. We’re going to release a beta and listen, then refresh the beta and listen some more. We’ll ship when the product is ready.

This is a refreshing point of view, that you don't hear too often. I imagine that the IE team is under a certain amount of pressure, due to Firefox's increasing marketshare.

This is my brain in....

2005-02-14T11:21:00.000-08:00

del.icio.us

You can map your del.icio.us tags with this handy tool.

Pilers vs. Fliers

2005-02-14T09:45:00.000-08:00

This is a great posting about the importance of not letting your inbox pile up.

If Your Inbox Has More Than a Screenful of Messages In It, You’re Rude

I totally agree with Jason Clarke. My own system is to move every e-mail that I have read to a folder called "Read Mail". If I don't have the time to immediately respond, I hit the "Reply" button and save the reply in my "Drafts" folder. If I need to do some research before replying to the e-mail, I copy it to my "Tasks" folder which automatically creates a new Task.

The Gates in Central Park

2005-02-13T10:14:00.000-08:00

The Gates in Central Park
Originally uploaded by JohnDunne.

We took a walk on Central Park yesterday to view "The Gates."

Here is a satellite image of The Gates.

2/15/04 - Added satellite image.

Get Your Code Head On

2005-02-11T10:28:00.000-08:00

Ever since I adopted test driven development, I have noticed a subtle shift in my development patterns.

Before TDD, I used to make a lot of effort to get into a "code head", a place where the code would just flow. To get there, I would eliminate all distractions and think about nothing but the code. Any lengthy interruption would set me back by an hour or two, because I needed to remember everything.

Now, I don't bother to remember anything. I maintain a to-do list of tests that I need to write, and I cycle continuously through "write test --> write code --> check-in". If I forget something, the tests tell me immediately.

This has meant a lot to my productivity as I get interrupted a lot. ;-)

2/12/05 - Updated wording.

Creating Abstractions

2005-02-08T09:58:00.000-08:00

To properly write testable code, you need to be able to test your objects in isolation. In practice, this means that your objects must only depend on abstractions that can be easily stubbed out.

Wagging the Dog

How do you know what to pull out into an abstract interface? Let's look at an example.

class Dog
{
void bark();
void setOwner( PetOwner* o );
PetOwner* getOwner();
}

You might want to just abstract the whole thing, like this:

struct IDog
{
virtual void bark() = 0;
virtual void setOwner( PetOwner* o ) = 0;
virtual PetOwner* getOwner() = 0;
}

This is often referred to as the pimpl idiom , but it has some problems.

- It presupposes that all clients want to deal with a Dog, forcing clients to write different implementations for cats and parakeets.
- It is harder to mock, requiring you to mock the whole beast rather than the one part that you care about.

We have achieve physical isolation of the Dog code, but have not logically decoupled anything.

Consider Your Clients When Creating Abstractions

When you create an abstraction, remember that you are defining an interface between two units of code. You need to take into account both classes, rather than just one. Sometimes, this can be tricky, but fortunately, TDD helps us to learn what the needs of both classes are.

And we have some rules of thumb to guide us. When we create abstractions, we may want to consider abstracting capabilities and roles.

Capabilities

A capability is an interface that, you guessed it, denotes the ability to do something. By convention, capability class names end in "-able", like ISerializable or Serializable.

By pulling a capability into its own interface, you make it easy for clients to get only what want.

struct IBarkable
{
virtual void bark() = 0;
}

It makes it possible for me to write a re-useable client, that works with anything that barks, and not just dogs.

void makeThemAllBark( std::vector& barkers );

Roles

A role is an interface that has a meaning to a particular audience. The same object may fulfill many different roles.

In our Dog example, having an owner is not a quality which is intrinsic to dogs. You can pull that out and say that this is a quality of a pet.

struct IPet
{
virtual void setOwner( IPetOwner* o ) = 0;
virtual IPetOwner* getOwner() = 0;
}

You can add this interface to any class that needs to support "pet ownership" semantics. You might see an opportunity to create one standard pet implementation which you can mix-in to different animal classes.

class PetImpl
: public IPet
{
virtual void setOwner( IPetOwner* o );
virtual IPetOwner* getOwner();
}

The Abstract Dog

Our final class looks like this:

class Dog
: public IBarkable,
public IPet,
public PetImpl
{
// IBarkable
virtual void bark();

// IPet is implemented by PetImpl
}

Things to Say When You're Losing a Technical Argument

2005-02-02T13:32:00.000-08:00

A useful list of ready made arguments, when you find yourself in one of "those" situations.

Things to Say When You're Losing a Technical Argument

How to Organize Your Blogs

2005-02-02T09:30:00.000-08:00

When I first got into reading blogs, and the number of blogs to which I subscribed started to become unmanageable, I organized them by topic. This seems to be a pretty common method, as I see it whenever someone publishes their OPML file.

The problem with topic-based organization is that no one ever stays on topic, as proved by this very same posting to a blog entitled "Reflections on Programming."

Even if every blog did stay on topic, you are faced with a ever growing list of blogs where only some of them are truly important. By nature, you will be more interested in some topics than others. You wind up with 50 subscriptions under "Programming" and just one subscription under "Snow Boarding". You never miss a posting about "Snow Boarding", but you frequently skip Raymond Chen's latest posting, because it gets lost in the noise.

The solution is to organize your blogs, based on their relevance to you. I have three categories: "Must Read", "Should Read", and "Whenever". I meticulously read the stuff in the first category, while I only skim the stuff in the last category. As the blogs evolve, I move them up and down in the list. Sometimes, they fall off the bottom when I am no longer interested them.

Here are my subscriptions on bloglines: http://www.bloglines.com/public/JohnDunne

Note to bloggers: These are organized based on their relevance to me, and should not be construed as a judgment about the overall quality of your blog.

Note to RSS Reader authors: My ideal feed reader would allow me to view my blogs by both category and relevance.

TDD Meets GTD

2005-02-01T09:49:00.000-08:00

In David Allen's "Getting Things Done" [1], tasks are organized in terms of Next Actions. A next action is the absolute next thing you need to do to advance towards a particular goal.

For example, a goal might be to organize your finances. The next action might be to balance your checkbook.

As you complete each next action, you figure out what comes next, and add it to your list. You organize your next actions in terms of the context in which they will be done. This might seem counter-intuitive, but it make sense when you think about it. If you have a big requirements meeting coming up, wouldn't you rather have a list of issues to discuss in the meeting in one place? Other forms of organization, like chronological or topical, fall apart, because there is no guarantee that the timing will work out the way you expect or that you will be able to remember the topics that you created from one day to the next.

In Test Driven Development [2], you constantly cycle between writing tests and implementing the functionality that they test. I find that I sometimes lose my place, and over implement a class, writing code that will never really be needed.

So I started maintaining a "test to-do list". Whenever I encounter a situation where I think I am going to need another test, I just add it to the list. This keeps me focussed on getting tests to pass. When I eventually get back to the to-do list, I sometimes find that I did not need that functionality at all.

Like GTD's Next Actions, I store my to-do list with the test suite itself, so whenever I turn my attention back to that suite, I have a list of outstanding issues.

[1] http://www.davidco.com/
[2] http://c2.com/cgi/wiki?TestDrivenDevelopment

Switching to Feedburner

2005-01-22T17:01:00.000-08:00

After seeing the statistics that Feedburner provides, I decide to follow my colleague, and make the switch as well.

You can now subscribe to this blog at http://feeds.feedburner.com/ReflectionsOnProgramming.

I will let you know how this experiment pans out.

Flickr

2005-01-14T14:11:00.000-08:00

This is a test post from , a fancy photo sharing thing.

Keeping you reading list in del.icio.us

2005-01-13T10:08:00.000-08:00

A while backed, I blogged about how you can use del.icio.us to manage your workflow.

I recently discovered Firefox's Live Bookmarks feature, which allows you to create a set of bookmarks from an RSS feed.

del.icio.us allows you to get an RSS feed for any combination of tags.

Are you thinking what I am thinking?

I created a Live Bookmark called "Reading List" and pointed it at http://del.icio.us/rss/johndunne/toread

I wish my defect tracking system had an RSS interface. I would love to be able to get a set of bookmarks to all issues assigned to me.

Feedburner

2004-12-29T08:06:00.000-08:00

A colleague has recently switched his rss feed over to Feedburner. I will be very curious to see how this experiment pans out.

RSS 0.91 was born on this day in 1997

2004-12-28T11:22:00.000-08:00

Danny Ayers notes that today is the birthday of RSS 0.91.

I remember Microsoft's CDF format and the promise of push technology. I think that "push" fizzled out because dynamic languages, like Python and Ruby, hadn't quite arrived.

With Python's urllib, I can easily play around with XML over in HTTP, whereas doing the same thing in C++ is almost painful.

Your ability to absorb a new idea is directly related to how quickly you can play around with that technology. Expensive, difficult to implement, technologies will never get the mind share that you can get from something which is truly simple.

RSS 0.91 is that simple.

Infrastructure projects

2004-12-23T06:45:00.000-08:00

In the TOC message group, Ron Jeffries made this amusing observation:

"We probably all know of infrastructure projects that have developed huge staffs, gone on for years, delivering nothing and ultimately coming to nothing. Those of us who don't know about these projects should report the color of the sky on their planet, for the benefit of those of us on planet Earth. "The taxi business"

I have to concur. Whenever a project does not target a specific user, but delivers a more nebulous infrastructure, it is highly unlikely that anything will get delivered.

Tool vendors get away with building infrastructure, because at the end of the day, they won't eat if they don't build something that they can sell. Internal infrastructure projects have no such limitation.

Serenity Now!

2004-12-22T14:43:00.000-08:00

iSerenity

Dynamic Languages and C++

2004-12-09T08:01:00.000-08:00

As I read Tim Bray's blog last night, I wondered if plain old C++ had a particularly compelling story to tell in the dynamic language space.

It seems like .NET and Java have a leg up on C++. Yeah -- I know you can write Python extension in C/C++, but you have to do extra work. It seems like with Java and .NET, you get this stuff "for free".

BTW, don't you think that Sun had an ulterior motive in inviting these dyanmic language gurus to their campus? To build up some street cred perhaps?

Tips for using del.icio.us

2004-12-06T09:09:00.000-08:00

I have become a big fan of the social bookmarking site del.icio.us, as you might have guessed, so I thought I might share some tips that I had.

In Getting Things Done, David Allen talks about processing your inbox, which may be either a literal or metaphorical inbox, by periodically purging it. Every item in your inbox gets filed as either a to-do item, reference material, or gets sent to the trash.

Whenever I encounter a link that I find even slightly interesting, I file it under the tag "toread". If I think a link might be worthy of a blog entry, I tag it as "toblog".

Precious Thoughts

2004-12-05T20:56:00.000-08:00

I have a moleskine notebook, and yet I hardly ever write anything in it. It is a beautiful little book, that has this incredible feel of permanence when you hold it in your hand. Every time I open it, I imagine that I am writing something that my grandchildren might one day read.

So, of course, I hardly ever write anything in it.

It is not that I don't value my own thoughts, but that I find it exceptionally difficult to think while simulatenously criticizing what I am thinking. I can only manage to write anything by first spewing out everything in my head, and then going back and editing the resulting mess.

Programming is a lot like writing. It is hard to get everything perfect the first time around, so you hack things out the best that you can, and then make a second pass, fixing the mistakes you made the first time. You only get into trouble when the decisions you made in that first pass are difficult to change, like the notes in my moleskin.

So here is yet another way to define the term "loosely coupled":

Your code is loosely coupled, when you have contrived to house all of your difficult decisions in their own components, so that you may change those decisions without having to touch any other component.

Notes from VS Connections

2004-11-15T13:46:00.000-08:00

I am writing this blog entry, after the fact. I wish that I could have blogged "live", like so many other bloggers, but there just wasn't enough time. These are not all the events that I attended, just the ones that I took notes during.

Day One

The Keynote

The speaker was the product manager for Visual Studio. I wasn't particularly shocked by anything that was said in the keynote. The main point of the keynote seemed to be that they were opening up Developer Studio to more than just the coder role, so that other team members ( project manager, architect, tester ) could find a home there as well.

One neat feature: Visual Studio may now import .VSI files, which contain application templates. Various third parties will be supplying templates for common problems. This is integrated into a search facility, which you may execute from the "New Project" dialog.

Introducing Indigo

Nothing new here since any of the previous Indigo demos that I have seen. I did get a kick out of Indigo's composability, as this has been something for which I have aimed in recent designs. In my case, I am coding in C++ and add new functionality using the Strategy pattern. In Indigo, you can weave in new functionality with .NET attributes.

Windows Forms

90 minutes of dragging controls on to forms. Okay...I get it!

Web Services

It seems like everything is just an attribute that you slap onto a class. I often have a hard time believing that it is simple as adding [webservice] or whatever to a class.

Day Two

.NET

The presenter gave a more general talk about the biz value of moving to .NET CLR.

Generating Windows Forms Interfaces

Some interesting stuff, regarding code generation, databases, and user interfaces, but I think that the fundamental premise, using code generation to automate the building of CRUD forms is flawed. Dialogs should represent business actions.

The presenter did throw out an interesting aside: generating unit tests from method comments. I thought this was pretty cool. I'd love to be able to do this:

/*
multiply
x y retval
10 20 200
-10 20 -200
*/

int multiply( int x, int y ) {}

And automatically build unit tests from the comments.

Whitehorse

Whitehorse is a RAD tool for designing distributed systems. I was impressed with its potential and I very curious to see how far Microsoft can take it.

Day Three

Permission Based Security

.NET allows you to define required permission as attributes. Principal information is stored on a per thread basis. The presentation did not cover authentication, which I would have been a much thornier topic. I would really have liked to have seen the whole thing presented from end to end, as I think that Code Access Security is an incredibly important feature in .NET.

C# Generics

Way cool. A lot like C++ templates, except that you can define constraints on template parameters, which are expressed as required interfaces.

One of my favorite things about C# is that, like Java, it elevates interfaces into first class citizens. I have always found this to be serious deficiency in C++.

Evolution

2004-11-04T15:28:00.000-08:00

I have spent most of my professional life developing traditional Win32 applications in C++. Sometimes, I wonder how relevant this sort of application will be in the future.

Don't get me wrong. There will always be room for that sort of development, but in this increasingly interconnected world, smart clients and web-based apps make more sense.

Adam Bosworth states that web-based apps or services can evolve more quickly.

Well this is where the comment about evolution in action comes in. Things that breed rapidly more quickly adopt through natural selection to a changing environment. Services can typically deploy changes every month or even more rapidly because they only have one single configuration on a set of machines whose OS, storage and networking they totally control and which they manage in their data centers. These days Microsoft gives birth to new products at a pace that makes an elephant seem quick, about every 60 months, that means in the time that a service can make 60 adaptions to its customer's needs, Microsoft makes one. It used to be that they shipped every 12 months. Then 18. Then 24. And so on. The creep is driven by the ever increasiongly complexity of features, hardware, os variations, and backward compatibility of the API's so ably designed to lock developers in. They locked the developers in all right. The Microsoft ones. This alone to me has been a compelling argument that when a product can be delivered as a service, it should be.

Reading this makes me question some of the architectural decisions that I have made recently. The main virtue of a smart client is that it support off-line capability. If you eliminate this consideration, it would seem that a web-based client is always the way to go. I think the only remaining question, is whose tool chain to use?

Next week, I head off to VS Connections, where perhaps the trade-offs will become more clear to me.

Unreflective Actions

2004-11-03T07:27:00.000-08:00

This morning on the Subway, I read Brian Marick's paper, Methodology Work Is Ontology Work in which he says:

I'm particularly interested in unreflective actions, actions people take because they are the obvious thing to do in a situation, given the way the world is.

I think this is a fantastic observation. Brian goes on to build a whole methodology "toolkit", covering a lot of ground from how we learn best practices to what is the best number of core values in a methodology (4), but I think this one quote makes the whole paper.

I cannot count the number of times that I tried to engineer a situation so that the only choice is the correct choice. This one concept may be applied to user interface design, architectural design, and code construction. It reminds me of manufacturing's poka-yoke, a device intended to prevent mistakes.

I wonder what changes I can make in my personal and professional life, so that I choose the correct action without reflection?

Re-usable Code

2004-11-02T14:41:00.000-08:00

Keith Ray blogged about code re-usability as a set of rules.

I will summarize the rules that I like:

Write your class to avoiding depending on other classes (etc).
A class should have one responsibility, delegating other responsibilities to other classes.
A class should not depend on other concrete classes [except the most basic types like String].
To further allow substitution of concrete types, avoid using "new ConcreteClass" within your class -- particularly the constructors.

He goes on to say:

The user of your class may want to subclass-and-override. Make that possible by avoiding static, final, or non-virtual methods, and private methods. Private methods either need to be declared protected, or should be moved to another class and made public, with the original class using an instance of that other class.

And provides a set of rules for making classes easily extensible.

I strongly disagree with this sentiment. Making everything overridable may seem to increase the likelihood that your class will be reused, but it also makes it likely that the implementation of a class will be spread across several classes in your hierarchy. In the long run, this makes maintenance increasingly difficult, particularly if you choose to employ the Template Method Pattern.

I think it makes more sense to prefer containment to inheritance, and to mix in new behaviors with the Inversion of Control pattern.

Geek Test

2004-10-28T06:17:00.000-07:00

A friend passed on one of those online geek tests to me, which my wife proceeded to take for me. Frankly, I was not too shocked when my score turned out to be 42.99%.

Further confirmation of our geekiness came when we spent the evening standing in the dark in Prospect Park, waiting for the lunar eclipse.

GMail

2004-10-26T13:31:00.000-07:00

Jon Udell just posted an article about GMail, where he says:

Because Gmail’s behavior is embedded in the UI engine, all subsequent interaction between the browser and the Gmail service is just an exchange of data. What Hwang calls the DataPack format is not XML, though; it’s JavaScript. When you make a request to the Gmail service, whether to refresh your inbox or to modify the list of labels you can attach to messages, the response is a minimal set of JavaScript function calls and associated data objects that the engine uses to update the display.

This is the very first thing that I noticed about GMail, and it continues to amaze me whenever I use it. I have to imagine that the GMail architecture is extremely scalable.

Wormholes

2004-10-19T09:08:00.000-07:00

Bill Caputo talks about wormholes, which are passages that transport implementation details through your layered architecture.

Martin Fowler follows up, talking about Data Transfer Objects, which are "an object that carries data between processes in order to reduce the number of method calls."

So what's the big deal?

I think that a layered architecture is great, so long as it buys you actual decoupling. If a layered architecture only buys you more layers, it is time to rethink the architecture.

Cleverness considered harmful

2004-10-04T09:03:00.000-07:00

Chris Sells posted this quote today:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
--Brian Kernighan

I tend to carry around a toolbox of not very clever, tried and true, techniques that I trot out for nearly every problem. This is probably a little reductionist, but it keeps me from getting into trouble. I used to get in trouble a lot.

When I find things are getting complicated, I know this is a sign that I don't really understand the problem. Sometimes, though, you need to write clever code to get to a place where you know enough to simplify it.

Still, this is a great acid test. If you find that you are stretching your mental limits just to write the code, then what chance do you have to maintain it?

Moving my blog

2004-10-03T19:50:00.000-07:00

I have had a similarly titled blog on bloglines for some time, but bloglines does not present a very easy way to edit this blog, so I am moving over to Blogger.

The topic of this blog is computer programming, but I will probably avoid talking too much about the various technical tips and tricks that are covered so throroughly elsewhere.

I am more interested in design techniques, project management, and the little things that make the day to day slog through coding fun, rather than a chore.