admin

With the New Year quickly approaching, it’s not unusual to find people thinking about changing positions or jobs and with that in mind Rob Farley has posted an intelligent and insightful piece of the subject of handing over one’s responsibilities at the end of an employment.

I really like Rob’s suggestion that a handover be ‘practised’. It’s a bit like factoring in ‘mock’ database backup restores into an overall risk strategy plan (I have witnessed first hand, 2 large engineering companies being caught short, by not checking that there was actually something on those backup tapes, that they were sending offsite to a fire safe for 2 years!)

If you haven’t heard, Visual Studio 2005 SP1 has been released. You can download it from here. Charles Sterling talks about some of the improvements here.

OK, hopefully that title got your attention! More about it later…

I’m starting to realise that a technique I’ve successfully used to build applications in the past is closer to Test Driven Development than I had imagined. Namely creating paper based screen mockups, acting these through putting yourself in place of the user, and then building live prototypes. Let me begin at the beginning…

Last week I purchased an e-book from 37Signals, “Getting Real: the smarter, faster, easier way to build a successful web application”. It cost US25) and was well worth the money. But check this out; you can even read it for free here! Free! How cool is that?

It says ‘web’ in the title, but it is equally applicable to non-web based software. The idea is to minimise non-executable artifacts (i.e. not actually running in the application), such as doco, diagrams etc…This is very similar to the theme that runs through agile development.

• It’s about staying small (and agile).
• It’s about less of everything that’s not essential.
• You start with the interface, the actual screens that users will interact with.
• It’s about short iterations (just like agile), and reducing the cost of change.
• And more specifically, it’s about delivering just what customers need (just like agile).

Just like TDD, we deliver better results because we are forced to think about the actual problems we are trying to solve, rather than our ideas about how they should be solved.

[I did a short stint at a home loan company where they did things the opposite way: create a load of throw away, static mock up screens rather than real pages, and produce documentation that is out of date the minute you publish it. But I digress…]

I was amused to see a quote from the Elements of Style, on vigorous writing, as I blogged about the similarities in the process of software development and ‘good’ writing a while ago here.

One description that really stuck in my mind was: bloated, forgettable software dripping with mediocrity. Gotta love that for a put down!

OK, so we come to the central tenet of this eBook: you don’t need tons of money or a huge team or a lengthy development cycle to build great software. Less software, less code, less mass. More simplicity for your users. More user buy-in and more users who are passionate about your product.

Here is some of the condensed ‘Getting Real’ advice:

Use a team of three for Version 1.0
Start with a developer, a designer and someone who straddles both worlds. Starting with a small team will force you to make trade-off decisions early in the development process. Such a small team will communicate more effectively and efficiently than a larger one.

Let limitations be your guide to creative solutions
You are never going to have enough of all the things you would like; be it time, money, people etc. Don’t worry! Constraints are great for driving innovation and putting the brakes on ‘feature creep’

What does your application stand for?
What makes it different than other similar products? Why is there a need for it? Before you even think about coding you need to know the purpose of the product you are going to build – the vision.

Ignore details early on
Always work from large to small. Let the details reveal themselves as you use what you are building.

“Getting Real” continues for a good 130 pages more than I’ve briefly skimmed over here. It’s worth a read.

I came across this One Minute How-to podcast site while browsing my feedburner stats. It’s a great idea and not unlike the theme behind DailyDevelopers, with an even larger range of topics. I love the idea of explaining something in just a minute!

Here’s a brief overview of TDD:

1. Write a test that fails (it fails because code that it tests is not written yet)
2. Write just enough code so that the test passes
3. Re-factor the code
4. Repeat from step 2 until code is baked, then repeat from step 1.

Brief guidelines for good unit tests:

• Write simple tests (if a test requires complex configuration and setup, it will eventually fall into disrepair).
• Test one scenario at a time.
• Tests are your specifications. Well written tests provide working specification of the code they test.
• Name your tests accurately and consistently.
• Use data that makes tests easy to read and understand.
• Write tests that run quickly.
• Make each test independent. You should be able to run them in any order.

The initial result of TDD is that you end up with a suite of tests to rely upon when you refactor your code. It gives you the courage to refactor freely and courageously, knowing that you have a ‘safety net’ that will tell you if you have broken existing functionality (providing you have sufficient test code coverage). But TDD also forces you to think like a consumer of your own code, with the positive side effect of producing cleaner, simpler designs.

The TDD sequence is often represented as follows (Note: Not the usual sequence for traffic lights!):

• Red: Write a test (that fails)
• Green: Write code to make test pass
• Amber: Refactor until Green again, then repeat back at Red

Here are a few resources:

Books:
Test Driven Development: Kent Beck. Addison-Wesley.
Refactoring: Martin Fowler. Addison-Wesley.

Web:
http://www.agiledata.org/essays/tdd.html
Test-Driven Development in .NET by Peter Provost. An easy to understand introduction to TDD and unit testing.

Charles Petzold (yep, that one!) has released a free, downloadable book aimed at C/C++ programmers that are embarking on the transition to C# and the .NET framework.

His blog post is here .Net Book Zero Now Available

Pro C# 2005 and the .NET 2.0 Platform, Third Edition

This book is clear, well written and does not sacrifice any depth despite its broad coverage. Although targeted at developers with a few years experience, it is one of those rare books that is good no matter what your level of experience. The style is very polished and the book’s topics flow easily into one another.

One notable and surprising omission of .Net version 2.0 features was the BackgroundWorker class. This is a very useful feature of .Net 2.0

This is one of two Apress books that I purchased 6 months ago, after researching what books were on offer for version 2.0 of the .Net framework (the other was Pro ASP.NET 2.0, which I hope to post a short review presently). As an aside, I’m not sure whether Apress still offer this, but when I purchased this book I was also able to download a free, fully searchable eBook as well.

We (myself and Alistair Waddell) have organised a User Group event along the lines suggested by Rob Farley (great advice and tips BTW, thanks Rob), namely a ‘have a go’ meeting when anyone is invited to stand up for 10 minutes or so and give a talk on just about anything (even non-technical, if they like). It’s happening on the 7th Dec, at the Excom facilities, level 2, 23 Barrack St.

The details are here; I’m really looking forward to it. Everyone is welcome.

This will be the last session before Xmas, so come along and have fun, learn something and network with like minded people over a few after-session drinks.

Kent Beck makes the following observations, in Martin Fowler’s book, Refactoring:

• Code that is hard to read, is hard to understand and consequently hard to modify.
• Programs with duplicated logic are hard to modify.
• Programs that require additional functionality that requires changes to existing code are hard to modify.
• Code containing complex and convoluted conditional logic is hard to modify.

When should you refactor?

1. When you add functionality.
2. When you need to fix a bug.
3. When you perform code reviews.

When shouldn’t you refactor?

1. When you really need to rewrite from scratch!
2. When you are close to a release deadline.

My favourite product is getting great press.

Between December 2000 and November 2006, external researchers discovered 233 vulnerabilities in Oracle’s products compared with 59 in Microsoft’s SQL Server technology, according to NGSS, which has worked for Microsoft in the past to make its software products more secure.

…

The NGSS report comes at a time when security researchers, irked by what
they consider to be Oracle’s glacial pace of fixing bugs, are increasingly turning their attention to its products.