Off topic perhaps but entertaining and inspiring…
If you ever wondered why there aren’t enough women working in IT, the problem appears to stem from earlier in life. The data below from ONS shows the greatest discrepancy between men and women is in Engineering & Technology and Computer Science (this from 2010 so could probably do with an update!). And whilst it isn’t mandatory to have an academic background in IT I personally prefer it when I’m scanning CVs.
Let’s remember that Ada Lovelace is generally regarded as the first computer programmer and was – shock! – a WOMAN!!! So, a few links to help get your daughters into IT:
I can’t help but think that I’d not get away with load-balancing of resources assuming an equal prioritisation of requests as the British political system allows with votes. No doubt the Tories got the most seats and should rightly be charged with forming a government. However, based on raw votes the distribution is unequal and the system is weighted in favour of the main two parties… and the emergent SNP! The table below is based on UK elections result data from The Guardian assuming you get the number of seats relative to the number of votes cast.
Suppressing minorities or mitigating extremities? Or a bit of both… It should not though be for the incumbents; and the system is a product of them, to decide. Perhaps our electoral system could do with an updated load-balancing strategy.
|Scottish National Party||56||31||+25|
|Democratic Unionist Party||8||4||+4|
|Social Democratic and Labour Party||3||2||+1|
|Ulster Unionist Party||2||2||0|
|UK Independence Party||1||82||-81|
|Trade Unionist and Socialist Coalition||0||1||-1|
|Traditional Unionist Voice||0||0||0|
… so I’ve just been told the most important thing about a computer is the number of “pouce” it has (thumbs to you and me). Humm… well, ok. Mine generally has two at most and I get angry if it’s got any more. My father in-law has 15.6 of them. Wow! That’s one powerful machine (I guess)!?
I can be a little cynical sometimes though going through the morning news it seems there’s been a couple of rather heartwarming moves by a some of our overlords today…
Microsoft to require suppliers to provide paid leave to workers (though Bill doesn’t look too happy in the photo he’s got my respect for the work of the Gates Foundation).
Apple boss Tim Cook ‘to donate millions’ to charity (and he can pay my sons university fees if he wants to as well!).
I suspect the shareholders of neither MS or Apple will care much though as it doesn’t really affect them and there’s a long way to go yet to address the inequality but… oops, there goes my cynicism again… 🙂
Using the legendary tree swing cartoon analogy of the IT industry for my own utility…
How does this sort of thing pan out in a naive project environment? (they’re not all like this).
- Analyst sits down with client for a chat about what’s needed.
- A mental picture (right or wrong – let’s assume right for now) is formed in his/her head.
- A blueprint of how it will work is drawn up (only mentally since we reckon the problem is simple enough).
- A few questions come up when considering this; how heavy the user? how high the tree branch? etc.
- Solution proposal is verified with client – via a chat over a pint because it’s all pretty obvious and he’s a mate.
- Worked out what items are needed (tree, rope, tyre).
- Worked out how to build it (again, only mentally because it’s pretty straight-forward)…
- Identified where to source the items from – rope from DIY shop, tyre from scrapyard, tree in back-garden (even checked that there was one!).
- Took client to scrapyard – picked a nice 50s white-walled tyre he liked… (nice team building day-trip out).
- Built it! Yeay!
All done with no documentation because it’s a trivial problem and hell, it worked so let’s do it this way everytime… until you write the requirement down…
Requirement: “I want a swing for my 10 yr old child to play on.”
Or as a user story: “As a child I want a swing in the garden so that I can play, see how high I can go, get dizzy and feel really funny!”
Or a set of 20 page use case documents (which is wrong in itself).. yawn!
At which point you’ll go to Amazon and discover a host of inexpensive off-the-shelf options which are probably better-designed/safer/more-flexible etc. and unless you’ve a rope, tyre and tree lying around you’re probably going to opt for the COTS option.
So it’s worth writing it down, just to make sure it’s understood, even if it seems obvious. Agile does not mean “no documentation”, just “avoid the bloated detailed crap no-one reads and focus on the useful stuff”.
Which for me starts with requirements! (functional requirements – a swing! non-functional requirements – for an average weight 10yr old child). It does not take a lot of effort…
But oh wait there’s more!… some form of logical design (blueprints), a plan (sources, how to do it), infrastructure requirements (a tree), physical solution (which tree?).
And my favourite hobby-horse this month… traceability from the solution to the requirements to demonstrate why it’s the way it is and to confirm it meets the clients needs and expectations. It can even be done in the pub with a whisky chaser!
None of this needs to be written down as reams of verbose documentation, none of this is counter to agile principles. A lot (if not all of it) can be done with a few lists, diagrams and matrices… no Word docs or Powerpoint decks in sight (unless that’s the chosen crapware you use to draw diagrams) and you can save the tree if you choose not to print to paper… But all of it needs to be thought about – whether you write it down or not!
I’d still prefer it if you’d use UML though… 😉
I’m often found ranting and raving about the legality or morality; or rather the illegality and immorality, of some solution or other – more often than I care to admit. This post should hopefully clarify what I mean when I say it’s “illegal” or “immoral”. I should point out that I’m using these terms as an analogy in context of some IT solution and of course the legality of a solution in technical terms is an entirely different question. Morality never was very well defined.
For further clarification I should state this post is in regard of IT solutions and not the behavioural rules and norms of society in general. That some of those IT solutions I’ve worked on may conflict with what society would expect is a separate issue…
Legality – TFD defines legality as “A requirement enjoined by law”. The key word here from a solution perspective is “requirement”. If we assume that all requirements are mandatory (of course they’re not) then when I say some solution or part of a solution is “illegal” I am simply (pompously) stating that it does not satisfy some requirement or other. This may be acceptable depending on the clients view of the requirement as some rules can be, err, bent.
Unfortunately, I often find that it’s the non-functionals that get eroded first. E.g.:
- “It’s acceptable that such-and-such a function doesn’t work with IE7 because it looks great on other browsers and isn’t worth the cost to fix it” – breaking a compatibility requirement.
- “It’s acceptable that performance on some pages suck – it’s good enough generally!” – stretching performance requirements.
Or perhaps the worst (and all too common):
- “Just dump all the user data to a flat file and e-mail it to the marketing guys – they need it now!” – violating security policy. If found out you could get fired, if leaked you could bring the whole organisation down – low probability but very high risk. It’s interesting that the business focuses on the “probability” whilst the IT dept. focuses on the “risk”…
Morality – TFD defines morality as “The quality of being in accord with standards of right or good conduct”. Oh dear, all very subjective. Who’s to say what’s right and what’s good? The architect of course! (arguments commence)…
Anyway, when I say some solution is immoral, then I’m just saying it doesn’t fit with standards and best practices in the industry. In terms of architecture this could be due to poor division of responsibilities, tight coupling between components and sub-systems, incongruence with organisational structure, inconsistencies in implementations, complex dependencies and so on. None of this is black and white and sometimes compromise is the best solution – so long as you can sleep at night. But there are reasons why this stuff exists – partly because it works, partly it’s old wives tales – you’ll need to figure out which is which.
We’re often asked to bend requirements. Sometimes it’s the right thing to do, sometimes it’s just the easy thing to do. In any case, like the law, ignorance is no excuse. Make sure you understand the requirements and if you don’t satisfy them then, well, that’s your call.
When it comes to morality it’s best to follow standards and best practice – most of the time – if only so you can avoid confrontation with the high priest of architecture (aka the Chief Architect). What’s right and what’s good is always worth the debate though – and a pint or two helps to lubricate the argument…
Is it me or has there been a radical explosion in the title “Chief” recently? CEO, CFO, CIO, CTO, I can get this (kind of)… But isn’t the point that such a role is, well, the chief? Like the president being commander-in-chief?
So we dilute the office (Executive, Financial, Information, Technology…) and you’re “chief” of your office… But ok, whatever, you need a little viagra to stimulate these guys.
We then have chief architect (period) which; I admit, in some cases was a role I had some respect for. But now I’m seeing chief-architect-of-xxx (where xxx is some random project spawned the morning after a particularly heavy drinking session). You’re not the chief, you’re a muppet for believing the title has any bearing on your status. The only effect that title has is to make the CEOs feet go cold when he realises his veil of authority is slowly eroding away, and for the minions you supposedly lead to think you’re a bit of a dick.
So I’ve decided to bypass this faux “chief” thing and skip it, going straight for… Master-of-the-Universe!
Now I’m just waiting for someone to title themselves “God of Pocket Calculators!”… and the circle is complete, as Dylan said, everybody “Gotta serve somebody” (and yes, I know it’s a Willie Nelson cover!).
“They may call you Doctor or they may call you Chief … But you’re gonna have to serve somebody”…
I’ve said it before and I’ll say it again… non-functional, not functional, requirements are the key to making your solution a success. Get these wrong and you’re going to lose no matter what.
They cannot be an afterthought delayed until some abstract time later. You need to know NOW!