Want people to read your emails? And not just read them, but pour over them with a fine tooth-comb, analysing for meaning, reading and re-reading every sentence, weighting every word? In a corporate setting there is only one way I know to achieve this – email recalls!

Recalled emails are a quaint notion, something akin to being able to recall a bullet after it has been fired from a gun. Usually the only people who recall emails are those who don’t understand how email works and have inadvertently sent something really stupid and/or personally damaging to a list of people they may not have intended to send that item to. For this reason a recalled email is like a deliciously prepared home cooked meal to your average boring office-worker who subsides on gruel and stale bread every day. And like the meal of a master-chef the recalled email must be savoured, digested, rolled around on one’s palette until every last ounce of flavour has been extracted, every morsel of embarrassment for the sender has been deliciously experienced, and every taste of treachery or whiff of organizational scandal has been appreciated. Normally recalled emails are only sent by accident…normally, but if you actually want people to read your emails sending them and then recalling them can be a really good technique. Recalled emails are the ‘turning it up to 11’ of email communication.

Just remember - like all attention grabbing techniques this one should be used sparingly, to avoid people becoming de-sensitized to it. Also, clever operators may want to deny they read the email at all, and can justifiably do so by claiming to be good corporate citizens and honouring the email recall (there is a saying that patriotism and following corporate policy are the last refuge of scoundrels). In order to remove this avenue of denial from them re-send the recalled email about 4-6 hours after the ‘recall’, with a minor typographical or spelling correction. Coming up next week - gaming the 'low priority' flag in outlook.

I was intrested to see today that in the new Productivity Power Tools update that the toggle buttons on the configuration dialog for this add-in have taken on a very iPhone-ish appearance.

And here for comparison are some iPhone toggle buttons.

Some investigation in Snoop shows that these are indeed styled CheckBox controls (CheckBoxes derive from ToggleButton in WPF and don't really add any behaviour, so semantically they're toggle buttons). The ContentControl hosts all of these CheckBoxes has a style called ToggleStyle, which is applied to the CheckBoxes to give them the iPhone-ish look. Another feature they added to VS2010 with this addin is the 'Solution Navigator' (which can be seen on the right in the screen-shot above...no, not the iPhone screen shot, the other one). I've wanted a hybrid class and file browser with search for _ages_ in VS so I'm particularly glad to see this. I'll be trying it out over the next few weeks to see how it staks up against my trusty old "CTRL+ALT+A > 'OPEN <filename>'".

BAs and cocaine…they go together (from what I've seen from most requirements documents) like developers and coffee, and sales executives and three-hundred-dollar lunches. Unfortunately just because your BA does a bad job it doesn’t magically remove the need for analysis to happen, somebody’s got to pick up the slack. If you’re a developer then that somebody is probably you, and to be honest you’ve got enough on your plate already, haven’t you. The best outcome for everyone would be if the BAs cleaned up their act and actually did their job. These are some suggestions for how to get your BAs to drop out of the Tony Montana finishing school for BAs, stop smoking crack and start creating clear, unambiguous and actionable requirements. If this doesn’t work try an intervention or rehab.

Side node: Although Tony Montana was a vicious psychopath without any specific technical skills he wasn’t actually a business analyst, per se.

Pay attention to terminology

Ideally all requirements should be written in a language structured around the domain model and used by all team members to connect all the activities of the team with the software. If your BA uses widget and sprocket interchangeably find out if the two have a different meaning or are synonymous. If your BA uses the two interchangeably but your business reps eyes glow with white-hot rage when you confuse the two chances are your BA doesn’t understand the problem domain properly.

Watch out for stuff that’s ‘pretty complicated’

Some problem domains are legitimately complicated. Sometimes people use ‘pretty complicated’ as a synonym for ‘stuff I don’t understand very well’. Knowledge is power, and I’ve seen BAs hold ‘pretty complex’ over the development team as some kind of Ace up their sleeve.

‘The foobaz report is pretty complex, but in practice all you have to do is multiply this value by 10%’.

There are plenty of aspects of software systems that live outside of code, like processes and procedures, policies, human workflow and the stuff that happens in the heads of the people using the system. As a developer you’re on the line to deliver the CODE part of the system, and the business rules and logic you have to encode in the foobaz report are either complex or they aren’t. If you code it up to multiply all the values by 10% it’s not suddenly going to start to show complex emergent behaviour once it gets deployed to production. Drill down into the complexity that needs to be, or can be implemented, and tell them to STFU about the stuff that isn't/doesn't/can't if they keep banging on about it.

Push back on subjective adverbs and adjectives

For example: 'all pages on the site will load quickly' is meaningless. Quickly relative to what? Get your BA to re-write this to provide something quantifiable, or get them to remove it.

Push back on motherhood statements

For example: 'The system will be easy to use' is ambiguous, and can’t be verified. It adds no value. Best get your BA to remove statements like this altogether.

Get them to think about the negative cases

I’ve read plenty of requirements with little snippets like:

‘if the user has the foobar role and the order has more than one line item they can click on button A to finalize the order’.

This describes the ‘happy path’ well enough, but what about all the un-happy paths? If they don’t have the foobar role what should the button do? Should the user even see it, or should it be disabled? What if the order has no line items? What about zero-dollar line items? What about future-dated orders? Try and train your BA to enumerate the negative cases along with the positive ones, because you’re going to have to build both.

Join forces with the developer’s arch-enemy, the tester!

Testers hate the ambiguous crap that most BAs spew out more than developers, because the personality traits that go towards making them a good tester also make them obsessive-compulsive, detail-oriented, and inclined to be none-to-impressed by prosaic and insubstantial requirements. Wishy-washy requirements are like kryptonite to testers because requirements that can’t be verified can’t be used to raise bugs. Detailed negative cases (the kind I noted above) in the requirements are the bedrock that negative test-cases are built on. Negative test-cases often make up the majority of (sometimes as much as 80%) of the volume of test cases, so without these negative cases testers are not going to feel like they’re giving the system the necessary coverage.

Get them to focus on the What and Why, and stay clear of the How – requirements shouldn’t dictate the implementation

Sometimes if the BA is a former developer, or when an existing system is being replaced BAs will devolve into specifying requirements in prescriptive technical detail. For example:

‘Every night at 12:00 the system will generate a tab delimited file containing the orders from that day that will be FTPd to ftp://192.168.1.54/tony/apps/interchange/’

Really? At 12:00, always and forever? Perhaps this other system we need to integrate with has a web-service we can call to keep the two in synch real-time? And what if tony leaves? Best to specify WHAT needs to be achieved form a business perspective (and possibly WHY to give the developers some context when making trade-offs) but steer clear of the HOW.

Sometimes there are real non-functional requirements that effectively dictate the implementation – if your BA is adamant that something needs to be done using a certain technology then perhaps (in a moment of clarity) they’ve done this analysis. Drill down to find out WHY they, on the face of it, seem to be suggesting the most brain-dead technical solution that has ever crawled out of the UML swamp. Even a stopped watch is right twice a day, and one with a substance abuse problem may be right slightly more often. Drill down into the details.

A similar (but worse) variation of over-specifying the implementation based on an existing system is the ‘nobody knows why it does this, but that is what the existing system does so that’s what we’re going to do’ syndrome, also known as ‘cargo cult business analysis’. Here’s a clue – discovering the answer to these questions is what the ‘analysis’ part of business analysis entails. Don’t accept ‘that is what the existing system does’ as a rationale for something.

Document significant decisions & changes

You approach Anthony the BA after a discussion with the business reps. He seems in his usual hyper-alert state, and he has that usual focused, manic stare. It’s 6 weeks out from ‘go-live’ and you have some specific questions about the security model. You feel that some of the requirements are unclear and can be interpreted in two contradictory ways. He rattles off some answers to your questions even though you’re not sure he’s thought through the implications. You try to draw him into a longer conversation about this but he says he’s in a rush, and to just make it happen. What do you do? You go back to your desk and write an email like this:

To: Anthony@MontanaConsulting.com
CC: yourboss@example.com; businessrep@example.com
Subject: Clarification of <Feature name>
Hi Tony, Just confirming the conversation we had re: <Feature name>, in particular <elaboration of your problem/question>. You said <what Tony said goes here>. I’m a little worried that <your concerns/impact of bad decision goes here>. I’m going to proceed on the basis that what you’ve said is correct, but can you verify this ASAP and get back to me either way?
Thanks
<your name>

Call me an ass-covering whatever, but I’ve been burned by this often enough that it’s almost a reflex now. What if your documentation ‘ownership’ process allows you to update the requirements directly? Why not just run with whatever Anthony said and run with that? Doing it this way if your fears are well-founded someone else might join the dots and realize what you’re on about. If not then you’re giving them visibility of the process. Plus letting Tony or another BA make the updates to the requirements shows that you’re not just making stuff up and then implementing it.

Don’t be fobbed off

Remember that time you stayed up ‘til 3AM in the morning with reflector figuring out how the data contract serializer worked, or debugging that memory leak using WinDBG? Good BAs should be like that but with business processes. Don’t be fobbed off with ‘well, I suppose I could ask the business’.

Further Reading

Writing quality requirements

Role of the Analyst in Agile Projects

Agile Requirements Modelling

Say hello to my little friend

The ABC's 'Gruen Transfer' show chose to award this 'ad' for Microsoft SongSmith their 'worst ad ever' appellation in the first of a series of spots where they present really, really bad ads. While it's amusing to poke fun at MS (in a kind of retro 'M$ sux0rs, slashdot roolz and 1999 is the year of linux on the desktop' way), this one strikes me as unfair. This isn't a real ad intended for airing on television to promote Songsmith to the general public, but instead a cheezy spoof video created by the team who work on Songsmith at Microsoft Research (they say so on their site). For one thing the ad is much longer than a usual TV ad spot, at over 4 minutes long. Secondly I'm fairly certain none of the people in it are professional actors (certainly none of them can sing). The video was filmed at the Microsoft campus for pete's sake! The green coffee cup with the Microsoft logo on it is a dead give-away. I guess advertising folks aren't known for letting the truth get in the way of a good story. I wonder if I make a crappy iPad video can the feature it next week? Also I found the comments almost more amusing than the ad, in a scatological kind of way.

The IT department in your medium-to-large organisation doesn’t care about your productivity. In most organizations IT is a cost, not an enabler, or something that gives your organization a competitive advantage, and your organisation is no different. Shelling out more money for better networking hardware, or more storage, or new software licenses has real, measurable costs that the IT department has to front up for, and which they have to pass on. When you have to wait 30 seconds between double-clicking a network folder and the contents displaying on the screen the cost is so small it’s hard to measure, and it isn’t a cost that the IT department pays. Sure, it robs people of their productivity, bringing in to sharp contrast for most of them just how unimportant they are, and invites them to task-switch to something else which has proven detrimental effects on productivity, but that isn’t the IT department’s problem now is it. 

Your productivity is collateral damage in the IT Department’s war with entropy. Flexibility is the enemy. Flexibility leads to change (forward progress is one kind of change, but allowing users to change their desktop background or their system font is another kind of change). Change leads to increased costs – one out of every thousand users who change their desktop background is going to accidentally lock themselves out of their account somehow, and cost the IT department in support calls to the helpdesk (a total misnomer since there is no desk, and no help). In order to try and put a lid on entropy things are closed and locked down. Legitimate sites and MIME types are inadvertently blocked at the corporate firewall, because there is a risk for the IT Department in letting them through, and there is no cost to the IT department for preventing you doing your job. 

This goes double if you’re a developer. The IT department like homogeneity. They like taking away user ‘rights’, and locking things down. They crave order and structure and minimal surface area. As a developer you don’t fit their model. You need access to configure web or database servers, to start and stop services, to install programs, to attach debuggers. You need exactly the same kinds of rights they have themselves, but you lack the fear of change that normally ensures the IT Department never does anything with them. And maybe you actually know what you’re doing. For the IT Department, preventing you doing your job as a developer is critically important, because as a developer you are an agent of change. Every key-press you’re writing a new future for some part of their IT ecosystem. Creating? Enabling? Improving? Maybe – those are subjective, and the IT Department probably won’t reap any of the benefits of those anyway. But changing – yes & ndash; that is not subjective, and that IS a risk/cost the IT Department must bear. Improvement and enabling are not possible without change, and the IT Department is diametrically opposed to change. Since they can’t directly oppose the change you’re carrying out they need to reign it in, and slow it down. Make you work in a virtual machine. Make you work in a virtual machine via VNC. Make you work in a virtual machine hosted in another country via VNC, over a slow link. 

Processes are one of the chief tools the IT Department has to reign in your positive change: Complex change control processes; opaque ‘network tests’ for anything that is deployed; Refusal to roll out supporting componentry; tiny windows for change to occur in; N months of ‘security testing’ before anything is rolled out. It’s fine for the IT Department to cause rolling outages during the working day because someone there can’t be bothered staying back late to deploy a change, because people’s productivity doesn’t matter to the IT Department. But not you, your work can’t be deployed for another 6 weeks because there is a change embargo in place until the end of the holiday season. 

The IT department is driven by that fear. Fear of change. Fear of additional effort. Fear of being taken out of their comfort zone. Fear of being wrong. Fear that they’ll be found out as imposters.  Fear that if they let you look at that proxy configuration, or that network trace you’ll see why that network folder takes 30 seconds to open for no good reason, and they’ll lose their mystique, their authority. And without that how can they retain control?

Of course their fears are somewhat misplaced. Where else are you going to go? It’s not like there are two IT departments vying for your business. It’s their network, and their hardware. Plugging in your own stuff can be grounds for dismissal, as can attempting to circumvent their controls. When two organizations merge the dominant IT Department will fight aggressively to bring things back into equilibrium. There can be only one. All those change control processes they enforced on you get thrown under a bus while the IT Department’s immune response system kicks in. And once again, if your productivity is impacted by this the IT Department just doesn’t care.

These are my observations from working in a number of medium to large organizations, both corporate and government at different levels. I wish it wasn’t this way, but it is.

Like many people with a technical background I am deeply sceptical about the effectiveness of anti-virus software. Instead I’ve preferred to rely on an understanding of the risks involved with opening emails purporting to display dancing bunnies and the like, and relied on security principles like least privilege, regular patching etc.  In light of the problems McAffee users around the globe had a month or so ago, who wouldn’t question the costs and benefits of anti-virus? Too many times I’ve been told by a non-technical friend or relative about the problems they’re having with their recently purchased computer, cracked open task manager and seen a plethora of anti-virus processes strangling their CPU or flogging their hard-drive to death.

In spite of all this I recently installed anti-virus software on all my PCs. Why? Had I been infected with a virus? No, but I’d come up agains t a nasty bug that was caused by anti-virus software locking a file I’d just written (and which I’d naively assumed I could re-open and write to with impunity). I’m not the only one who’s been bitten by this bug either. This comes back to the age-old principle of computer programming – you want to develop and test your software on environments that are as close as possible to what you’ll eventually run on. When you’re writing desktop software that’s a lot of terrain. The belt-and-braces way to do this would have been to create an huge test-bed of virtual machines, with a good breakdown of anti-virus vendors added as an extra dimension to the matrix, however since I’m just a lone developer working on something cool in my spare time I decided to install anti-virus on my local machine. 

The anti-virus software I chose was Microsoft Security Essentials – it was the anti-virus software that had originally triggered the bug for me on a test machine (a fairly low-powered netbook - I hadn’t even noticed it from a performance point-of-view so I knew I didn’t have much to worry about there). Also it was well received by a number of reviewers so it seemed like a no-brainer. If Microsoft makes a free anti-virus product that is well regarded and has low performance requirements why isn’t something like this built into windows? Two words..Consent Decree. If you’re writing rich-client applications I think you need to take this kind of thing into account, and if you’re looking for something to recommend to that relative whose machine is getting pounded by Norton/McAffee check out Microsoft Security Essentials.

Since the release of the .NET framework there has been a quiet arms-race between those who want to protect their intellectual property, and those who want avail themselves of the intellectual property of others. And from where I’m standing, the reverse-engineers are winning, convincingly. 

The CLR is a virtual machine, and for JIT compilation, linking and introspection to work a considerable amount of type information must remain in an assembly when it is compiled.  Because of the extra meta-data (compared to a native C/C++/Delphi etc DLL) if you’re shipping an un-obfuscated assembly to your customers you may as well be giving them the source code. Sure they’ll miss out on the “why” in your comments, but other than that they get pretty much everything.  Tools like reflector just make it that easy to reverse-engineer un-obfuscated .NET code. This leads most people who are developing commercial products built on the .NET framework that are shipped to end-users to investigate obfuscation as a means of pr otecting their IP. Often this is also done to prevent easy circumvention of any licensing checks and restrictions that developers may have put into their .NET products.

Obfuscation can use a number of techniques, such as stripping meta-data, encrypting string resources, scrambling control-of-flow, adding rogue IL instructions that don’t break the program during execution but crash ildasm or reflector, aggressive method overloading (effectively another way to throw out information by removing method names), “packing” the application to hide the IL, and safeguards to prevent debuggers “attaching” as well as probably dozens more that I’m not aware of. And the reverse engineering crowd seem to have counter-measures for every one of these techniques.

Sometimes this takes the form of de-obfuscation tools specifically developed to un-do the work of a particular obfuscator ({smartassasin} for {smartassembly}, “the Xenocode solution” for Xenocode, DotFuckScator for dotfuscator etc). Usually this is a “partial” thing – after all the obfuscation process usually removes information which can’t be recovered, but the de-obfuscator will usually un-encrypt encrypted strings, allow the assembly to be viewed in reflector and un-scramble the control-of-flow obfuscation. No, I haven’t tried all these tools and some of them are now a little out of date, but I’m fairly sure similar ones exist for the newer obfuscation products, and it really doesn’t matter because the general-purpose de-obfuscation tools are even scarier.

And if the thought of obfuscator-product-specific tools isn’t worrying enough, or you were thinking about rolling up your sleeves and writing your own obfuscator have a look at this - a general-purpose re-assembler with de-obfuscation tools built in, demonstrated by Daniel Pistelli, author of the “NativeBlocks” application (currently unreleased, but you can be sure serious reverse-engineers have tools like this or more powerful). By running a few fairly short scripts through his tool he is able to remove a lot of the control-of-flow obfuscation in reflector (before Lutz Roeder gave it in to the care of red-gate/sold it). This is in addition to publicly available tools like Rebel.NET (a re-assembler for .NET, also by Daniel) and simple assembly explorer (a class browser and re-assembler, one of the few reverse-engineering tools I found that came with source…I guess if you know what you’re doing with RCE you don’t need source).

I guess it’s not that surprising that reversing of .NET applications is easy for those who know how. Even native applications that don’t have as many restrictions as .NET applications, and _CAN_ quite happily redact all of their internal structure as they feel like during the compilation process are frequently reverse-engineered using tools like Ollydbg, IDA and Hex-Rays. Ultimately if it runs on a computer outside your control it can be broken. The ethics of all this reverse-engineering seems fairly dubious to me. Aside from the area of malware reverse-engineering I can’t think of many legitimate uses for this stuff, but that doesn’t stop me from being impressed by their ingenuity. 

That is the only logical conclusion I can draw from his recent comments. Either that or he is stupid. Otherwise why would he make ridiculous claims about Google’s recent collection of public WiFi data when doing streetview data collection, saying that “It is possible that this has been the largest privacy breach in history across Western democracies”. Sure…it’s possible. It’s also possible that the senator’s remarks are nothing more than a cheap use of parliamentary privilege to get back at Google for their speaking out about his ridiculous internet filtering plans.
Compared to the petabytes of search and adsense traffic, web crawl data, email and newsgroup postings that Google has been gathering for about a decade, this data set must be truly immense to be of such a privacy concern. Also his claim that the collection of data could not have been inadvertent shows a basic lack of understanding about how software works, and is built. Remember this (Google) is a company obsessed with data – A/B testing to determine which shade of blue in links converts better. So I’m not surprised that “get everything” was the default when someone there wrote some WiFi code for a different project, which was then re-purposed into StreetView. In spite of Eric Schmidt’s comments on privacy Google still has a pretty good track-record – remember Google vs. DoJ? Redaction of faces and care numberplates in StreetView?
Also the notion that Google need your permission to photograph your house is quite amusing. If I print the salacious details of my personal life on a billboard outside my house have Google violated my privacy because they know how to read?

[Disclaimer: One of my brothers works for google...I have worked for Microsoft on and off for a while so there's no love lost there. I was nearly sent home one day from MS for wearing a Google T-Shirt, but that is a story for another time]

I was looking at Word 2010 and WordPad (in windows 7) SxS today. There were a few things that occurred to me.

• The tech support folks are going to hate this.
• Two different teams, two code bases, two sets of icons, two sets of test cases, two ribbon implementations, two release cycles - all from the same company.
• I wonder if the bottom one is what WordPad in Windows 8 will look like?
• Dam, Word 2010 looks nice.

I often hear questions about .NET development and the Windows ecosystem that deal with very specific situations.  “What order do these events fire in?” “Will doing this leak memory?” “Will I see those details in a SQL trace?” “Will that be lazy-loaded?” When you’re a developer you often live and die by these kind of details, and humans are notoriously fallible – so why bother asking the question at all – why not write a simple program and find out?

I often see similar problems in the enterprise – questions that could be answered with a simple prototype, a cursory inspection of the data or the event logs, or a 5-minute discussion with the owner of an external system are left to fester and take on a life of their own. Meetings are called because we’ve got a problem calling system X’s web services. Really – what’s the problem? Well, we don’t know – we haven’t tried calling their web services. Sheesh.

Obviously it’s a judgement call on the part of the developers as to when to answer a question with a simple prototype and when to put up your hand and ask (and of course not all questions can be answered by working code). If the time it takes to ask the question properly (provide all the context, environmental details, sample data etc. to those you’re asking the question) is greater than the time it would take to answer it authoritatively yourself then DIY is a no-brainer. Similarly if you’re making an important decision that will be costly to reverse later then you’d really be foolish to take someone else’s word for it anyway, so you might as well answer the question with working code. Also, if you’re going to be blocked until you receive a response I usually ask the question, and then begin trying to answer it myself with working code (since I’m blocked anyway). Typically I find if you can’t answer the question fairly quickly with working code either you’re not clear about what you’re asking, or your question is too hypothetical (“will this work on MONO on Linux”? – if you don’t have a Linux VM lying around to test this hypothesis either there is a huge gap in your environment “test” matrix, or you’re asking a question that is purely academic).

A single data point doesn’t prove a hypothesis – all swans were believed to be white once, but all you have to do to disprove this theory is to find one black swan. If you’ve answered a question with working code, but are still doubtful go ahead and ask the question, with the evidence you’ve amassed from your code experiments included. People will see that you’re not being lazy and have taken the time to do basic investigation yourself, and hopefully people will only respond if they have something specific to add.

See also: how to ask a question http://catb.org/~esr/faqs/smart-questions.html