Monthly Archives: July 2005

PM#, Project Management

PM#5 – Whose schedule is it anyway?

6 Comments

There was an interesting discussion entitled “is it just me?” over here at Scottish Developers. My reply is here. Anyway, it preempted this posting in some respects, but I’m going to carry on with this post regardless!

Customers and management never seem to believe the estimates developers give them…time and time again, developers provide an estimate of how long a project (or task) might take, e.g. 12 weeks, only to be told (by the customer/management) that it will take 6 weeks. There are many reasons for this sudden shortening of the schedule…many of which revolve around the fact that the customer/management have promised their upstream customer/management something (a software solution) by a given date. An unrealistic date at that.

Who is more qualified to make schedule decisions that relate to software development? Is it the person whose job it is to actually “cut the code” (the most important part of any software project, no code, no project), is it the person who actually does the job or is it the person who has promised a piece of software to their upper management by a certain date?

Despite any potential previous bad experiences, customers and management should learn to trust developers more, they are the most experienced resource management tool a software project will ever see. They have excellent gut reactions, they know when something is “do-able” or not. They can reliably tell you whether something requires 4 hours or 4 weeks to complete. They know their business, inside out.

So why is there such disrespect for developers and the work they do? Why do I hear lots of sob stories revolving around late delivery, “he said it would take 4 days, it took 12 days, his estimates are rubbish”?

The simple answer is this: unless the part of the schedule that a developer is working toward actually belongs to him, realistically speaking, the developer knows he’ll not be able to meet the schedule but will carry on regardless. He has nothing vested in an arbitrary schedule that does not give him enough time to to his job properly. True, the developers will probably bust-a-gut trying to bring the project in on time, however as we know, invariably they’ll fail. But it’s not their fault. It’s the fault of the person who gave them the wildly inaccurate schedule in the first place.

Even if the schedule was remotely accurate and did have input from the developers, other folks exhibit a disturbing lack of respect for the developer and the schedule. A schedule can often be agreed provided that all or some tasks are distraction-free: this is easy to agree at the outset, but rarely happens during the project execution. Similarly, a fully-committed developer has no “resource gap” or free-time, there is no “contingency” in most projects. Therefore, you cannot duly expect to either e-mail or walk up to a developer and ask them to take on other tasks (for other projects) that aren’t part of the schedule…and since developers (and a lot of other good folks) find saying “no” difficult, they can often be [bullied] into saying “yes” to more work that will invariably knock the previously agreed schedule out. The trick here is not to offer developers other work – no matter how important it is to you (your top priority work isn’t going to be the developers top priority, he’s busy focusing on the project.)

Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more manageable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibly moving the project forward in some respect.

Analogy
When you last had you car serviced, you probably gave it to the garage for a whole day. I don’t hear about folks telling the folks who work in garages: “You need my car all day? No, you can have it for 3 hours. Can you get everything that needs doing done in 3 hours?” I’d like to see the state of your car once you get it back…may be not today, but in a few weeks time when you thought all that work had been done…

Example
I have a standalone application – a single .exe that runs on a per-machine basis. A client has requested that we “get it to work over the network”. For us, this is a big job, it requires changes to the backend database to allow the introduction of a user column (at least), transaction support, improved backup/restore, etc. To the client, networking an application is the simple matter of adding a login box at the start of the application. Since that’s all the client ultimately gets to see…”how can that possibly take N weeks to write?!” Perception and explanation are key. As developers we must learn to stand up for ourselves and learn to say “no” to unrealistic schedules: whoever is asking you to commit to such a schedule doesn’t understand how their car works, yet you won’t find them telling the garage to cut their schedule in half…unless they are themselves a mechanical engineer (versus a fitter), in which case they would need to be experienced software engineers in order to discuss schedules with you!

Need to cut the schedule? Well, why not cut the feature set?
If you have a pressing need to cut the schedule, at least negotiate with the developers over the feature-set that your hoping they’ll implement in the shorter time-frame. We know that “80% of a product’s value comes from 20% of its features” (originally from here), surely you can afford to cut the number of features in order to cut the schedule? Of course, now we’re in the realms of controlling the four success variables (cost, time, scope, and quality).

four variables

In the first instance the customer is allowed to select values for any three of these variables. The development team will then choose the value for the remaining forth variable. Ultimately, between the customer and development team there will be a series of compromises and trade-offs resulting in an adjusted set of values, or even trading of variables!

There are interactions between the variables. For example, increasing the time can allow for an increase in quality and/or an increase in scope. Another example might be a reduction in scope: it is possible to deliver earlier (less time) or cheaper (less cost) or possibly with more quality.

It is worth noting that the relationship between the four variables is a complicated one – it is not possible to reduce the time variable simply by increasing the cost variable. Nor is it possible to increase the cost expecting an increase in quality.

Crazy Schedules
Schedule pressure often sees shortcuts (or what are perceived as shortcuts) being taken. Instead of well-structured, reliable object-oriented code, being cut produced, prototypes are built as proof of concept…a little cut’n’paste then follows, prototype code suddenly becomes production code but only after crazy amounts of testing and re-work. It’s a spiral that requires a step back and a re-write to get out of, and may be more than one re-write at that. Crazy schedules will cost you considerable amounts of time and money downstream, they’ll also cost you the respect of your developers too.

Scott Berkun wrote an excellent book, The Art of Project Management, reviewed here, where he cites an example: your client in on the operating theatre table, the brain surgeon tells him that the operation he requires will take 12 hours…you won’t find your client turning to the surgeon and saying “no, you have 6 hours”…This just wouldn’t happen, I rest my case: if programmers or developers tell you something will take 12 hours, give them 12 hours (or more if you’re generous), it’ll protect your reputation, they’ll respect you for it and it’ll give your project more chance of success.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#4 – Start it…finish it

8 Comments

As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).

Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.

I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.

Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.

So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Developer Events

Scottish Developers – eXtreme.NET

4 Comments

Dr.Neil Roodyn came to a sunny Edinburgh to talk to Scottish Developers about eXtreme.NET. Dr.Neil was presenting at a half-day mini-conference; the other session was by Christian Weyer whose slides are available here.

curse
Christian curses that Java compiler!

As the other speaker noted, Dr. Neil spent some 2 hours and 15 minutes talking about writing code…without actually writing any code at all. But that was the intention, and it made for a thoroughly excellent presentation. And it was nearly a full-house, there were only a handful of empty seats.

crowd shot
Nearly a full house!

Dr.Neil kicked off the session with a look at XP’s four values: Communication, Simplicity, Feedback and Courage. He went on to note that respect starts at the top [of the management tree] and goes all the way down to the developers/workers and the customer. Respect is lost when the project manager/client asks developers to do something in an unreasonable time-frame.

The first of many quotes:

Anybody, including a lone developer, is part of a team if they are working on software for a client.

When comparing the traditional cost of change curve for a software project, Dr.Neil makes a potentially emotive statement:

As a system grows, it should not be exponentially costly to make changes.

In other words, the cost of change curve shouldn’t be a curve at all, it should be a straight line that very gradually rises over the course of the project (image to follow)

Audience Poll
Dr.Neil’s quick poll of the audience revealed an interesting statistic. Two questions were asked: 1) who knows .net? and 2) who uses .net? More hands went up for question 2 than did for question 1. I suppose nobody wants to be seen as “knowing .net”, “in its entirety?” Perhaps for fear that Dr.Neil was going to pick on whoever claimed to “know all of .net”…fear not, this would not have been the case, it was merely a poll.

.net, call it what you want, a technology, a platform, a framework, Dr.Neil simply describes it as “cool”, and rightly so. He is using it to help him and his customers deliver high quality business-focused systems within a short delivery time-frame. Dr.Neil knows of a customer with some 85,000 [NUnit] tests, with a 5-day bug fix period and no bug-tracking database (more about this in a moment). The said customer operates on the premise that [the XP] values come first, they throw away anything that degrades those values.

Thinking out of focus
When a new project comes along, the thought process often looks like this:

  • Choose the Technology and the toys (e.g. .net, web services)
  • Choose the Process, Practices and Methodologies
  • Choose the People

This is, in fact, the wrong way around. We should choose the people first, then the process, then the technology. We should drop the heavy focus on writing masses of project documentations (consider the value it adds). Dr.Neil made good use of a car dealer analogy to get this point over: when buying a new car, the deal says to you “the car’s not ready yet, but here’s the manual.” You’d far rather he said: “the car is ready, but the manual needs some work…it’ll be ready next week.” Instead, the focus should be on “better product, better code”. It should be easy to install (this is the first point at which the user experiences your software, make it an easy and memorable one!), it should have features and functions the users wants and needs, it should ship with the most business value , it should have high quality (i.e. repeatedly works) and it should be upgradeable (i.e. we can add features after the fact, at low cost and with ease).

Bugs reproduce – throw away your bug-tracking database
Bugs that live in a bug-tracking database simply attract more bugs – if you have a database/place to put bugs, every developer will start populating the database with bugs they have found; even the customer will get involved. Bug-tracking databases are simply repositories where folks will “submit’n’forget”, i.e. once a bug’s in the database, it is unlikely to see much resolution activity…

Typically our bug databases see bugs being prioritised in some way. Unfortunately, most developers (myself included at times) procrastinate – as such, we find ourselves taking the easy lower priority items out of the bug-tracking database and we fix those. Lower priority items tend to be lower in business value…even if you take a handful of them together, their value isn’t a much as a single high priority item. Hence Dr.Neil suggests that we dispense with a bug-tracking database and simply fix bugs as they are found, i.e. we have no known bugs in our software.

Mentioned of “broken window syndrome” was made – one broken window attracts another: the only solution is to not have broken windows, i.e. keep things in good condition. Replace “broken window” with bug, and “keep things in good condition” with “fix bugs as they are found” and you’ll see where this is going!

Why do software projects fail?
65-85% of software projects fail. Granted, fail is perhaps extreme, but take it to mean any number of things including: fail, crash, bug-ridden, under-used, fully-featured where 80% of the features aren’t used, and so on… In contrast to the aircraft industry, where failures do exist but are trapped and handled much better, the software industry seems to accept that it produces stuff that fails. Why is this?

A quick audience poll and subsequent discussion resulted in the following answers:

  • politics
  • pitch/price low just to get the job (the value comes via requests for change…expensive changes too)
  • someone else’s budget (not my problem)
  • choice of language
  • choice of technology
  • the decision to use complex patterns (that we don’t actually need)
  • the decision to use specific practices (that are outdated or are not suitable for this project)
  • we make our software more complex that it needs to be (to make “us” look smart and/or to justify high salaries). We do make our software more complex than it need be, citing excuses like “it’ll save us time later if we do…”. Project complexity is seen as a get out clause, a get out of jail card: “it was a tough project, no wonder it failed”. I have refrained from using such language on this blog so far, but get out of jail cards are another form of arse covering – such things should not be tolerated on a project. Although, quite where the high salaries are…I might need to do some more research…

Kent Beck: “Comments in code means you’re not finished.”

Principles
Dr.Neil went on to explain some principles that help create great software (and bring projects in on time!):

  • rapid feedback.
  • assume simplicity. Aim for a “task time” of about 30 minutes (avg), this may mean some items that are 5 minutes, others that are 30 minutes. Note that estimate accuracy increases as task time reduces. Try and achieve a project with >90% of it being small tasks and <10% large tasks that require more effort. The small tasks will provide the sense of achievement and the endorphins that developers long for.
  • incremental changes. Big changes don’t work, there is too much disruption and they are typically too hard to understand (even by those so-called high-salaried folkes!)
  • quality. There are only two choices: excellent and outstanding.
  • teach learning. Learnt something new? Spend 20 minutes teaching it to your co-workers via a “nugget”, a webcast or a blogcast.
  • small initial investment. Put a little bit in, get a lot out. Don’t work long hours, don’t work harder rather than smarter.
  • play to win. Build yourself a track record of winning, ship software frequently.
  • experiment. Use XP’s spikes for what they are good at: if you can’t estimate a task, perform a spike. Limit your spikes to 4 hours.
  • honesty & openness.
  • go with instincts. We should learn from this – developers who have been on many projects in the past bring with them a lot of good experience – typically they’ll be the first to say “that’ll never work” or “we need 12 weeks, not 6 weeks”. Listen to them. They know their stuff, don’t insult them by offering them 6 weeks, you’ll just lose any respect that you had from them if you do.
  • shared responsibilities.
  • adaptability.
  • leave baggage behind.
  • realistic measurements.

The Team(s) must be aligned, it’s the only way to move the project through to completion. Dr. Neil Roodyn, Edinburgh, July 21st 2005

Another quote that just makes perfect sense:

a piece of functionality is not complete unless it is being used by a customer

Four key stages
We noted that there were four stages involved in delivering a great piece of software:

  1. Coding. Without code, there is no program
  2. Testing. Without test results, you know nothing “trust nothing until it is proven”
  3. Listening. Developers are dumb, most of the time they don’t understand “the business” and they write code that other developers don’t understand.
  4. Designing. Organise and plan for enough flexibility, keep it simple, logical modules, organise code, prepare to re-design

Dr.Neil noted that his studies show that most bugs are “created” by programmers after 6pm. Tired programmers create bugs. Don’t be too surprised, if you are lucky enough to be working with Dr.Neil, to find that he’ll kick you out at 6pm…go home, have a life.

Test-Driven Development (TDD)
On the subject of Test-Driven Development (TDD), Dr.Neil reminded us:

  • that TDD is a design exercise
  • that it makes us write the least code and the most simple code
  • that it makes us consider interfaces and design
  • it puts quality first, not functionality (this is most important)
  • writing tests for third party components is a good thing
  • a green “screen” or bar means you can potentially ship your product, you have something shippable

tdd - the red screen
Dr.Neil ponders over the red screen, indicating test failure (luckily, he forced the test failure for demo purposes!)

…And Finally…
This was a throughly excellent session, if you weren’t there you missed something special. If you get the chance to be present at one of Dr.Neil’s presentations, pull out all the stops to be there.

Links
Dr.Neil’s tools, links and presentation relating to this posting can be found here.

Colin provides a similar write-up here. And there’s more over here.

General

VirtualPC inside a VirtualPC?

2 Comments

Kimberly Tripp mentioned this little funny in her SQL Server 2005 pre-conference session at TechEd this year (blogged about here).

Kimberly mentioned a funny error message that would appear if you try to run a mobile application via Visual Studio that’s installed in a Virtual PC image. Given that the mobile device emulators are themselves essentially virtual PCs, this shouldn’t be too surprising…but the error message is, well, humourous to say the least.

Chris Hart saved me the effort of installation, etc. and provided this image:

unlucky for some

General

DHTML Lemmings

Jonathan’s post about Asynchronous JavaScript with XmlHttpRequest (AJAX) caught my eye. As noted in Jonathan’s post, using the XmlHttpRequest object isn’t new…it has been available in Internet Explorer for a long time, certainly since late 1999/2000. Indeed, it is only now that other browsers are appearing on the scene and more of us find ourselves with always-on Internet connections that AJAX comes of age. Like Jonathan, I’m looking forward to getting my hands dirty with it, very soon. There’s more about AJAX-based applications over here.

I also found a link to DHTML Lemmings in Jonathan’s post…uh oh, I can see hours of my time going out the door…I overplayed Lemmings when I had it for my Archimedes during the late 80s and early 90s. Ok, ok, Jonathan’s post title did mention it too, but I didn’t think the game would be this realistic.

Move over Patience and Solitaire, your days are numbered.

unlucky for some

Developer Events

DeveloperDeveloperDeveloper – the return

6 Comments

Saturday 22nd October 2005 – Save the date!

The second DeveloperDeveloperDeveloper day is coming!

Like the first event, it will be held at Thames Valley Park (TVP), Reading, UK.

Call for speakers: If you are interested in delivering a 60-75 minute session or even a 30 minute session, please let me know: craig@scottishdevelopers.com

We’re open to your choice of topics, but given the close proximity to the Visual Studio 2005, SQL Server 2005 and Biztalk Server 2006 launch on the 7th of November, we’re happy to take topics for those products too. This is a Community Community Community event, so product plugs/marketing sessions might not go down too well.

We going to cater for all levels: if you are a “wanna-be” speaker, this is your chance to shine, we can guarantee an informal, relaxed environment, and will give you all the support you need to promote yourself to the next level. If you’ve never spoken at a developer event in the past, this is your chance! 30 minutes is very easy to fill! We’d love to hear from you!

There is a good chance that the sessions will be put to the community for selection/voting, i.e. the sessions will be Chosen By Developers, chosen by you.

Watch this blog, amongst others, for further announcements!

Can’t wait!

Developer Events

TechEd 2005 – Being more productive in .NET

Juval Lowy – some session!

We kicked off with a look at the under-used WinCV.exe class viewer (something that Delphi has enjoyed for some time now…). Juval compared a search for ‘object’ using the WinCV class viewer and a search on the MSDN. He referred to the class viewer as “intellisense on steroids”.

WinCV
WinCV at work – it has incremental search too

WinCV is available today, you can find it here:
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin

However, if you are looking at Visual Studio 2005 betas, you’ll find it’s built in to the product. Take a look at the View –> Code Definition Window menu option:

Code Definition Window

Tied in with this, Visual Studio 2005 has a right-click menu option “Go To Definition”. This works very much like Delphi’s ability to turn methods and properties into URLs when the control key is pressed…in which case it has been a Delphi feature for a long time now!

Conditionals via the System.Diagnostics namespace

// I must change my WordPress theme such that it respects code a little better :-(
#define MySpecialCondition //usually DEBUG

public class MyClass
{
public MyClass()
{}
[Conditional("MySpecialCondition")]
public void MyMethod()
{}
}

//Client side code
MyClass obj = new MyClass();

//This line is conditional
obj.MyMethod();

Link File
Interestingly, and this is something that I’ve preached about during my TDD presentations, Juval went on to remind us about the little drop-down menu that is attached to the Open menu:

unlucky for some
Open –> Link File is useful

If you’re anything like me, you’ll hate having to copy classes/files between projects. Indeed if you download any of the TDD examples, you’ll see I make copious use of the Link File option to share a class between more than one project. In Juval’s words: [Link File] “References the file for compilation purpose, but does not copy it”.

Starting more than one project
One thing that did catch my eye was Juval demonstrating “multiple start up projects”. It’s tiresome when building client/server applications that we find ourselves starting the server, then running the client. The screenshot below can be reached via right-clicking on the Solution item inside the Solution Explorer, then choose Properties (Visual Studio 2003/2005):

multiple startup projects
Multiple startup projects…very handy

Beware of the false Finds!
Personally, I love Visual Studio’s folding editor: the ability to mark sections or regions of code and hide them away is long overdue! However, when a piece of code is folded away, pressing Control-F to perform a Find operation can lead to surprising results. Code that is folded can be included or excluded from the Find dialog’s operation, i.e. Find operations that you expect to be successful, aren’t. By default in Visual Studio 2003, the Find dialog ‘Search hidden text’ check box is unchecked…therefore you may not find what you are looking for, even though you know it’s there! In Visual Studio 2005, the checkbox is checked.

Name those threads!
Presented as being useful during debugging, naming threads is remarkably simple (apologies for the VB code):


Imports System.Threading

Dim currentThread As Thread = Thread.CurrentThread

Dim threadName As String = "Main UI Thread"
currentThread.Name = threadName

Peculiar Selections
Oh, and rectangular text/code selections? You need to hold the ALT key down whilst dragging (works in both Visual Studio 2003 and 2005). This is a feature you either love or hate, but as Juval says: “Very useful in removing namespaces and repeated definitions “.

This and That
Visual Basic has been blessed with the My class that provides access to a multitude of things, such as Audio, Keyboard, Mouse, Network, etc. Perhaps because C# developers are deemed smarter than Visual Basic programmers (I’m already ducking!), C# doesn’t have the My class. Until now at least. Juval has spent some time working on an implementation and he was keen to demonstrate it to us. So, given that Visual Basic has “Me” and “My”, C# now has “This and That“, I jest you not:

This and That

Download this and that.

And finally…
This was a really good session that presented a lot of the differences between Visual Studio 2003 and 2005 and did so by means of lots of demonstrations. Juval was a little quick at flicking between the PowerPoint slides and the Visual Studio IDEs for my liking, something I found he did in another session too – don’t let that put you off, he’s a good speaker and won’t let you down technically. You’ll find Juval blogging about Lornhorn.

Juval left us with a pointer to his coding standard, available via www.idesign.net.

He also mentioned that his book is undergoing a revision and should be with us this month, Programming .NET components, 2nd Edition, Juval Lowy, O’Reilly 2005:

PM#, Project Management

PM#3 – Use e-mail properly

4 Comments

E-mail can be a hinderance for three reasons:

  1. Unless you are very strict, most folks find themselves checking e-mail more than three times per day. This is especially true if your e-mail application has a notification facility whereby you see and/or hear new e-mail arriving. It’s very difficult to resist the urge to go and read new e-mail. Worse, in open plan environments, it’s possible to hear other peoples’ new e-mail arriving.
  2. E-mail, as an application, has history, it has etiquette, it has a modus operandi. Very few people, in my humble opinion know how to make good use of e-mail. This is especially true for “newcomers”, i.e. those folks who have joined the e-mail bandwagon late and don’t realise that there are written and unwritten rules that should be understood (notice I don’t say ahered to, rules can be broken if the timing is right, but that’s another posting!)
  3. E-mail has no real means of helping us manage our to-do list, it doesn’t help us manage those e-mails that require us to respond to, nor does it help us manage those e-mail for which we are awaiting a response. As project managers, we find ourselves dealing with collections of issues, requests for information, decisions, etc. How do we solicit such data? We use e-mail. How do we track who has responded and who hasn’t? Suddenly it becomes very difficult.

One of the e-mail rules that I like to adhere to however, is one that is all too often broken by others. If you find yourself in the CC section of an e-mail, i.e. not in the TO section, this typically means that the e-mail, for you, becomes a FYI…for your information. Your response, unless solicited directly in the e-mail, is not required. Should you choose to offer a response, you should apologise for interjecting from a CC.

Managing by e-mail is also rather difficult. I know some folks work on a “zero in-box” policy whereby e-mails are converted to tasks (we’re talking about Outlook here) and thus you have a prioritised list of things to do. This works, however I think the problem of information management, and e-mail falls into this category, is a much more difficult arena, and one that is not served by a killer application. Of course, managing all this properly brings with it the need to classify, attribute, associate, infer, etc. links between items, prioritise items, and so on. Whilst work is being performed in this area, all we can do today is learn to use e-mail properly.

Don’t let e-mail rule your life – you don’t need to check your e-mail more than three times per day (if somebody tells you that they have just sent you an e-mail that requires your attention, you may of course check your e-mail in between times!)

Do try to keep your immediate in-box cleared down to a reasonable size, I prefer to have less than 20 items “in my face” when my e-mail client(s) start up. Use folders and colour-coding (if available) to help you sort’n’prioritise – not to the point that it overcomes point 3 above. Generally speaking, I’ve noticed that I have very few e-mails whose lifespan is more than 7-10 days – as such, I have a folder “older than 10 days” which can be used as a manual dumping ground, or automated via a rule. Your threshold may vary, but try it, you may be surprised.

You don’t need to keep all trivial e-mails, move them to a “trivial” folder, or better still, delete them.

I will often include myself in the CC list of an e-mail. This allows me to clear out my sent items folder fairly frequently. If your e-mail client offers you “sent item”-specific features, such as delivery/open tracking, this might not be an option for you (but only if such tracking is required).

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Developer Events

TechEd 2005 – IT Blogging

1 Comment

Microsoft’s Betsy Aoki and Eileen Brown gave an excellent Chalk’n’Talk session that was well attended and enjoyed a moderate amount of interaction. This session was preceeded by Betsy’s session about MS IT Microsoft’s Blogging Engine – Construction and Delivery, blogged about here.

Being a Chalk’n’Talk, slide content was limited and was required merely to spark discussion.

Here are some of the things we discussed, with my notes underneath:

What’s a Blog/Why Blog?

Inside/Outside Reach

Customers talk back
Blogs are a great way for your customer to talk to you – but make sure that you don’t become their personal support specialist!

Remember no “Flogs”
This made me chuckle: the guys over at http://www.falafelsoft.com/ use flogs instead of blogs!

Present yourself as resource and aggregator

How do blogs differ from forums/newsgroups/chats?
I’m not sure if we discussed this to completion, I’ll need to check the audio. However, for me, I blog because:

  1. RSS/Atom feed creation is free.
  2. RSS/Atom provides an easy subscription mechanism for my readers
  3. I can access my blog from anywhere, as TechEd’s wireless connectivity demonstrated
  4. no FTP is required, which means I could blog from behind a firewall
  5. it [the blog] pushes content out
  6. content keywords add Google fodder that promotes ranking and facilitates easier searching
  7. content can be short and focussed
  8. there’s much less noise than nntp

Does blog platform matter: yes and no

Consider small audiences and Steve Ballmer: who do YOU want to reach?
“Leverage the power of the small audience”, Betsy Aoki – good quote: you may only have 20 folks reading your blog, but if they are your 20 best customers…

What to Post

Consider “ego searches,” post longevity

X-casting and alternative delivery mechanisms

Link generosity and becoming a human Aggregator

Corporate credibility
This topic reminded me of this and this.

Fighting comment spam

Gaining readers: promotion/tagging/search discoverability
Eileen noted that a simple spelling mistake in one of her posts resulted in a huge number of hits.

Spiders and Bugs

An audio recording of this session can be found here: http://podcasts.msmobiles.com/?p=73 .

Further information:
IT learns to tune out blogging’s white noise
Blogcasts: Coming soon to a computer near you
Microsoft uses blogs to reach out to IT community

How To Blog And Not Lose Your Job

Developer Events, General

eXtreme .NET and Web Services – TechEd speakers hit Scotland!

1 Comment

July 21st – TechEd speakers come to Scotland!

I caught up with Christian Weyer at TechEd 2005 last week, he’s a great guy…and he’s coming to Scotland next week to deliver his “‘Add Web Reference’ Reconsidered: Implementing Web Services the Other Way” session.

And Dr. Neil Roodyn will be presenting his “eXtreme .NET – An Introduction to Better Software Development” session.

Extreme Programming (XP) and web services on the same agenda – it doesn’t get any more up to date than that!

Interested? There’s more information here: http://www.scottishdevelopers.com/modules/news/article.php?storyid=86

I hear that a free copy of Visual Studio 2005 beta 2 DVD pack will be given away to every attendee! (in addition to a free CodeZone gift!)

There’s also talk of a hillwalk on the 22nd of July…

Developer Events

TechEd 2005 – MS IT Microsoft s Blogging Engine – Construction and Delivery

Microsoft’s Betsy Aoki gave us a great session explaining all about “blogging at Microsoft”. Initially, during 2003/4 there were only 5 bloggers using BlogX, after PDC a further 200 signed up and within a year there were over 1000…mainly using .Text. Currently, Betsy manages of 1600 Microsoft bloggers split between blogs.msdn.com and blogs.technet.com (and a handful of other employee-specific sites).

Those of you who are avid bloggers and follow Microsoft blogging closely, will know that Microsoft have gone through a few blogging engines in their time so far. Initially, some Microsoft bloggers used BlogX. This was followed by .Text and now by Community Server 1.0 (written by Scott Watermasysk and Telligent Systems who are lucky enough to be able to say: “Writing blogging software is our day job now!” I’m only jealous!)

Betsy played a pivitol role in the migration to .Text and the subsequent migration to Community Server 1.0. When migrating from one engine to another, it’s worth considering how refferals might work: consider setting up 304 redirects for the RSS feeds. Raymond Chen‘s blog took over 30 minutes to port from .Text to Community Server…mainly due to the vast number of referrers!

Betsy noted some of the problems peculiar to a blog site. Particularly:

  1. Skins are absurdly important. You would think content was the important thing, no, it’s the look’n’feel. How long did you spend looking out the theme/skin for your blog?
  2. Microsoft employees want to blog: Wherever, whenever. Initially, Microsoft bloggers were a little reluctant to blog, stating “you want me to blog and do my day job”. Now, and this was evident in this session and Betsy and Eileen’s session (more later), Microsoft bloggers can’t get enough of it. Folks are on the ‘phone complaining when they can’t get to their blog…it’s an addiction (a soft one luckily!)

I was interested to learn that Microsoft don’t have an official blogging policy, but they do offer advice on “how to blog” and particularly, “how to blog smart”. Robert Scoble is noted as “setting the scene” and “driving it forward”. Betsy explained that Microsoft don’t have a blogging policy because they don’t want their employees to feel constrained, nor do they want blog readers to believe that employees are being told what to write…i.e. blog posts become a marketing device. So it seems that good stuff doesn’t always need policy.

I enjoyed this session, it was delivered well and gave me an insight into something most of us take for granted…I mean, blogs.msdn.com just appeared…did it not?

There is a recording of the session here: http://podcasts.msmobiles.com/?p=74
and a related news item at the msmobiles.com portal can be found here: http://msmobiles.com/news.php/4017.html

PM#, Project Management

PM#2 – Focus on the project

3 Comments

In Vienna, April 2004, Ken Schwaber, co-founder of Scrum said to his class:

“Don’t procrastinate, do something, no matter how small…something that moves the project forward”

I’ve kept that quote close to hand ever since. In fact, I even use it in my Scrum presentations (more here – registration required)

The crux behind “Focus on the project” is this:

We all suffer from an uncanny ability to be sidetracked or to be distracted. This is not good for the project.

Distractions, as Clarke might say, are evil. I certainly agree, distractions are the work of the Devil.

I find myself distracted by a number of things (apologies if these sound like rants…they are sort of!):

  1. Passers by. I’ve been travelling a lot over the last 18 months, so when I get back to my desk I’m invariably greeting with the response “oh, you’re back…”. And being an IT guy, the next question, after the usual exhchange of pleasantries is “…I have an Excel problem…have you got a minute?” (Of course, sometimes it’s Word!) As noted earlier, “a minute” usual means five. Getting back to what I was doing after a five minute gap can be a chore.
  2. The telephone. The telephone’s great for getting quick decisions and I favour it over a series of e-mails (this is the subject of a future posting). However, just because I have chosen to answer the telephone, typically out of politeness, it doesn’t mean that I’m at your disposal. Please ask me: “is now a good time to talk?” or “do you have time to talk?” Better still, if you’re call isn’t that important, send me a single e-mail asking me to call you when I’m ready. Telephone interruptions tend to be continous, once a caller realises that you are already on the the ‘phone, they’ll tend to keep trying until they get through. Apart from the obvious waste of time and resource, it means you suddenly end up with two (or more) ‘phone calls back-to-back. This is really frustrating as it feels like you’re destined not to get on with the task in hand, i.e. focus on the project.
  3. Folks who don’t realise the importance of what’s being done. I’m sat here in my study typing this post, to all extents and purposes in the eyes other folks, it’s something that can be done later…because all I’m doing is staring at the monitor. Creativity doesn’t work 9-5, it doesn’t always manifest itself in swish graphics on the screen or reams of fancy looking text. Similarly, it’s the weekend…my deadlines have been published for long enough now, but still I’m just perceived as sitting in the study twiddling my thumbs…my to-do list isn’t at all important!
  4. Doing something for doing something’s sake. It’s nice to get ticks in boxes, little jobs complete, but ask yourself: “how important was that tick in the box activity?” It might have been important to somebody else who needed the tick in the box, but did it really help the project? There comes a time in a project when a particular avenue is closed off and another route has to be examined. Some folks will expect the original avenue’s work to be completed such that proper closure can be achieved. Invariably, you’ll find yourself creating documentation or doing work that will not be used and merely gets the requestor a tick in the box – this kind of distraction does not help the project and serves to slow to you down.
  5. Poor use of e-mail. A future posting will cover appropriate use of e-mail…as a distraction, “e-mail ping pong” is a real pain. E-mail is a great tool, but some folks treat it as “work postponement device”. This scenario typically occurs when you pass work on to somebody, you may spend some time crafting a very succinct e-mail making sure that you pass the request/work over neatly. Imagine your surprise when the reply comes back very quickly with a question that essentially passes the work content back to you? I’ve seen this trick referred to in other postings as “sloping shoulders” – the uncanny knack of not accepting a work package! I’ve also seen this scenario referred to as “answering questions with questions.” The distraction element occurs as you have to read the question and then re-plan the distribution of that particular work package.
  6. Too much work. Yes, I agree, this is a strange one. I find myself, and see others, being distracted because they’ve got too much work to do. In this distraction scenario we find ourselves flitting between tasks/activities, not really focusing on any task for too long. We essentially fall into the “multi-tasking is evil” camp, but that’s another blog post (#7, in draft format, coming soon).
  7. Too much travel.

    8. Travel takes its toll; downtime in airport departure lounges can be harnessed, however invariably, I find myself fidgetting and wanting to get on with some work, i.e. move the project forward. However, I usually end up reading a technical book, or a novel (this is sometimes better as it frees the mind, allowing the subconcious to “do what it has to do”) I’m a great believer in conference calls and LiveMeetings for bringing folks together “face to face”.

In summary…
Do what you have to in order to reduce the number of distractions that are plaguing you. Make large chunks of uninteruppted time available to you and your project – it’s the only way you can make significant and productive progress.

Even if you publish your deadlines and to-do list, sometimes you will find that you need to reinforce the importance of it to others.

Alway ask youself, “is what I’m currently doing helping the project?” If it’s not, then it’s periphery and you should re-prioritise your work basket.

It’s not just about “you” focusing on the project, it’s also about getting the project team to buy-in to a similar focus otherwise you’ll find yourself threading water (if you’re lucky). I know it’s difficult, but if you have folks on your project who have interests other than the project in hand, it’s important to have them drop that interest such that they can focus on the current project.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making