Five Afghan children have been injured, some seriously, by cannon fire from a British Apache helicopter, according to UK defence officials.I can assure Mr. Norton-Taylor (the author of the piece) that, had any of the children been hit by a stray 30mm high-explosive cannon shell (aka 'bullet') from the Apache's cannon, they'd have been a good few steps beyond "seriously injured".
It is believed they were hit by stray bullets during an intended attack on an insurgent as they worked in a field in the Nahr-e-Saraj district of Helmand province, on Saturday.
As The Press reported last week, Frank was among 500,000 people who travelled to London to protest peacefully on March 26.Um. Where to start? It's great to be proud that your brother was standing up peacefully for what he believed in, but that doesn't really cover hurling poles at police does it? That's why it's called violent disorder.
But he was captured on CCTV throwing two poles at officers in London’s Piccadilly in the middle of mob violence and then immediately walking away. Victoria, who lives in Wakefield, said she did not condone the violence, but she was proud he was prepared to stand up peacefully for what he believed in.
She said: “As family, you always think they don’t deserve it when someone is punished, but all the Facebook supporters agree with us.”
Compare Gilmour’s fate to that of Wendy Lewis. When Miss Lewis, who like Charlie Gilmour had a drugs problem, vandalised the Cenotaph by urinating on it, she got a suspended sentence and was ordered to enrol in a drugs rehab programme. Miss Lewis is 32 and a mother of two: like Gilmour, she should have known better. So why did she get a more lenient sentence than the Cambridge student?Well, there was the minor point that Ms. Lewis, unlike Mr. Gilmour, didn't try to set light to a building, trample through a smashed shop, or participated in the attack on the car of the heir to the throne and the Duchess of Cornwall. Indeed, Mr. Gilmour was not (as far as I understand) prosecuted or sentenced for the Cenotaph incident at all. But as a privileged young man who was on his way to university he had fewer excuses for his behaviour, and maybe that helped the judge push his sentence towards the right hand side of the available tariff. Perhaps Cristina Odone feels that Mr. Gilmour being high on illegal drugs was a mitigation? Odd then that she doesn't raise the point.
"The man sent in to film was looking rather uncomfortable, but we were assured the cheetahs would only go for the fluffy microphone and if it looked like he was going to get eaten, not to worry."The least dumb of all the participants would appear to be the cheetahs. Perhaps we should appoint them to run the zoo instead.
- "Fall from a tree? He's probably absolutely trolleyed." I'm not taking that bet. We also saw from a maimed carpenter that electrical tape is just as good as, if not better than, Elastoplast.
- A good friend is one like Patrick who will hold a bowl under your jaw while you vomit into it, while he is completely sober. Such friends are rare, treasure them. He even bigs up your past heroic deeds to the nurse who's about to stitch up your nose.
- Oh, another stab victim (left side upper abdo). Didn't see much of him beyond ten seconds just before the ad break, and there was no narration about his injury but it was a small but obviously deep isolated wound to the front of the abdomen. I got the message.
- The poor sod who got stuck between a cherrypicker and a car was, nevertheless, painfully lucky. He just wanted to go home but, as the consultant pointed out, his pain relief choices were between paracetamol at home or morphine in hospital. After that kind of squash, I'd take all the opiates that were on offer.
- Unknown male with a head injury; fall from a ladder onto concrete (height unknown), intubated with severe traumatic brain injury. He had a mobile phone but it's locked - who can unlock it? Turned out to be a chap called Nicholas who, it appears, was very near to biting the big one. He's still a long way from fully recovered but a light year from the state he was in after the accident. Good job by the neuro guys and all the rehab team.
- When the A+E nurse is acquainted with your model of vegetable cutter (a mandoline) it's a sign that you should change to a different one.
- Ironic that Darren who fell through a window while cleaning it, saw his arteries spurting blood over the walls and ceiling, and wrapped his arm up in a towel to control the bleeding, didn't feel he could watch the nurse sticking him with a local anaesthetic. There's no accounting for taste. Incidentally, that's why you shouldn't clean your windows.
#!/usr/bin/python from errorprone_code import main_program from time import sleep complete = False while not complete: try: main_program() complete = True except Exception, err: print "Strewth! %s" % err sleep(1)which should be crash-free, but we clearly have not made the main_program() run any more free from errors.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.Unverifiable code in a safety-critical system is clearly bad. That doesn't mean that it's actually wrong, nor that it caused the crash. You certainly wouldn't want to let an aircraft with unverifiable engine code into service, but Boscombe Down was overruled by MoD (no doubt a conversation along the lines of "we've already bought the damn things, we'd look pretty stupid if we didn't let them fly"). There did appear to be real problems with the FADEC, including uncommanded engine run-ups experienced on the Chinook HC2, which doesn't surprise me in the least. But as long as the Chinooks flew in regular flight regimes, with standard power settings, they'd be running through the best-tested parts of the FADEC code which would therefore be the least prone to error. There's nothing in the crash which indicates any abnormal engine operation, commanded or uncommanded.
- Pick well-established development languages and supporting tools (e.g. database, httpd), ideally those that you or your team have already used for a successful project;
- Choose the most recent version of a language or tool which has been in productive use for at least 6 months, not just the most recently released;
- Plan for changing major versions of each language or tool at least once in the project lifecycle, e.g. Python 2.4 to Python 2.7, Postgres 8.4 to 9.x; have a very small number of places where this version change needs to be made;
- Provide sufficient shared hardware to make life-like testing easy without developers or testers having to fight for resources;
- Ensure that your company standard OS image already has the libraries and tools that you need for development and testing, and if they don't then establish immediately how you are going to get them added (and updated);
- Know your hardware and software ordering process and lead times; you're going to need more than you initially expected, but won't yet know what (or have the figures to justify it)
- Cost out one day of tester or developer non-productivity and one week of delivery slip and use this to justify your additional hardware / software requests
One nurse noted "I had 'ping pong ball in anus' the other day in Trauma". That's got to chafe. "They had four and then noticed there were only three left". Thank goodness she left the detail to the imagination. Wonder what happened with the bats.
Oh, look, intoxicated students, injured after falling from a bar they were dancing on. Alcohol, stupidity and gravity; kerching - the pisshead triad. They were trying to look after each other, which was sweet, but doing so while four sheets to the wind made it a little futile. Amusing to see their friend assert to the nurse that their head injury wasn't serious. Glad that you've got CT-level vision there, sunshine.
Grudging respect to builder Colin who had his forearm opened up by a knife in an attempted cellphone mugging. He seemed quite happy scrutinising the injury which opened up around 10mm of flesh, and was concerned but not panicked about loss of sensation in his finger which likely indicated nerve damage. Had been drinking but that didn't seem relevant to the injury so I'll let that one pass. He seemed relatively relaxed about the docs prodding the injury, that's a man with a substantial pain threshold. This was confirmed by him removing his own stitches to get back to work sooner.
I have to confess to a growing respect to senior sister Jen, who has seen everything and is near-terminally laid back about an increasingly demented night shift. She knows biological facts that no-one should need to know, and confirmed the 50%+ alcohol-induced injury proportion for the key shifts. She handled combative patients and stressed relatives with aplomb combined with don't-screw-with-me-sunshine firmness.
Father and son brought in with "samurai sword" and blunt trauma injuries, though the son's holes didn't look that large to me (they were in dangerous places though) following gatecrashing of a family party.
A couple of predators decided they wanted to come in and "no" wasn't an acceptable answer. Wonder what their crime history looked like.
Catherine was a classic PFO who "started to feel unwell" after an evening out with friends. Drank enough to start inducing apnea, which caused no little concern. I'd suggest hot sweet coffee, p.r.. She claimed that "her drink was spiked". Mmmm...
Moral of the evening: if you need to go to A+E with an injury that will be treated in Minors, don't go on Saturday night; you'll be there until Sunday daybreak. And it's probably your own fault.
Joel Spolsky reckons that his key criteria for hiring is "smart and gets things done". With all due respect to him (after all, his firm has bashed out some commercially successful software over the years) I don't think that's enough. I would modify that to "smart and gets the right things done". I've known any number of smart and productive people over the years who spend at least half their time doing work that never ends up being used - either it's irrelevant to the main thrust of development, or it does the right thing but in a way that's never going to scale. Someone who's always asking themselves "what does my current work actually do for the project?" will be at least partly aligned with your goals.
Get people who are familiar with the technologies you plan on using in your project. The ideal is to find people with experience developing either at the size of code base / complexity you are aiming at, or at worst one level below that (so for an estimated 100KLoC Python codebase you should find people who have written systems with at least 10KLoC and preferably at least 50KLoC of Python). Never use your project as the basis for testing a new technology - or, if you must, confine it in one place in your design and have a fall-back plan if the new technology doesn't cut the mustard.
Good developers need an ego - they have to take pride in producing the best possible system - but they also need to be able to take criticism and deal with it appropriately. If your developer is a prima donna, you're going to end up with the system that they want to build, and damn the customer.
Always consider the one-under-a-bus rule. Your team should be able to tolerate any single team member being run over by a bus, minimising the inevitable resulting delay to the project. This means that no team member may be irreplaceable, and you should ensure that each system component (which as noted above is probably developed by a single team member) has at least two team members who are capable of developing and testing it. If you're requiring that any code change be reviewed by another team member, this should fall out automatically. If you see a team member actively hoarding information and expertise, you should seriously consider dropping that person from the team. I assure you that ignoring the issue and hoping for the best will not improve matters.
You need to get your team size right, and my personal feeling is that the team should be as small as possible but no smaller. The problems caused by oversized teams, or teams that have people firehosed on them late in development, are well documented. Fred Brooks Jr's "The Mythical Man Month" is timeless, and peerless on this subject. Start by picking out your developers; you need at least two (one needs to check the other's work) but no two developers should be focused on a single part of the system. Slice up the design between developers.
Once you know the size of your development team, consider what you want to do about testing / QA. My finger-in-the-air rule is that the testing / QA headcount shouldn't be more than half the developer headcount, and quite possibly less. Perhaps you need more of them in the first couple of months when you're building out the unit/system testing and developer environments, and fewer in the middle phase before customers get their hands on the system.
If you have anyone technical on your team who is happy doing repetitive tasks, you need to re-educate them. With a small development team you don't have the spare resource for someone to spend their day pushing buttons. They should be automating wherever they can - everyone should be happy in a scripting language like bash, Perl, Python or (heaven forfend) .NET.
Don't forget the support that won't be part of your official team but is nevertheless vital - sysadmins who maintain your hosts, admin staff who handle your procurement and organisation. Don't try to do their job yourselves. A talented developer who is spending half his day deploying new OS images is not making good use of your limited time.
If you want to build a software system that will make you (or your company) money, it's quite important to ensure that you build what your customer really wants. This is, please note, often very different to what your customer actually wants, what your boss wants you to build, what the chosen technologies allow you to build, or what you know how to build.
A classic example was the NHS über-screwup Connecting for Health, which was only successful from the viewpoint of the consulting and implementing companies that managed to squeeze a cool £10bn+ from Government before the public outcry became too loud and the relevant management saw the writing on the wall. The medical staff didn't want most of the functionality that was being built in, patients weren't interested in the much-vaunted "Choose and Book" functionality, and the Summary Care Records provoked privacy outcries. If you want to try building a massive centralised project like this, good luck, but please note that as a taxpayer I'm going to be lobbying for public whipping to be an integral part of the failure-to-deliver penalties.
So what do you need to asking before you start planning your system?
- Who are the end-user customers?
- Some poor schmucks are going to be the main users of your system once delivered, and a subset of them will be trialling out the early delivery. Know who these people are. Have an idea of their daily tasks, workflow, education, expertise, blind spots. Identify not just your "normal" users but also the pathological "experts" (who will try to make your system do things it was never designed to do, and expect it to keep up) and "abusers" (who will sadistically mis-enter data, jump forwards and backwards in the workflow changing and re-changing items and howl that the world is ending if so much as an unexpected warning box pops up).
- Who's holding the purse strings?
- Someone's going to be paying for this system to be developed; specifically, someone in the finance department is going to be cutting cheques (or the electronic equivalent) to you at various stages of delivery. Find out who this is, and what they need and want to see before they sign those cheques. This is going to lead you to ask:
- Who does the purseholder listen to?
- The purseholder is unlikely to have computer expertise beyond a grasp of Excel. They're going to have a "technical expert", who may or may not justify that title, who will tell the purseholder whether the system has met the requirements for the next cheque. You need to know exactly what that expert is really looking for, which will likely be a strict superset of:
- What does your contract say that you must build?
- If you're lucky, you'll get into this process before the contract is written, and you can get involved in the details of gateways, acceptance criteria, contract variation etc. You're seldom lucky, so are more likely to have the contract waved in your face as a fait accompli. Ensure that you know it backwards.
Given this knowledge about what you should be building, your next step should be to ensure that you're actually going to build this. Some of the pitfalls to avoid and tricks to employ:
- Avoid early technology decisions
- The temptation to nail down technologies at requirements time is nearly irresistable: "oh, I know the kind of thing that's needed, let's do Linux + Perl + Apache". It is extremely important to resist. Apart from anything else, you don't have enough information yet to know if your technology is good enough, can scale sufficiently or will be supported for the required timescale. To make a start on gaining this knowledge you need to:
- Build a working prototype
- Throw together something that demonstrates 50%+ of your system functionality, and (importantly) goes end-to-end. It doesn't have to scale, it doesn't have to be bug-free, it doesn't have to run on the target hardware. What it does have to do is allow end-users to play; to enter data, give you feedback on what works and what doesn't, tell you where they need it to be faster. Do not plan on any code in this prototype making its way into the production system, but do keep it working so that you can test e.g. proposed user interface changes.
- Dogfood during development, if you can
- Eating your own dogfood during systems development is an excellent idea to improve quality and usability. The idea is when the product in question is related to your daily work, e.g. a bug tracker or revision control system; however, even if it's a completely separate business function you can get some way towards this. As soon as it's in alpha release, get an end user or two sitting next you and using the new release. They have carte blanche to whack your team with a rolled-up newspaper and tell them what's irritating them or making them unproductive. It's amazing what can get fixed when the results of bugs are immediately apparent.
- Early worst-case scaling
- Once you have a good idea of the expected data size, performance requirements and target hardware, make a performance challenge system. Have some way of loading up 10x the required data and measuring the impact. Run your user test system on underpowered hardware. (Note: don't run your automated tests like this - these need to be fast to flush out errors ASAP).
I'm starting a blog category talking around the aforementioned Software Systems Delivery Minefield (SSDM) and how to avoid getting your legs blown off.
SSDM is not to be confused with SSADM, a development methodology devised by the UK Government in the 1980's. This aimed to improve the reliability and predictability of IT systems development for Government use, and was the outstanding success that any experienced software developer could have predicted.
The scope of the SSDM blogs are as follows:
- software systems, not just isolated programs;
- covering the full lifecycle, from inception through development and delivery, to operation;
- taking the viewpoint of testers, developers and the project manager;
- limited to a team size from 2-10 people; and
- technology-agnostic, trying not to prescribe a specific technology but rather enable the reader to form a view on what properties of their candidate technologies make them likely to either help or hinder.
I hope to be able to pass on some of the lessons I've learned and show a few of my scars
(in tasteful locations only) and would be interested in others' feedback on their experiences.