I was unsure because there is a consensus of small writes to SSDs aren’t as breathtaking as the reads and writes of larger files:

SATA-based SSDs generally exhibit much slower write speeds. As erase blocks on flash-based SSDs generally are quite large (e.g. 0.5 – 1 megabyte), they are far slower than conventional disks during small writes (write amplification effect) and can suffer from write fragmentation.

- Wikipedia

But these things are fast at everything else, and while mulling over the idea of upgrading for a few months, I started to notice my usage patterns of switching between lots of different supporting applications. Given that’d I’d get improvements elsewhere if not in Visual Studio, I decided to try it out for myself.

The SSD I chose is the Corsair CMFSSD-64D1, otherwise known as the Corsair Extreme Series X64:

Here are the timings I took with the original Samsung 80GB 7,200rpm drive, and the timings from the Corsair Extreme X64:
(all timings are in seconds, so lower numbers are better)

Conclusion

Overall, the SSD performs 53.6% faster – that means my machine is twice as responsive as it was.

However, the most important savings to me are loading, and building solutions – I’ve only been running the SSD for a couple of days, but already I have shaken the reflexive pause I felt before closing or restarting Visual Studio, or opening up different solutions.

Granted, building or compiling decent sized projects in Visual Studio on an SSD is not as impressively fast as spinning up applications (Outlook, Paint.Net or Dreamweaver for example), or the improvement in general system responsiveness.

I now get 3 complete builds for 2..  put simply, it’s almost fast enough to remove the build waiting tax. It’s fast enough that I don’t lose my train of thought and context switch to something else – which makes me more productive.

Method

Timings were taken manually with a stop-watch, and averaged over 3 data points on different days.

* The Windows logging in timings include a start-up anti-virus scan.

System Specification and software versions:

• Intel Pentium 4 HT, 3.0 GHz
• 3 GB RAM
• Windows XP 32bit (HDD timings), Windows 7 32bit (SSD timings)**
• Outlook 2007
• Visual Studio 2008 Team System Developer Edition
• The 8 project web solution is the fantastic invoice management software called SNAP, written in C# .Net 3.5

** yes, I’d have loved to have done an apples-to-apples comparison by copying the exact same Windows XP installation over to the SSD, and I was all set to do so, except the Samsung HDD had a series of faults around the ~36GB mark that resulted in an XP installation that would only boot into Safe Mode.

I had taken the timings the week before I found this out, and with a clean SSD it seemed crazy not to take the opportunity to upgrade to Windows 7.  I suspect that had I stayed on Windows XP, the speed improvements would have been more impressive.

Fortuitously, the Corsair SSD arrived the same morning that the Samsung HDD exhibited the fault. (I know what you’re thinking, and no, it definitely wasn’t sabotage.. the SSD was on order for 2 weeks prior, and wasn’t due to arrive for another 3 days)

The Solid State Drive upgrade is a definite improvement, and I don’t think I’ll be buying Hard Disk Drives any more 

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.”  There is no consciousness of effort; the work just seems to, well, flow. You’ve been in this state often, so we don’t have to describe it to you.

Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It’s only when you’re in flow that the work goes well.

To paraphrase, “It’s only when you’re in flow that you’re at your most productive”.

The quotation is taken from chapter 10, page 65. I know that because after reading those short paragraphs, I realised something that made me stop and put the book down..

When a software developer thinks up an estimated time to complete a development task – they’re thinking solely in “flow” time.

That realisation is profound.

Sure, more experienced software developers will then add time to this based on their experience before giving their answer, but their first thought is based on flow-time, which is their best-case, uninterrupted development time.

Why is this?

I think it’s a combination of 2 things;

1. The question itself.. “how long would it take you to do / fix / add / change x?”.
   A developers starting point is their experience of development to date, and that development is at it’s most productive in flow-time. So they’re going to answer you based on them being in productive flow-time. However, this means they’re starting their estimate based on an unaware assumption that they’re quoting flow-time.
   For example, if a developer responds with “it’ll take me half a day”, what they’re really saying is “with a half-day of flow-time, I can do / fix /add / change x”.
2. If you didn’t already know, developers are optimistic. They’re optimistic about how much they can get done, and they’re optimistic about how much flow-time they’re going to have.

So what is the answer?!

To quote more from Peopleware:

Chances are, your company’s present time accounting system is based on a conventional model. It assumes that work accomplished is proportional to the number of hours put in. When workers fill out their time sheets in this scheme, they make no distinction between doing meaningful work and hours of pure frustration. So they’re reporting body time rather than brain time.

…

The phenomena of flow and immersion give us a more realistic way to model how time is applied to a development task. What matters is not the amount of time you’re present, but the amount of time that you’re working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won’t accomplish anything.

The answer, then, is to take the developers estimate with a pinch of salt (the more ‘seasoned’ the developer, the less salt required), remember that their estimate is an estimate, and use it with evidence based scheduling (if you aren’t already).

The next question you may be asking of course, is how do I reduce the difference between the estimate and the actual – the ‘slip’.

That’s a topic for another day. I’ll let you know when I’ve finished Peopleware, or you can grab a copy for yourself