The Politics of Software Requirements

Friday, January 13, 2006

Politics is part of human life. It exists at all levels, and it is not inherently bad. There are good politics as well as bad politics. The fuel of politics is power, and within a software engineering project, requirements specifications are very powerful. They can be used to determine the direction of a project, to promote different viewpoints, to identify culprits in the case of failure – essentially, he who controls the requirements pretty much controls the project. Therefore the role of a requirements manager, which paradoxically is rarely a senior role, is fraught with dangers. There is a good essay (which I mentioned a few posts back) on this topic, which may appear to be black humour, but as you read through it, it becomes apparent that there are some uncomfortable parallels with many real world projects in there. To restate, politics are part of software requirements, and they need to be managed. They need to be managed in a neutral way, without adding fuel to any fires, and without intentionally upsetting anybody. The best way to do this is by presenting an extremely well verified, watertight and managed set of requirements, which are fully visible to all stakeholders. The role of the requirements manager is seriously corrupted if they try to actually influence requirements. The role is to understand, interpret, verify and translate, whilst remaining neutral. The discussion, at whatever level it happens (rational, biased, politically-motivated,…) should happen between stakeholders. If the requirements manager stays out of arguments, and concentrates on steering between obstacles, then there is some chance that a cohesive, realistic requirements specification and a reasonable quality product will emerge. Incurable political players – and they do exist, everywhere – will be left with no option but to find a more easily influenced project to use as a political football.

Politics Oriented Software Engineering

Tuesday, January 10, 2006

This is absolutely brilliant. It is also sadly accurate. I was going to get around to writing an entry about the fact that almost all "how to" books about software engineering processes start off with the (false) assumption that everybody in a project is working towards a common goal. Now I don't have to. I'm willing to believe that this mediocre behaviour extends outside of the software industry, but I've worked outside of the software industry, and I've never seen anything anywhere near so bad (although possibly at the time I thought it was). I have had some extremely good managers in my time - some even within the software industry - and some extremely bad. The bad ones were exclusively in IT.

iPhotocopy

Wednesday, December 07, 2005

Zero points for originality… : http://www.theregister.co.uk/2005/12/07/creative_vision-m/ Can't the Japs et al work out the simple fact that if people WANT an iPod, they'll buy one. People who consider that Steve Jobs, not Bill Gates, is the Son of Satan, want an ALTERNATIVE…..don't they ? Honestly, it is all about fashion: very soon, iPods must morph from being "cool" to being "boring" - it is amazing it hasn't happened yet. I bet the average 16 year old girl does not want to go around looking like she's borrowed her dad's iPod, I'm sure that people would buy a better product, if one was offered. Clearly it is beyond the reach of the competition to (a) work this out and (b) come up with a new approach.

User support = support from users ?

Friday, November 11, 2005

You, er, want to me to destroy my data to debug your product ? This is a typical tale of the attitude of many software companies these days to user support. The fact that it emanates from a company which I used to believe offered excellent user support makes it sadder, but nevertheless, it is fairly typical. The company in this specific case is iView Multimedia, the product is iView Pro v3, the latest update to an excellent, agile multimedia catalog application released on 1st November. Unfortunately I discovered several problems with this new release. One, which killed my upload workflow stone dead, was an apparent change in AppleScript syntax. So I reviewed the FAQ, reviewed the user forum, drew a blank, and emailed user support. Here is the core of my support request: > Hello > > I've just upgrade to v3, and to my surprise (sort of...) I've discovered > that the AppleScript syntax for referring to custom fields seems to have > changed. Some 3 days later came the reply (iView turnaround on support used to be closer to 3 minutes, but since they have a clearly issue-ridden new release just out, I'll forgive them that): Have you tried this feature with the latest build of MediaPro from our website? What is the Build number of the version of MediaPro that you are currently running? So, what is wrong with this ? First, they're asking me for the Build Number of a product which was released less than a week ago. Exactly how stable is this product, if they already have a new build out ? They don't tell me where to find the Build number (it is in the About popup), and on the website downloads page the build number is not so obvious (there's a small unlabelled number there, but it would not be difficult to make it clearer). So, rather than ask me "are you using Build n ?" and telling me how to check, I seem to be expected to download, unpack, and install the application again, noting the Build number before and after to see if it has changed. Not ideal. I'd note as well that their download files don't even identify the version number - they've all been called IVMP.SIT since at least v2.0, if not before. Next, there was no attempt at all to answer my question. I could infer, perhaps, the standard "it's never done that before", but I'm not even convinced of that. I am left almost certain that the support guy has not lifted a finger to attempt to validate or duplicate my issue, which is actually quite specific. I might expect something like "sorry, we tried to duplicate the problem, but we cannot. Can you provide us with further information ?" before asking me to take full responsibility for testing. This is not what one pays $199 for. If he could tell me, yes, it was an issue in Build x, but it is fixed in Build y, then fine. But asking me to find out for myself when it could be verified at source is pure buck passing. Running AppleScript in iView, or indeed anywhere else, can have disastrous results. I should not be asked to try this, before any other avenue has been explored. In this case I could seriously compromise a 6 year photo archive. Ok, I'd be stupid to do that, and the security of my data is my responsibility but part of user support should be to suggest safe scenarios. Even worse - in parallel, I discussed the issue on their support forum, and I had in fact found a workaround, which I posted, and which at least one other user succesfully adopted. But this appears to have gone unnoticed. A major source of feedback, albeit unstructured, on their own server, seems to go unused. Let's be clear here: this is NOT user support. This is asking users for debugging support, and charging them for the privilege.. I like iView very much. I've used it for years, although I used to use Aldus/Adobe/Extensis Fetch/Portfolio, and I keep an eye on alterntives. The excellent scripting support and user support for iView kept me a firm customer. It would be quite complex to switch now, as I have a lot of development effort invested in an iView based workflow, not to mention many annotated catalogs. Possibly (dare I say probably) the company realises that switching on this sort of product is not a decision made lightly, and acts accordingly when allocating resources to user support. However, reputations are hard won and easily lost. I hope iView Multimedia realises this.