Martin Parry

Microsoft Azure as a driver for efficient programming

2008-10-28T11:58:00Z

Microsoft announced Azure at the PDC yesterday, and it's got me thinking in all kinds of directions.

I've been an occasional visitor to StackOverflow.com since it launched a while ago. I can't say I've been an active participant - my reputation is only 271 at the time of writing, but even with my occasional visits I've noticed a theme that comes up in quite a few questions: does it matter whether I write efficient code? This manifests itself as people asking whether those "pure" computer-science topics like algorithmic complexity and computability are worth learning, and also in answers to many questions that were not obviously about performance or efficiency.

Right now, Microsoft seems not to have decided exactly how it will charge for host applications on Azure, or how it will charge for use of its hosted services, but it seems likely that the cost will be some function of resource usage: CPU time and storage space used, for example.

So, for people targeting that environment with their applications, there could be whole new reason to design efficient applications: it'll be cheaper to run. Ok, I guess that's always been true but it's often been somewhat hidden among the other costs of maintaining an application. If/when the business starts receiving bills from Microsoft quoting amounts of CPU, storage, and other resources consumed by your application, you could make yourself very popular by shaving a few percent off those bills :-)

Some Thoughts on Software Performance

2008-10-27T19:17:00Z

In recent years I've done quite a bit of performance and scalability testing of apps on the Microsoft platform. I know plenty of people who are more knowledgeable about software performance than I am, but at the same time a little knowledge about how to measure and affect performance in software is a surprisingly rare commodity. I guess it's a skill-set that not many people have the time and/or inclination to obtain. Certainly, I only learned what I know because employers have put me in positions where I've had to learn that stuff.

I'm glad they did, because it's a fascinating area. One of the things I like about this area is that so much of it appears counter-intuitive at first glance. I'll give you some examples...

1. Low CPU usage - good or bad?

Let's say we have some code running on an application server. We test it by submitting a certain workload, and it takes a few minutes to work through it. We observe the total CPU usage to be around 50%. I've been in this situation countless times, and more often than not, people look at the CPU usage and say "great, our code is efficient, we have CPU to spare". But let's look at that again: CPU 50%, and it takes a few minutes to work though the workload. The right observation would be "why isn't my CPU running at (or near) 100%, and getting through the workload quicker?"

Perhaps because people are used to things slowing down when their desktop CPU creeps towards 100%, they assume that high CPU is bad. On a dedicated application server, low CPU is bad, because it means that something is preventing that server CPU from working as hard as we'd like. That is, we want the CPU to be working harder doing useful work. Obviously there's no point increasing CPU work if our workload isn't processed any quicker.

So in our scenario, we can say that either (a) we're not generating the workload quickly enough to keep the CPU busy, or (b) the app is constrained by access to other resources, such as I/O on network or disk, or maybe contention around locking constructs. Either way, we need to do some work to relieve that constraint and get the CPU working harder.

2. Asymmetric CPU usage

I'm sure I don't need to say why parallelism is important. We in the software industry need to get much better at concurrent programming I think. Most of us now have multiple CPU cores in our development machines. That means, if we don't look in the right places, we might get a misleading view of the CPU usage in our applications.

It's surprisingly easy to build a .NET application that does most of its work on one specific thread. This is particularly true of a Windows Forms desktop application. I've seen apps that, although written in C#, were essentially VB6 apps because only the UI thread was used for doing any work. On a dual-core machine, you might see something like this in task manager…

If you only ever look at an aggregated CPU usage value, you might be proud of the fact that your CPU usage never goes above 50% (although as I said in point 1 this is not necessarily something to be proud of). In fact, this is showing a real problem in the design of your app, because no matter how you upgrade your hardware you're unlikely to make this app go any faster.

I guess I should admit that, right now, the app I'm working on looks a little bit like this. Physician heal thyself, etc.

If you're using perfmon to analyse your app's CPU usage, you'll want to use the Process object so that you can view CPU usage just for your app's process(es). It's worth pointing out that the CPU counters in the Process object go up to more than 100%. If you have two CPU cores in the machine, it goes to 200%, or 400% for four cores, etc.

3. Extrapolation

One of the most interesting human factors around software performance is the common belief that software performance behaves linearly as variables change. You most often see this as people trying to extrapolate performance figures to assume how software will perform on bigger hardware, with greater data volumes, or with more concurrent users, etc. In general, it's safest to assume that you simply cannot extrapolate.

When you're working to improve the performance of an application, you find the first problem; let's say your app slows down to the point of being unusable when you're loading a large quantity of data into it. Someone might say "ok, we'll work on getting that data loading problem fixed. In the meantime, you find the next slowest part of the app and work on that". The problem with this is that "the next slowest part of the app" might well be different when you manage to get that larger quantity of data loaded. The slowest routine to operate on 100 items may not be the slowest routine to operate on 10000 items.

In many ways, improving the performance of an application is like mending a leaky garden hose. You find the first problem and fix it, then you see the next problem and fix that, then the next, etc.

Mac vs. PC

2008-10-14T21:04:01Z

I have a Mac. Nothing fancy, just a small MacBook. I don't think it was a reaction to leaving Microsoft. In fact, I dual-boot it with Windows Vista. I need Vista because I am a Windows developer, after all. Having said that, I have grown to like the Mac. These days I'm doing most of my admin in the Mac partition, although I do use Microsoft Office:mac 2008.

Curiosity got the better of me, and I decided to try my hand at development on the Mac. I should say that I was a C and C++ developer earlier in my career, which makes it easier for me to adapt to Objective-C Cocoa development than would be the case if I had only done .NET development.

There's a lot I could say by way of comparison between Mac Cocoa dev and .NET development for Windows. Maybe I will say more about it at some point. For now, let me just say that .NET developers have a much easier time of things than our Mac brethren.

Some of my time at Microsoft was spent in a marketing group, and one of the facts of life there is that, among all Microsoft's customers, developers are some of the harshest critics of the company. All I can say is, some of those developers should try building apps for the Mac. I think they might have a bit more love for Microsoft afterwards :-)

For a long time Microsoft has courted developers. I think their focus on maintaining a productive development platform has helped their success in no small part. Apple on the other hand seems to do almost nothing for developers. Their online documentation is extremely dry compared with MSDN, and their development tools are idiosyncratic, to say the least.

So, .NET developers, consider those worse off than yourself :-) And if Apple ever gets its act together and produces an online developer marketing channel* to rival MSDN then Microsoft will really have something to worry about.

I haven't given up on Mac development. It's harder, but that's not necessarily bad. It's always useful to have more strings to your bow.

*yes, MSDN is a marketing channel. You knew that, didn't you?

Microsoft's Bad TV Advertising

2008-10-14T20:59:26Z

I just saw one of the latest batch of Microsoft TV adverts (I'm in the UK by the way). As usual, it's banal, and leaves me wondering what the heck it was trying to say. For such a wealthy company, Microsoft has some shockingly-bad TV commercials. When I worked there, I seem to remember that most of my colleagues agreed.

Look at the Mac vs. PC campaign run by Apple (which I guess this new Microsoft ad is playing on). They were fun. Enjoyable to watch. They made a point. People remembered them. All this Microsoft ad ("I'm a PC") did is remind me of the Apple campaign and help cement Apple's message in my mind.

Source Code Management Changes

2008-09-25T12:24:00Z

I currently spend a lot of time working on a development project with a client, and on that project we recently changed our source control system. We were originally using ClearCase, and it's hard to be too critical of ClearCase. I mean, it's been around for a long time, and it's still in use on some of the largest and most complex software projects. It can be quite hard to get your head around the first time you use it, but if you're working on one of those large, complex software projects, I suppose you'd better be up to understanding ClearCase.

Anyway, for various reasons our project recently changed from ClearCase to Perforce. From where I stand, these two products couldn't be more different : -

ClearCase costs a lot of money (although I'm sure it's worth every penny) whereas Perforce has a sliding tariff starting from "free".
In ClearCase the default working paradigm is that everyone has a private branch. They can check in/out on that branch without affecting anyone else, and when happy they integrate back onto a shared branch. Perforce supports the idea of branching but it's a less-frequently-used option. The normal model is one of multiple concurrent checkouts; an idea which I've found a bit daunting in the past, but which seems to work very well in practice.

Both products have been totally reliable for me, in the sense that we haven't lost any work because of them. I also feel like I'm being more productive with Perforce, mainly because in our environment a ClearCase integration operation could take quite a few minutes, whereas everything I do with Perforce is more-or-less instantaneous.

Because you can download and use (with some limitations) Perforce for free, I have it installed on my personal development systems as well. I really like using the same tools everywhere. Even my Mac OSX system has Perforce installed, and the client app looks/behaves the same everywhere.

Congratulations to Perforce. I like your product, and I like your business model. And they didn't even pay me to write this :-)

Debugging FileNotFoundException

2008-08-15T15:54:03Z

Recently in our app we were getting a System.IO.FileNotFoundException. The trouble was, the exception detail didn't tell us what particular file was missing. Our .NET app has a dependency on a COM DLL, which in turn has good, old-fashioned, dynamic-linkage dependencies on other DLLs.

Initially, I tried Process Monitor from sysinternals to log all filesystem access, but no joy there. This clearly wasn't normal File I/O, it was a module load that was failing. By the way, you can run those sysinternals utilities directly from http://live.sysinternals.com now, which is handy.

There might be a simple way to resolve this problem, but I couldn't think of it, so I resorted to a fairly obscure method, involving WinDbg. When I was at Microsoft we used to joke that Microsoft really has only one tool, and WinDbg is it. You can do everything in there. It's not easy to get started with it, but I do recommend persevering. It's best if you work near someone that already knows it, and get them to show you.

I guessed that the failure was occurring in a call to LoadLibrary or LoadLibraryEx, so I wanted to put a breakpoint on those functions and look at the string that was passed in - the name of the module to load. Here are the commands I entered into WinDbg...

bp kernel32!LoadLibraryW "r $t0 = ebp+8; r $t1 = @@c++( *((long *)@$t0 )); dc $t1 L64; g"

bp kernel32!LoadLibraryExW "r $t0 = ebp+8; r $t1 = @@c++( *((long *)@$t0 )); dc $t1 L64; g"

Each command sets a breakpoint in the relevant function, and defines a command to run when the debugger hits that breakpoint. In each case I find a pointer to the first parameter (which is at ebp+8), then I dereference this pointer and dump out 64 characters found at that address. The final "g" is to make the debugger automatically continue from the breakpoint.

What did this achieve? Well, running the app in the debugger dumped out all the names of the modules that were loaded by these two functions. When the FileNotFoundException was thrown, I just had to look at the most recent filename dumped out and that was the module that failed to load.

Almost done, but not quite. The name I just found is of the module that couldn't be loaded, but it could be found alright. Let's call it "banana.dll". It couldn't be loaded because it had a dependency on another DLL that couldn't be found. To find out what that might be, I did a "dumpbin /imports banana.dll". That told me what DLLs are imported by banana.dll. I just had to look through that list to find the one that was missing from my filesystem.

This is a case of "blogging for posterity" in case I ever need to do this again. Hopefully others can benefit from it too, though :-)

Finally, I have to question the wisdom of using FileNotFoundException to represent module load failures. No wonder the exception detail couldn't tell me which file was missing. Perhaps there should be a separate exception class for this?

On the Nature of Blogging

2008-08-08T13:55:48Z

When I look at the viewing statistics for my blog I see that last month was the biggest month ever, in spite of the fact that I didn't post much, and that I was on holiday for half of the month. Actually, there was quite a big increase compared with the previous month. This leads me to suppose that blog stats can only ever go up.

When I worked at Microsoft, "the management" collected bloggers' stats each month. In fact, it was a key metric that our performance was measured on, and one that I never excelled in. I don't think I'm giving away any secrets there. Sure, when you read a blog that's from a Microsoft employee you can probably expect that blogging is a part of his/her job that they're measured on, but that doesn't make the blog less valuable. Although there are a few worthless ones :-)

In general I think bloggers are seen as people donating their knowledge out of a spirit of generosity, and for a great many that is so, but you should always keep in mind that quite a few blogs are created and maintained just because the boss says so.

I'm sure other technology companies encourage blogging among their staff too. This is not a "Microsoft is evil" post. Blogging has become a very important marketing channel for technology companies.

The good news is that most bloggers who do well at achieving high stats do so because their content is high quality and they keep it coming at a prodigious rate, whether or not their boss is keeping score. But I must say I have known a couple of blogs that managed to achieve high numbers without seeming (to me) very worthwhile. There are all kinds of tricks a wise blogger can carry out that will hugely inflate their stats, more quickly than generating a lot of useful content that a lot of people want. Unfortunately, many employers can't see beyond the raw numbers. Quantity beats quality every time.

When you're reading blogs, why not see if you can tell whether the blogger is playing a numbers game...?

Visual Studio and Stability

2008-07-09T11:33:00Z

I was just reading the lastest MSDN UK Flash newsletter, and was very interested in the survey results. For the uninitiated, each issue of the Flash contains a survey that readers can respond to. In the next issue, they show the results of that survey. The most recent survey question was "What would interest you most around new versions of Visual Studio?" and the largest response (34%) was for "Stability, Reliability, Performance". I find this quite surprising.

In the 8 years I worked at Microsoft, I went through several versions of Visual Studio, including pre-release builds a lot of the time, and I must say I always found its stability and reliability pretty good. Performance was never a problem for me either. This was also true in my life before Microsoft.

But in all those roles I actually installed Visual Studio myself, from a disc or from the network using Microsoft's supplied setup.exe. In addition, I never had cause to install any non-Microsoft add-in for Visual Studio.

Recently I've been using Visual Studio on a machine managed by a customer of mine. They use a 3rd-party packaging system to deploy everything to their managed desktops. I don't know the details of how this works, but I'm guessing that it's some kind of registry/filesystem snapshot.

It's clear to anyone that's installed Visual Studio from a disc that the process is considerably more complex that dumping stuff straight into the registry and the filesystem. Maybe it shouldn't be - I could happily support that view - but it's clear that it is more complex than that. Otherwise why on earth would it take so long, and why would it display messages like "generating scripts"...?

So if we accept that VS is somehow "hard to install" we should probably believe that any 3rd-party packaging tool is unlikely to deduce all the correct logic to use when installing VS. In fact, I find VS decidedly less stable on this managed desktop than I've ever found it to be in the past, on systems where I used Microsoft's setup.exe.

Also, this managed desktop has several add-ins for VS installed. Occasionally VS has crashed and I've caught it in WinDbg, so I know it was at least one of the add-ins that caused the problem. I guess that VS has become a platform in its own right and people are blaming it for faults in components that they've installed on top.

Microsoft used to get the blame for all blue screens in Windows but I think these days most users realise that it's more likely to be a 3rd-party device driver at fault. Microsoft had to educate its customers by capturing data about their software failures and publishing data about the results. Kind of like "naming and shaming" except I don't think they ever published the names of the culprits.

I wonder how many of the survey respondents were using some "odd" deployment tool, or some 3rd-party add-in. Did they think about whose code was running when they experienced those stability issues?

So this survey result makes me think that perhaps the most useful features in future versions of VS would be to capture and publish data about which add-ins are crashing it, and to simplify the setup to the extent that a simple registry/filesystem snapshot is all you need to deploy it reliably.

Herding Sheep

2008-06-24T17:32:33Z

One of the things I find most interesting about software development is the people who do it. I think you can spot personality traits by reading people's code :-) A few years ago, I was introduced to the Myers-Briggs Type Indicator, and I was interested that it seems to categorize people according to 4 axes. I was a little dismissive of it at the time because, of course, a personality is more than 4-dimensional. But as time has passed, and I've met more software developers, and read more of their code, I've started to realize that there are common traits, and there probably are ways to categorize developers.

I should say, this is just idle chat. I am not suggesting that there's anything useful to be gained from this sort of analysis. I just find it interesting. In particular, I don't much care for the idea that an employer might try to assemble a team based on different types. But some days, a difference between types of developer hits me right between the eyes, and today is one such day.

Have you ever read some code and found a comment like "was getting unexpected exceptions here, but with this Sleep(500) it works ok". To my mind, the person who wrote this didn't feel in control of the machine. It's like "one man and his dog". I mean, the shepherd and his dog might consider themselves to be in control, but in reality the sheep have brains too. Ultimately it's their decision whether they walk into the little pen. I guess their thought process is something like "I might as well go where he wants, otherwise it's another 15 mins of being chased around the hillside".

But computers are even more stupid than sheep. You can try to coax it into doing what you want with little things like Sleep(500), but it has no concept of "you've been debugging me for hours now, I'll just give in". So coaxing and goading a computer into doing what you want is not an effective approach. You need to grab hold of it and make it do your bidding. Instead of the Sleep(500), when the exception happens, debug it. Find out exactly what's happening and then stop it happening. Master the machine.

So some developers are masters of the machine, while some are shepherds. In truth, I don't think it's a binary choice, it's more like a spectrum; master at one end, shepherd at the other. So...

M <------|------> S

...whereabouts would you put yourself on that spectrum?

SQL 2008 and SQL Compact 3.5

2008-06-20T12:33:17Z

I've been using SQL Server Compact Edition v3.5 for a little while now, and while the database engine has performed faultlessly so far, the same cannot be said of the management tool that's built into VS2008. Perhaps that has improved with SP1 of VS2008, I haven't checked yet.

Today, I downloaded the release candidate of SQL Server 2008, just to get the management tools and see if I can connect to my SQLCE3.5 database from there. I can, and it seems to work well. I must say that I haven't spent long working with it yet, but it's great to have access to some of the features I'm familiar with from "normal" SQL Server, such as a graphical view of the execution plan.

Of course, it's still a release candidate. My early optimism might soon wear off :-)

DesignMode in Windows Forms control development

2008-06-17T13:21:00Z

I'm currently working on an app that has to run on v2.0 of the .NET platform (with no SP applied). The particular behaviour I'm talking about may have changed in more recent versions - I haven't had time to check - but I was struck by something and just had to write about it.

When you're working on a UserControl, Visual Studio sets the value of a property DesignMode to true whenever it loads your control into the visual designer. This allows you to ensure that any code that depends on runtime artifacts doesn't run in the designer. But if you search, you'll find lots of folks bemoaning the fact that DesignMode isn't set before the constructor of your control runs. Again, maybe this has changed, I should check...

That means you have a problem if code in your constructor depends on constructs that are only available at runtime. There are a number of workarounds posted on the web, but none of them struck me as very nice, and some just didn't work for me. So I did the "obvious" workaround. I took the code that couldn't run in the designer, moved it out of my constructor and into a separate function, and did a check for DesignMode there. It works fine.

Now my control has a simpler constructor. It just initialises fields with values that are always the same. All the logic that calls into other parts of the app has been moved into my new function. I feel that my control is somehow "less-coupled" to other parts of the app now that I can construct it without those things being there. It feels more correct.

What's the catch? Well, something has to call my new function. That could be the code that instantiates my control, or I could call it from my own control's Load event handler, or from some other event handler inside my control. In my case, I chose to let the calling code do it. it worked fine but I still walked away thinking I'd made my codebase more complex to workaround an "issue" in VS2005.

But today I was doing further development against my control. It struck me that the additional function I introduced has actually allowed me greater freedom in the way I initialize the control and has actually simplified my codebase in the end. The feeling of correctness I got from refactoring the constructor was borne out in my ability to reuse this control in ways I didn't anticipate.

There's a lesson in that. You might feel coerced into writing code a certain way, just to workaround a quirk in your tools or platform, but that doesn't mean the workaround is actually worse than what you originally intended. It could be better.

The Campaign Against .NET Obfuscation

2008-06-13T12:27:53Z

I've started a one-man campaign. In fact I started it years ago when .NET obfuscation first appeared. I don't like any of the .NET obfuscation technologies. I don't think obfuscation is worth bothering with, and it makes the developer's life just a little bit harder. So don't do it.

Think about it...

1. Obfuscation is not encryption. That's really important.

2. People being able to see your code is not a bad thing most of the time.

3. If you have a case where it's really necessary to hide your code then, by definition, obfuscation isn't good enough. You need to encrypt that really sensitive piece of code, perhaps using something like Microsoft's SLPS. Even then, only encrypt the sensitive stuff, not the whole app.

4. .NET didn't change anything. Native code is not encrypted either. If someone can benefit from reverse-engineering your code, they are just as likely to do that to a native-code app as for a .NET app.

5. Obfuscation might deter the very casual observer, but how many casual observers fire up ildasm or Reflector? Honestly? And how much harm do you think casual observers will do to your business?

6. The ability to run ildasm and Reflector over my code is very useful to me, and makes me more productive.

7. Obfuscation might give your company a feeling of protection that it really doesn't offer.

8. No matter what the obfuscation-tool vendors do, the debug process is always slightly more complicated for an obfuscated app. If there was some value in obfuscating, this might be ok. But there just isn't.

Why I Don't Use Windows Forms DataBinding

2008-06-13T12:25:20Z

I have two reasons to eschew Windows Forms databinding. Complexity and Performance. As is usually the case, these two are related. You see, Microsoft designed databinding to accommodate a wide variety of controls, and an equally wide variety of datastructures. Because they couldn't predict exactly what we'd build, they designed a very flexible framework. But flexible often means complex, and slow, and in my opinion both are true here.

Controls and datastructures that are built into the .NET Framework typically "just work" when you bind them to each other. At least, that's been my experience. I think the same is true when you use controls that are supplied by any competent vendor. But if you try to create your own controls and datastructures and bind them together using Windows Forms databinding, you might find things get rather difficult.

As I've said before, don't use a tool if you don't understand what it does, and to fully understand Windows Forms databinding takes quite a bit of work.

Let's say you build a form and bind that to some complex datastructure of your own. First you have to understand databinding well enough to make it work as expected. Remember, you'll create the associations between controls on your form and data items in your datastructure, but the exact moment that values get copied backwards and forwards is not under your control. That single fact makes your code hard to maintain, in my opinion. Anyone trying to modify your form or your datastructure needs to fully understand databinding in order to know that it will continue to work as expected. And if at some point the binding isn't working as expected, someone will have to fully understand databinding in order to figure out where it's going wrong. Before you know it, everyone in the team has to understand databinding.

What's wrong with that? Well, surely to goodness the whole point of abstracting relationships between controls and data is to simplify. If everyone has to go and learn a somewhat complicated body of code in order to maintain your app, that simplification goal has gone awry.

Remember, Microsoft built databinding because they didn't know what types of controls, and what types of datastructure, we were going to create. To bind our controls to their data, or their controls to our data, we can use databinding. When we own the controls and the datastructures, we just don't need a flexible binding framework that can bind anything-to-anything. We can actually write obvious code that works intuitively to copy values from A to B. That might mean more lines of source code in our app, but it's a lot fewer lines of code being executed at runtime, and it's a lot more straightforward to maintain.

Ok, that's the complexity issue dealt with. I just want to say a little about performance. I accept that for most desktop apps Windows Forms databinding performs perfectly adequately. I happen to work on an app that's unusual in that, at times, it needs to update a lot of data on the screen very rapidly. I mean, much quicker than a human being can actually absorb. But we can't predict which value the user will want to look at, and when they look at it, it's got to be a very recent value. I mean, certainly no more than 100ms stale. If you know how Windows Forms databinding works, you'll know it doesn't lend itself to updating a lot of data that rapidly. This isn't a criticism of databinding, but it's worth knowing. I guess it wasn't designed to do this.

Because databinding towards the control is triggered from a property change in the underlying datastructure, any such change has to happen on the UI thread. You know you can't modify controls from some background thread. But when you're getting a lot of updates, you really need to minimize the work being done on your UI thread. I mean, it should really just be painting the screen and nothing else. I don't want to be managing my datastructure on the UI thread, rebuilding indexes and so forth. I want that to happen on another thread, then my UI thread can simply ask 10 times per second "what value should I draw here?". . And I certainly don't want to be creating objects to describe the property that just changed, simply to communicate that change to my control in a totally extensible and flexible way. I know what my datatypes are and I don't want to see source code that passes around property names as strings. That stuff just gives me the colliwobbles.

So there are two reasons why I'd rather not use Windows Forms databinding in my current project. The performance reason probably doesn't matter for most apps, and perhaps not for certain parts of my own app. The complexity reason on the other hand, well, that's the big one.

Simplicity in Software

2008-06-13T12:21:20Z

I think most of us developers would agree that keeping our software as simple as possible is a noble aim. I guess there are some developers who like to make things unnecessarily complex, but I for one hope not to spend too much of my life maintaining their code. I'm sure that no reader of my blog would fall into that category. No, we're talking about "other people" now.

Anyway, simplicity. What does that actually mean? I can think of a few definitions; I'm sure there are others...

1. Fewest possible lines in your source code.

I'm sure we've all seen those pathological examples where a whole lot of meaning is crammed into a few characters. Normally these examples are in C although I've seen good ones in Ruby and Perl too. So clearly simplest != fewest characters.

No, these things are clearly not "simple" in any practical sense. But, to some extent at least, trying to minimize lines of source code is a good idea. If you can make things clearer by removing code, do so. If removing code makes things less clear, don't do it.

2. Smallest amount of code overall.

I'm not talking about highly-optimized code necessarily. You could write few lines of source code yourself, but behind those few lines could be millions of lines of library or API code. People maintaining your code are probably affected by the complexity of code that yours calls, so it might be a good idea to give some thought to the particular calls you make and just how complex those implementations are. Of course, that has other benefits too.

3. Simplest logic.

Trying not to have too many nested levels of if/else with complicated, inter-related condition clauses. That's probably a good idea.

4. Most "obvious" code.

Is it better to have more lines of code that clearly copies values from A to B, or is it better to use some data-binding API that allows you to set up relationships between A and B, without knowing exactly when the values get copied? Me, I prefer to be in control and I'd rather suffer a few more lines of code if their meaning is explicit. Actually, Windows Forms data-binding is currently out-of-favour with me. I'll write about why in a separate post I think.

All my comments above assume that creating "simple" code is your top priority. In some cases other priorities come first and that's quite natural. Performance, security, or customisability could all lead to more complex code for example. But the goal of creating complex code for its own sake comes nowhere in the top-100 priorities of a software developer. If it's not already clear in your team, why not ask the person in charge to prioritize the various aspects that your system could exhibit...

1. Performance
2. Correctness
3. Maintainability
4. Security
5. Scalability
6. etc. etc.

...and assuming that Maintainability appears in their list, drill into that a bit further. Do they want the code to be "simple"? What do they mean by "simple"?

Rant about "Quiet Carriages"

2008-05-28T12:38:00Z

Moving away from my normal topic of software development, I just wanted to vent some annoyance about "Quiet Carriages". On the rail service I use, the operator designates 2 of the 8 carriages in the train as "quiet". They request that you don't use mobile phones or personal audio equipment in those carriages.

Now, here's a non-exhaustive list of the things that other people can do to annoy you while on public transport, in no particular order...

Hum or whistle a tune
Sniff loudly and incessantly
Clear the throat loudly and incessantly
Laugh out loud for no apparent reason
Rustle their newspaper
Get up and walk around for no apparent reason
Converse on a mobile phone
Converse with fellow passengers
Make lots of beeps from their laptop computer
Type loudly on their laptop computer
Eat smelly food
Suffer from unpleasant body-odour
Sit next to you and take up too much room
Listen to music through earphones that emit that "tickety-tick" noise
Spread their things all over your table
Tap hands or feet in time with some unheard music
etc. etc.

I've certainly experienced all of these things on British trains, and it didn't take me long to produce that list.

Why then would a train operator pick on just two of those potentially anti-social activities and forbid them in 25% of every train? I say potentially because I've certainly seen people use mobile phones responsibly - in silent mode, keeping their voice down, keeping calls short - and I've sat next to people using personal audio equipment that emitted no external noise detectable to me.

I've also seen a respectable-looking man run the length of a carriage to berate some unfortunate whose mobile phone rang in a quiet carriage. The poor guy didn't even answer his phone, he was just unlucky enough for it to ring, and he silenced it as quickly as he could. The elder vigilante wore a maniacal expression as he leapt into action and exclaimed loudly "this is supposed to be a quiet carriage". Now, whose action was the more distracting for his fellow passengers? In case you're wondering, the phone user wasn't me, but it might have been.

I use these trains during peak times, and frankly you're lucky to get a seat at all. For the train operator to suggest you have a choice of sitting in a quiet carriage or not is ridiculous. They just make no sense to me at all. I suppose most people of ticket-buying age can remember a time before mobiles, and before the walkman, so maybe this is an attempt to outlaw the new-fangled tools of distraction. I think when our children are grown up the quiet carriage will be a thing of the past, remembered as a quaint curiosity like when all cars had to be preceded by a man waving a red flag.

A lot of people either want or need to work while on a train, but surely most of those people work in open-plan offices? I can't believe a train carriage is a more distracting environment than your average office. Perhaps I'm lucky in that I'm able to switch-off from my environment, and so other people's phone calls don't distract me at all. Even if they did I'd have to accept that my distraction was at least as much my fault as theirs.

In the end, it's a sad commentary on our society that a train operator has to publish rules of politeness. I would be happier though if the rules were about courtesy and respectfulness in general rather than singling-out specific devices, and if we're instructing people on courtesy we should give equal effort to encouraging tolerance. It's a two-way street.