I’ve been introducing the in-laws to “Internet shopping”.
I struggled to explain this one to them:
“£29.99, you say, nice price, fully featured, state-of-the-art, tell me more.”
Clicking on the first link took us here:
And the second link took us here:
Two totally different prices, nothing like “Our price: £29.99” at all.
Granted, these prices are a little more realistic…
Derek Laud, was evicted from Channel 4’s Big Brother reality TV programme on Friday. What he had to say once he left the house was somewhat inspiring, and he said it with considerable eloquence, grace and civility.
First and foremost:
…team effort is absolutely everything..and that’s fundamentally what works
Unfortunately, I’m not sure his housemates really grasped that concept on the whole (irony accepted). Team effort is everything: in a group of 10 or more people, it’s not worth being the only person, or the only two people trying to do all the work. Delegation is part of the game, but so it responsibility – it’s no use just sitting watching one or two people trying to do all the work, chip in a help them (especially if they ask you to!)
“team effort” == community.
Followed closely by:
it’s a lack of selfishness that’s very very important in life
The World doesn’t revolve around you. If you didn’t do your job, it wouldn’t be the end of the World. It’s not about “me me me” [cf].
I found this quote interesting and somewhat close to home:
other people are much better about making their problems seem more important than anybody else’s
Me me me. My problems are more important than yours ,listen to me, let me talk your ears off. Yes, a lack of selfishness is important, but so is taking your turn. Everybody has their problems, we just have to prioritise the solutions by importance and need.
And to finish:
listen more, talk less
Feedback is important, there’s little point soliciting feedback if you don’t listen to it and act upon it. Similarly, there’s little point in a one-sided conversation (which by its very nature is at least a two-way thing). And if team members bring problems to your attention, they’re doing it for a good reason, be sure you listen to them and act upon them.
Politics aside, a combination of Derek and Boris Johnson would revive the Tory party, perhaps? Just a thought.
I don’t know what’s more annoying, the National Lottery site going down just after I click submit whilst buying the office syndicate’s tickets or the fact that they’ve got a happy smiley face highlighting a little anticipation of it coming back up…
…I certainly won’t have a happy smiley face if the tickets weren’t bought: I’ll probably be lynched.
But anyway, rant, rant, etc. Can you believe that they’ve actually put a Trademark on the “site down” message?
Last month saw a few of us climb Ben Lawers, amongst other associated peaks.
Apart from the fun element, this was Scottish Developers way of showing appreciation for the sterling presentation Dr.Neil gave the group the day before.
Here’s the Google Earth image, tilted to show terrain:
Google Earth shows off the terrain rather well
Craig admires the view. CodeZone caps get everywhere!
That loch in the background is Loch a’Chait
Dr.Neil, myself, Dave, and James
Dave, James and Barry – posing for the camera just before Craig decides to “leg it” with Barry’s camera…3000 feet up and in the middle of nowhere!
Dr.Neil, Dave and myself at the top of An Stuc
A triumphant Barry reaches the top of Meall Greigh
Thanks to James and Barry for the photographs!
It seems that security concerns are preventing us making progress. Robert Jaques has an interesting piece in the September 2005 issue of PCW (UK). Yes, I know August has just descended upon us, however PCW does seem to be published some two months ahead of the actual month it represents!
Whilst the rest of the world are making progress with IP telephony/VOIP and wireless networking and wireless hotspots, etc. it would appear that there are some folks who are thwarting progress by following the maxim “if it ain’t broke, don’t fix it”. Well, in this situation, that maxim doesn’t hold true. For example, I’ve just returned from Microsoft TechEd in Amsterdam, where Microsoft was kind enough to provide [potentially] 6,500 of us with wireless access to the Internet. It was a remarkably liberating experience. I was able to check my e-mail whilst attending sessions, blog “live”, provide session feedback within minutes of the session finishing, etc. It was truly amazing.
How did we ever live without wireless? I can’t imagine the Internet without it now, never mind the connectivity gains that I’ve acquired after pushing the wired LAN into the dark and distant past (OK, so I’ve a wireless ‘bridge converting the wireless into wired for use in the study…it still means that I don’t have wires running all over the house, much to my wife’s delight!)
Life without wireless/VOIP might not be secure according to the hype mongers; however, can we believe them? True, wireless networks do open themselves up to a wider range of potential attacker – the attack surface extends itself to the far reaches of the wireless broadcast. And yes, early wireless kit was delivered (out of the box) with all the security options turned off or disabled…but I seem to recall that some operating systems were delivered in a similar fashion. Nowadays of course, virtually all wireless kit (and the aforementioned operating systems too) arrive with all the security bells and whistles enabled so much so it’s sometimes difficult to miss. With a little care, it is possible to secure a wireless network and/or VOIP such that there is considerable business benefit.
Life without wireless/VOIP means a mess of cables. It means a laptop, a rucksack and a bag full of various network cables and adaptors – I carry five RJ45 cables of various lengths and an RJ45-to-RJ45 extender that allows me to daisy-chain two RJ45 cables together if required. I didn’t carry such excess baggage to Microsoft TechEd…the only wires I saw there were those leading to from laptops to power sockets and from the VOIP handsets to the controlling PC.
Life without wireless/VOIP means having to find landlines or worse, mobile ‘phones. It means having to stretch a fixed line ‘phone across tables/desks to get it close to your laptop which is plugged in to the network and the mains – and because neither the network provider or the electrician spoke to each other, they both kept their infrastructure as far apart as possible. If you’re lucky enough to have a network provider and an electrician who speak the same language, the floor sockets that house their respective outlets/sockets, and this is especially true of electrical outlets, are sunk into the floor, hidden underneath a tightly fitting lid that soon comes away in your hand the minute you lift it open. And if that wasn’t bad enough, you try to plug your laptop’s power adaptor in, oh, the huge transformer prevents you from plugging it in…or, worse, you have a regular-sized plug fitted with a less than flexible cable…the power outlet’s live/neutral plugs so close to the edge of the housing that you can’t even bend the cable to fit.
And just think of the triangulation involved in plugging a laptop into the mains at point A, the telephone at point B and the network at point C. The resulting mesh is a potential safety hazard.
Just in case you had forgotten what life without wireless looks like, here’s a very tame reminder:
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).
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
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
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.
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.
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:
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:
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!):
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:
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:
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.
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:
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.
E-mail can be a hinderance for three reasons:
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
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…