Uncategorized

Darren Neimke posted an interesting question on a situation many developers/managers find themselves in. I’ve quoted it in full below:

You’ve just joined a new company as a senior developer. During the interview process your role was discussed in depth…

1. Lead a development team
2. Deliver a new application
3. Using state of the art tooling
4. Highly ambitious

You start, and in your first few days you are shown more details of the task at hand. The project plan and delivery timeline were created by the head developer – a person for whom you have a great deal of respect. Internally you are no really about how you will deliver this in such a short space of time.

What do you do next?

Even though Darren posted this over a week ago I thought I would chip in with my 2 cents worth and attempt to answer some of these questions, beginning with a few of my own:

Does point #3, do you mean that there is little experience with a new set of tools? Are these tools stable, well documented, well supported? Are we talking about VS2005 Team System?

Point #4: In what way is the project “Highly Ambitious”? For the customer? For the developers? Does this mean it consists of too much scope in an undoable timeframe? If so, it’s time to start pruning non-essential features.

How would you establish that the existing project delivery plan is realistic?

First thing I would do is take a look at the requirements (hopefully, you have some). Talk to the customer, and make sure you understand what they are trying to achieve; in other words, get an understanding of their target domain and how this software will make their task easier/more productive and what the essential features are (“The high level feature list”). If you are going to sign up for, and be responsible for a project delivery plan, then you should verify that what is being asked is achievable.

“Get the feature list from the customer, and then figure out the requirements you need to implement those features”

Next up, do you have a set of use cases (scenarios) describing the high level processes that the application is supposed to perform? This is a excellent way of determining if the features are all supported and the requirements are complete, or if there are there surprises lurking.

“scenario” is often used interchangably to mean one of the following:

1. a use case
2. a path through a use case
3. an instance of a use case

#2 and #3 are really the same thing. #3 is preferred (more than one scenario occurs when the use case has alternate paths, but these still achieve the main goal of the use case)

Each use case must have:

• clear value to the system
• a well defined start and stop point
• an external initiator

As soon as you have a set of use cases, you can perform textual analysis upon them to figure out candidates for your classes and methods (nouns and verbs). By this point, you should have enough information to break up your application into smaller pieces of functionality, and have a better handle on how much development time is required.

Grant Halliday’s comment about working 20 hr days is a little worrying! 😉 If any developer is working more than 8 or 9 hours a day, then you have a big problem. Odds are they will be making plenty of mistakes. There is considerable evidence to back this up. A good plan will not force developers to work unproductive hours. Any manager that thinks he will retain the confidence and support of his staff in doing so, is almost certainly mistaken.

Here is some condensed wisdom for C# programmers from a ‘must read’ book, The Elements of C# Style. This book models itself in the tradition of “The Elements of Style”, and is a similar physical size, which means you can easily read it cover to cover in very little time.

If you program in C#, having a copy of this book on hand will provide a great reference, at least until you commit it all to memory! Some of this sage advice applies to other languages as well:

• Use meaningful names. Names things accurately and consistently
  With the exception of loop variables used as a counter or index within a loop (where using ‘i’ is often more readable than a longer name).
• Use names that exist in the terminology of the target domain
• Do not use excessively long names or excessively short names
• Do not shorten names by removing vowels; use complete words
  It’s not the 1970’s! Your compiler is not going to complain about names longer than 32 chars (Oracle might though!) Take this along with the previous suggestion.
• Avoid abbreviations unless the full name is excessively long
• If you really have to use an abbreviation, use one that is widely used and commonly accepted.
• Pluralise the names of collections
  List cars = new List();
  Car car = cars[index];
• Prefix interface names with “I”
  
• Use nouns to name interfaces that describe service declarations
  public interface IMessageSink
  {
  public void MessageReceived();
  }
  
• Use adjectives to name interfaces that describe behaviours
  Most of these will end in –ible or –able.
  public interface IDriveable
  {
  public void Drive();
  }
  
• Add a suffix of “Base” to abstract base types
• Add a suffix of “Exception” to custom exception types

I did find a couple of typographic errors and one bit of advice which is considered wrong if you go with the recommendations in the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina; namely, point #157 states that you should derive custom exceptions from ApplicationException. These should be derived instead from System.Exception.

Also, quite by coincidence, on a second re-read I noticed that the double-lock pattern used in point #85, should not be used (see my previous blog post which refers to Jon Skeet’s article). Jon mentions that it can be fixed using memory barriers via the volatile keyword, which in this particular example would require the instance of LoanCalculator to be declared as volatile. But, he also mentions that the experts can’t agree on this, and is therefore sensibly avoided!

I believe point #48 should read:
[MyFavouriteAttribute]
…

We are starting the year with an exciting talk by David Lemphers on his explorations into .NET and Robotics, 5:30pm, Weds 10th Jan 2007.

Please note that this meeting will be held at the Microsoft offices, level 14, QV1 building, NOT at the new Excom venue. Look forward to seeing you there!

He is also presenting on SQL server to the SQL UG the following evening at Excom.

Huh?

Having had a few xmas parcels go astray en route from Australia to the UK (not to mention the horrendous cost of postage), a colleague suggested that I simply buy a few things from Amazon UK. Brilliant! Now why didn’t I think of that! Worked so well, I sent two shipments. I came across this image today, and wanted to share it: Amazon UK at xmas! If only software could be written that way…

Just when I was starting to be a Microsoft champion and truly believe they had turned over a new leaf, they go and do something like this: Microsoft tries to claim a patent on RSS (just a few days ago). This is ridiculous and disgraceful! Everyone knows that Microsoft did NOT invent RSS! In fact, they were relatively slow to adopt support for RSS into their products. MS, you need to get those patent guys under control, before they seriously start damaging your newfound credibilty.

Rob Walling has posted an article, Nine Things Developers Want More Than Money, that managers should read, if they want to understand what makes most developers tick. Rob draws upon Frederick Herzberg’s Two Factor Theory.

Just over 1 year ago I left a job at an engineering company in Perth (with its head office in Canada). In the space of just 10 months, before and after I left, my department had a turn over of its entire complement of staff. I mention this, because all of the problems and complaints voiced by the developers are discussed in this post. [This one’s for you Bernie!] On the positive side, everyone that left found better jobs.

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!