blog.philcrissman.com

There was a lot of discussion awhile back about Facebook and its limit of 5,000 friends. The discussion, in case you (mercifully) missed it, was largely driven by social networking power users like Scoble.

I didn’t think too much about it at the time. Between now and then, I’ve thought a few times about social networks, and how they are implemented. Not the front end, but the back matter; the model. The database; users and connections.

A social network is fundamentally a graph. Most social networks are analogous to non-directed graphs – that is, there is no distinction which “direction” a connection goes. If you are friends with someone in Facebook or MySpace, they are also friends with you. Pownce and Twitter have taken a directed-graph approach, in which friendship (following) is not automatically mutual. I could follow you, but you might not follow me. And so on.

The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is so difficult to rectify later.
- Fred Brooks

Again, I’m going to continue to use “hack” in ye olde sense of interesting and/or excellent coding. And in this context, we’ll let “development” stand for the sort of coding you might do at work; something businessey, something enterprisey. It’s all good. I’ve been writing about this a lot. I hope that’s okay.

When I decided that I wanted to change my career and “go into computers”, I had a very limited exposure to computing.

Well… I should qualify that. It’s true, I had used DOS so much in high school (before there was Windows) that I preferred DOS to the Macintosh of that day, wrote my own autoexec.bat files, and in fact had a copy of DOS, Pascal, and Moria on 5.25” floppy disks that pretty much went everywhere with me. At the time, many DOS PCs did not have hard drives; you loaded the OS from a floppy, then it ran from memory and you put in some other disk with your files or other programs on it.

Okay, the novelty of exploiting use-mention ambiguity wore off awhile ago. That’s okay.

It’s possibly time we stopped considering things harmful. The idea is somewhat puzzling; it seems as though the thing under consideration might not actually be recognized as harmful for any other reason than that we are considering it such. A panel of experts, perched somewhere behind your shoulder, has unanimously agreed that what you’re about to do may, in fact, be harmful. Dispensing with things such as proof, we’ll just consider it harmful and be done with it.

What are you doing? Don’t you know that’s considered harmful?

The trouble with this is that, to be consistent, we can’t even consider “considered harmful” harmful without violating our new rule. You see? That’s what happens when we start inventing considerations without regard to rhyme, reason, or reality.

“You should use iterative development only on projects you want to succeed.”

- Martin Fowler (UML Distilled, 3rd Edition).

NOTE: I’ve had a penchant for just posting quotations, recently. This is mainly because I’ve been swamped with work, but part of that work has included reading or re-reading a lot of software development classics, hence the quotations. For what it’s worth, I’ll try to write something of my own some time soon.

“The discovery of common abstractions and mechanisms greatly facilitates our understanding of complex systems. For example, with just a few minutes of orientation, an experienced pilot can step into a multiengine jet aircraft he or she has never flown before and safely fly the vehicle. Having recognized the properties common to all such aircraft, such as the functioning of the rudder, ailerons, and throttle, the pilot primarily needs to learn what properties are unique to that particular aircraft. If the pilot already knows how to fly a given aircraft, it is far easier to learn how to fly a similar one.”

Booch, Grady, 2007. Object-Oriented Analysis and Design With Applications. Third Edition. Addison-Wesley.

Let’s assume that testing your software is good. We’ll assume that you are working on a larger project, or as part of a team, so we want to test the code. Great. There we are.

Something to keep in mind is that exhaustive testing is not possible. This is not provable, and it would not be true if it were provable.

If it were provable, that would mean that you could locate everything testable within the software, and demonstrate that tests could not be written for all of them. But if it’s possible to locate everything testable within the software, then it must be possible to write tests for all of them.

Of course, showing that something is not provable isn’t the same thing as showing that it’s true… but let’s assume, just for fun, that exhaustive testing is not possible. I mean, exhaustive. Nothing left out. Nothing left untested. No input, output, or circumstance un-foreseen and un-tried. Impossible.

So there will be some things that are not tested. Whatever you don’t test probably has a bug in it, somewhere. That’s also unprovable, and a little bit cynical. It’s also a bit of a tautology. If we assume that all software has bugs (cynical? realistic), we know that the bugs are not in what you tested, because if they were in what you tested you would have found and corrected the bugs. So, said bugs (of whose existence we are confident) must be in the areas which you didn’t test.

Of course, if you’re going to do tests at all, you want to test everything you can; you want to at least attempt to be exhaustive, within reason. Good deal; your manager will be very happy.

For the record, I do think test-driven development is a Good Thing, and that it will probably ensure that, at the very least, your core concerns (whatever you had the foresight to test) will work properly.

But you’ll know that you haven’t tested everything. Because you can’t have tested everything.

Simplicity is a feature. It’s a feature shared by too few software projects, and as such should be highly sought after and implemented wherever possible. Sadly, the reason it’s so often not implemented is because developers do not believe they have time to implement it.

“I would have written a shorter letter, but I didn’t have time.”
—attributed to Blaise Pascal