Analyse This

• 21Jun

  The ‘value for Money’ fantasy

  Uncategorized No Comments
  Half the money I spend on advertising is wasted; the trouble is I don’t know which half.

  John Wanamaker, (attributed)
  US department store merchant (1838 - 1922)

   

  I’ve been involved in a number of organisations that at one time or another have done ‘value for money’ exercises.  To cut a long story short, I usually have issues with this because, frankly, I don’t think value for money exists:  It is a abstract concept that exists in people minds - rather like ‘the perfect lasagne’ or a ‘brilliant restaurant’.  Paradoxically, that doesn’t mean it doesn’t exist. People have - and should have - very clear and strong ideas about their applications and projects and their relative worth. If they want to describe this as ‘Value for Money’, fine. The problem is that it is difficult to demonstrate it for sure. Like “Tescos’s is better value than Sainsbury’s” (something I’ve heard people have passionate debates about), you’ll never prove it. It’s just instinct im afraid.

  We live in a world where people seem to expect absolute certainty and think that everything can be turned into a science: The idea that you might be developing something on the back of instinct and passion rather than a formula the finance people can work out with a calculator will sit uncomfortably with some, but that is the reality - benefits of technology are often intangible and unpredicable.  Get over it.

  An example of this came to mind when I was at an event run by a large UK department store many years ago. The web was in it’s infancy and my company (me, really) had done some work developing their first web site. Later, they had added ordering facilities for a selection of their products.

  I got talking to a lady that turned out to be very senior in the Marketing area of the organsiation.  Very briefly, she was moaning that although they had invested alot of money into the site (much to my annoyance they had done most of this through a rival company), there didn’t seem to be much evidence that it was generating sales:  The site itself seemed to get alot of hits but the rate of ‘conversions’ (turning these into sales) was quite low.  Overall sales for the company as a whole were doing OK though, but there was pressure to consider the web investment and perhaps even drastically cut it back.  She was dissapointed with what was happening and asked me for my opinion.

  “Isn’t it obvious what is happening?” I said.  Silence, shrugged shoulders.  “People are going to the site, looking up poduct information and then going into the shop to buy it” I said.  “I probably would”. I continued “so the site is doing a valuable job and providing a service but not in a way that anyone intended”.

  “Interesting” she said.  “I hadn’t thought of that - how do we prove it?”.  I explained that you can’t and I suppose if I had really wanted to be clever I could I could have quoted John Wannamaker above who famously said “half the money I spend on advertising is wasted, the trouble is don’t know which half”: It’s probably best I didn’t - I always thought it was Lord Lever that said it.

  The marketing lady got another glass of red wine and changed the subject.

• 13Jun

  User Stories dont give you the whole story

  Uncategorized No Comments

  I have always had a concern about the way User Stories are sometimes regarded as all you need to build something.  Don’t get me wrong, they are a good technique to focuss the mind and provide high-level statements of intent.  The problem is when people do a workshop, come up with a set of stories, and before you know it development is starting.  Very worrying.

  Before User Stories become the norm, people used a variety of techniques for expressing these statements but often it became problematic.  Typically you ended up with granularity problems - some statements represented massive pieces of work taking weeks or months, others were very small, but hard to progress because they had a large number of dependencies.

  User Stories at least give an ‘out of the box’ solution to some of these issues, but they still need to be supplemented by something more.

  “I think we’ve demonstrated on this project that you can build a system just from User Stories”  One lead developer said to me not so long ago.

  “Of course you can” I said. “You’ve been on the project for a year and a half. You’ve had time to build up your knowledge. What if someone new came in with no knowledge of anything?  How confident would they feel, do you think?”  Silence.

  He had a point, of course.  If you are woking on something for a long period you have the luxury of getting to know it ‘inside out’. This gives you the ability to ‘travel light’ and also gives you the confidence to think beyond the work itself and to start considering about how you structure and organise it.  The lead developer in this case probably didn’t need the User Stories either, frankly.

  Being on a single thing for a long period and getting to know it intimately, is what you would expect in the lean world, given it’s background in production and manufacturing. In production environments people will be working in gangs or on lines doing a single activity. They become experts and then gradually become confident enough to make judgements about how the process itself should be altered.  It occurred to me the other day, that most of the ‘lean’ and ‘agile’ proponents I have met within IT, also tend to be people that are working on single products or single developments and have done so for some time.  They are therefore, to some extent in a ‘comfort zone’.  I never seem to encounter many ‘lean’ proponents that are spread across multiple projects with multiple stakeholders, and that require multiple domain and technical knowledge day to day.  This might be pure coincidence of course, but personally I think it is quite significant.  The people that work in this type of environment are the ones less likely to want to ‘travel light’ and more likely to want a different approach to agile - or rather agile ’supported by something else sitting outside it’ perhaps.

  As I have said previously in this Blog, if you think User Stories are all you need, all I can say is - good luck.

• 16May

  Another slice of Cucumber, ‘Developers Develop’ and the Mission to explain

  Uncategorized 3 Comments

  Someone stopped me at work about a month ago and said that they thought my comments about Cucumber (here) were a bit harsh.  ‘Why’, I asked?  ‘I thought they were quite mild’.  In essence they thought that what is being produced with the automated tests are fine if you just view them as smoke tests or maybe regression tests – basically as ways of proving if your system works, and it’s a bit of a mistake to assume they are providing a repository of knowledge about the system.  I think he is right.

  The idea of automated testing is fine if you accept it for what it is, and remind yourself of this regularly:  That is, that all you are doing is simulating what a person would do. Nothing more.  As such it is important not to get carried away with what you are achieving by using it.  Back in January I spent much of the month writing Cucumber tests for a system I am involved in supporting, and then doing a lot of the Ruby implementation.  This system is a challenge on several fronts; the technology is quite old now and also complex.  Release and configuration is a nightmare. But there is also something rather more significant: It isn’t particularly well understood.  Or at least, wasn’t at the time.  The time I spent doing the tests and writing Ruby didn’t improve my knowledge of the system at all:  Luckily I had had some time a couple of months earlier to learn about it and to put together some other analysis artefacts.  Not to the degree I would have liked to, but it was a start.

  So I guess what I am interested in these days is how you arrive at the tests in the first place.

  If like me you are often involved with systems that are ‘legacy’ or maintenance challenges for various reasons, one of the biggest issues is discovering what the system is supposed to do in the first place.  This seems like a rather obvious statement but in my view is the root cause of much lost productivity both within and outside IT.  As I have stated previously in this blog, there can be an institutional issue with this:  Often the users might not know anything either and expect IT to educate them.  The knowledge problem can exist equally between IT and the users (or ‘business’). 

   

  ‘Developers Develop’

   

  I used to hate that phrase.  Many years ago I had a boss who used it to describe the organisation of the department.  ‘It’s very simple, Mike’ he said, ‘Developers develop, Analysts analyse, Project Managers project manage’.  I took issue with this.  It struck at the heart of why I went into IT in the first place:  This was to see the fruits of the analysis and design implemented in the system, and to see how it changed the working lives of the people using it.  At the time my boss made this statement, I was a developer, but I had come from an analytical background and the work I did tended to be a mix of development and analysis. What motivated me was the end product:  Slightly like when you design some building work on your house or do decorating:  You want to see the finished article, and development is what you go through to get there.

  For a long time I assumed all developers thought like this.  Why wouldn’t they? Years later of course, it became clear that many developers – probably the majority if we’re honest – don’t think like this.  They are interested in writing clever code and are motivated by the technology and art of what they are doing. Often they aren’t particularly interested in the end product or the users or, astonishingly, even the organisation itself.  My way of thinking represented a specific group: a small Genus within the overall Species of developers.

  The point is that if people are struggling with the basic understanding of the system they are working on (and I don’t mean at the code level) no amount of automated testing (or any form of coding) is going to help you.  My January foray into Cucumber tests in Ruby didn’t improve my knowledge of the system but it was interesting to do some coding and it certainly brings home the importance UI design and user experience design:  get that right and your tests can be much simpler to write.

  But even if you can write tests, do you have the knowledge to do so? You don’t suddenly end up with tests out of nowhere, so how do you know if they are complete?  How do you know if you have been through the right thought process?  This seems to me to be the issue with Test Driven Development. 

  My concern is that automated acceptance testing and TDD in general can actually result in a rather shallow, simplified view of the world, where people are writing tests before they have the knowledge to do so.  There has to be some form of ambient ‘layer over the top’ that provides the necessary background and context people need.  Otherwise the danger is of people just ‘going through the motions’ to tick boxes (and I’ve seen this).  In an earlier article I likened it to ‘writing exam questions for a subject you don’t know particularly well’.  Can you do it?  Yes, of course you can – by this I don’t mean ‘are the questions factually correct’; I mean are you covering the right things? Are you getting the insight and understanding you need?  That’s the tricky bit.  In some ways, I’d rather forgo the automation, and address some of these fundamentals first such as:

   

  • Proper documentation of, at least, the happy paths through the system but recorded in a user-friendly way accessible to IT and business users in equal measure; Use Cases are fine for this if they done well (but as we know, there is plenty of opportunity to not do them well).  I have an article here about the issues around this;  And before you ask, no: this absolutely isn’t the same a set of User Stories. 
  • Ability to repurpose the documentation into user-facing materials: training courseware, help files and so on, that can assist in building a lasting partnership with the users;
  • An acceptance that this material needs to be maintained continually forever, and isn’t a ‘one off’ ‘project’ activity to get forgotten afterwards; A cultural acceptance that such material has to be continually maintained and improved and that people should want to do so.

  If this is done wisely and with vision, it can address the ‘common language’ issue which blights many organisations; it also provides a foundation to write our tests and means we can hopefully start to talk confidently about what we are doing, even if it is new to us.  Remember that even if something is new to us it isn’t necessarily new to the organisation (the system I was doing the tests on in January has been in use since 2000: Heaven knows how many people have worked on it since, and how much time has been spent over that time try to reacquire knowledge about it).  Personally I think the benefits that can flow from this vastly outweigh the benefits you will get from automated tests, and quite possibly consume lest time.

  Of course, no developers (or as I alluded to earlier, few developers) will ever suggest something like this.  The cucumber automation part, probably appeals to most of them though, because it’s, well, coding.  So in a way, perhaps my former boss was right after all.  Developers do ‘develop’, and it is up to others (people like me for example) to ensure they have as much information as possible to be productive at it. 

  A final word about ‘automation’. It occurred to me the other day that the idea of automation is something that is buried deep in the human psyche – and probably something that goes back to the age of the space race and so on.  If you have ever watched an episode of Thunderbirds, you’ll notice how everything is labelled as ‘automatic’ (and ‘atomic powered’). We’re brought up with the idea that anything ‘automatic’ ‘robotic’ or in some way unattended is always a good thing. Remember also the part in Jurassic Park when John Hammond proudly showcases InGen’s advances in genetic engineering and shows his guests through the island’s vast array of automated systems. Later he blames the problems on an over-reliance on automation and a failure to respond to what humans were actually observing.

  Interesting.

  The ‘Mission to explain’

   

  About 2 years ago I was on my feet doing a presentation when someone asked me what I thought the role of a systems analyst (or indeed any analyst for that matter) was.  I was a bit taken aback by the question.  Thinking quickly, the phrase ‘it is about ensuring that the developers have enough information to do their jobs without having to ask too many questions’ came to my lips.    Not a bad definition, actually.  In some senses it is also being able to explain things to developers, managers and the users (or the horrendous ‘customers’ as we are now obliged to call them). 

  The key message in this article is that if as a team we can’t explain our systems to ourselves, let alone to our users, how are we supposed to write tests for them?  Obvious I suppose, but I just don’t get the feeling that the ‘layer on top’, ‘context’ and ‘background’ that you need before you even start is getting much attention. Many don’t even seem to acknowledge that there is a problem; strange, since I seem to observe it every week and I have written about it here.  There are massive opportunities and benefits available also: With a bit of investment and slightly less of a focus on automation as the be-all-and-end-all, we might actually achieve them.

• 23Apr

  Economics is a discredited discipline

  Uncategorized No Comments

  This is rather off-topic compared to what I usually write about, but anyhow.  What’s the point of a blog if you can’t say what you think.

  I came across this acticle recently which goes some way to summarising what I have been saying for some time (even before the economic downturn over the last year or so), which is that Economics is a discredited discipline.

  http://www.timesonline.co.uk/tol/comment/columnists/article5689642.ece

  What has become clear over the last year is (a) most economists have absolutely no idea about what is really going on, and (b) the profession of Economics itself has no culture or mechanism for admitting failure. Therefore it also has no concept of attempting to improve itself. When a problem or disaster ocurrs in disciplines such as IT, medicine, engineering and so on, people hold their hands up and admit it.  Especially in engineering, there are clear procedures and expectations on people to understand the cause of the failure, and then to learn, and improve. 

  This notion seems to be totally lacking in Economics:  I have seen not a single economist over the last year saying ‘actually, we don’t fully understand this stituation - we’re learning to understand it though, for the benefit of the public’.  Such statements are commonplace in most other disciplines.  Why is it that Economics has absolutely no notion of self-doubt?  Why is it that it has been allowed to be dressed up like a branch of chemistry, when, it seems to me, it is nothing more than guess work?

• 28Mar

  Doing the knowledge

  Uncategorized 2 Comments

  Because I am an analyst, and because, unlike many people in this industry, I actually was an end-user sitting on the other side of the ‘UAT divide’ at one point early in my career (forcing every IT professional to do a period in non-IT roles where you actually have to use the systems being built is something I would strongly recommend:  you will certainly learn more from this than from many training courses),  the things that interest me more and more these days is how knowledge of the processes describing how the organisation operates is recorded and managed.  By that I don’t mean how you conduct the analysis itself (though that can be challenge enough):  What interests me is almost more important: what you do with it afterwards. It always makes me smile slightly when a person in IT says they are going to visit people in ‘the business’ (a horrendous term - although ‘customer’ isn’t much better) to find out the detail of how something is operating:  They talk about it as if they are on a pilgrimage to request elightenment from the Deli Lama.

  The reality is, of course, that the users may not know anything.  Trust me, I was one of them. In IT, we’re conditioned to view the users as mystical deities with the definitive answers. Few people seem to realise that often the users may just be in a role by accident and they have to make the best of the systems they have been given - horrendous as they might be.

  There is an important point behind all of this.  Recently I met some users to go through possible future enhancements to their system.  Although the meeting was productive, at the end of it I asked them out of curiosity how they learnt how to use the system in the first place.  The answer was that it was a combination of word of mouth, gleaning nuggets of information from other people in the office and ‘just picking it up’. Basically they are just muddling through - though It’s not their fault of course.

  Not very impressive, is it, given that we expect these people to be the fonts of all knowledge; and if the system in question had been more  complex than it was, and their enhancements more demanding, it would have raised serious alarm bells with me.

  Personally, i’ve never been a great one for ‘just picking it up’.  Picking what up exactly?  Bad habits and erroneous procedures that the organisation spends years later undoing?  The fact that many IT initiatives and indeed entire projects can be blighted by a lack of knowledge is in my view one of the most inportant issues the enterprise has to deal with.  In my job, I see developers struggling almost every day with issues not to do with code quality or the deployment, but with the basic understanding of the fundamentals of the system they are supposed to be working on.  As I said previously here, one of the things that concerns me about automated testing is that it doesn’t contribute anything to one’s understanding and knowledge of the system. If the team are struggling with the basics, no amount of coding or automation is going to help you.  It can on the contrary, give people a sense of ‘false success’ where they appear to be making greater progress than they are:  But how exactly were the stories and and tests arrived at?  Are they right?  Are they complete?  (Oh, and I should add that it takes a long time to do).

  Go on a pilgrimage to ‘the business’ and you often find the same basic thing - people struggling with the understanding and trying to aquire ‘the knowledge’.  

  Another very interesting issue that sometimes comes to light when talking to the business users is that often they expect the IT department to already know the answer to the questions they are asking: they are implying - albeit subtly - that they expect the IT department to already have the knowledge. In addition, and perhaps more importantly, they think this is the way it should be.   

  There are important issues for agile in this.  When people ask me about what I think about agile, my view is always the same:  I agree with most of it.  The percentage tends to hover around the 70-80 percent mark. The remaining 20 to 30 percent consists of miscellaneous concerns chief of which is around the area of knowledge management and ensuring that people (in the business and in IT) have the fundamental knowledge and understanding to even contemplate starting on the piece of work in the first place (or even having an informed chat about it).  Also, will the knowledge that has been gained during the piece of work be propagated into the future, so that when a follow-up piece of work takes place in a years time, we are not continually asking the same questions?   This kind of thing doesn’t seem very important to many agile proponents.  To me, though, it is critical:   There must be importance attached to managing knowledge of the ‘as is’ state of our systems and processes. This benefits all the projects and initialtive going on.    I hear and read little in agile about this, and worse still, sometime such things even seem to be discouraged.  Crazy.

  Going back to the user (or ‘customer’ as we are now forced to refer to them):  Many users are under the impression that this is already done. They are obviously surprised (or perhaps annoyed) that we are continually asking them questions about things we ‘already know’. After all, we built the system in the first place, didn’t we?  They view IT (rightly) as guardians of this kind of knowledge and as custodians of the systems themselves. And I agree:  I think that is exactly how an IT operation should be, and this is why I have a bit of an issue with the ‘customer’ definition - I guess it’s fine if you know the specific context but it never seems to convey the partnership or collaborative nature of development and as such it sits a little uncomfortably with me.

  So what are my conclusions?  Well quite succinctly, I think ensuring ‘the knowledge’ is available within the team (and outside in the wider IT and business community), and that this is maintained properly irrespective of what projects happen to be going on at that point, is a critical objective for the enterprise. It’s not just an IT issue, far from it, But for IT Is at least as important as acceptance test driven development, auto-deployment, and even issues around code quality and refactoring. In alot of instances it is more important. How can it not be?    But it also requires the same level of time and investment. I am not sure it is getting the attention it deserves, though.  A shame, or perhaps an irony, since it is so obvious.

• 25Mar

  A new agile method: ‘Getting on with the work’

  Uncategorized 1 Comment

  About 10 years ago I was working on a project that was something of a nightmare challenge and fitted many of the criteria of what I have later described as ‘the existing system syndrome’.  That is to say, it was a replacement, pretty much-like-for-like actually, of an existing application. These projects are almost always in my experience the most difficult and problematic.  Many people are surprised by this statement. Replacing an existing system should be easy, surely?  You already have the knowledge?  You have the existing system as a basis?   The business area using it is probably mature and knowledgible? 

  Well, alot of this adds to the problem, bizzarly.  For one thing, the expectation on the part of the customer will be that it is ‘just an upgrade’ or a ‘conversion’ and therefore they won’t want to fund it properly.  For another, the simple fact that you are taking something that people already know (and sometimes love) and replacing it in it’s entirety means you have on your hands a potentially complex reverse engineering exercise (or at least we did), but it also taps into alot of emotional baggage that end-users have built up.  ‘Oh the old system was so much better’ some histrionic soul emailed me (because a specific keyboard shortcut had changed if I remember correctly). It’s like trying to recreating the recipie for the favourite lasagne that someone likes.  You’ll never get away with it lightly.

  There were a bunch of issues we faced with this project.  It was poorly estimated for one thing (not by me, I hasten to add, but probably as result of the mind set I have just mentioned). Yes, we did have some of the source code for the system we were replacing but this was incomplete in parts and in any event was presented to us as being somewhat ‘unreliable’ in terms of the version.  We had a compiled executable and installer (which may or may not have been built from that source code), and a set of documentation from about 6 years earlier describing the calculations the software had to perform.  It did, however, have to behave exactly as before.

  This scenario throws up a whole load of discussions, but needless to say the project did run into problems - unsurprisingly - and I set about thinking of ways in which we could restructure the project to help deal with them.   It seemed obvious we would run into very serious issues if we didn’t, and there needed a way of ‘blowing the whistle’ if the right things didn’t start happening pretty quickly.

  Over a combination of lunch and a glass of Leffe blanc after work with a colleague, the solution became clear. To cut a long story short, we would dissect all the existing tasks and requirements and structure them into logical groups based on how well they fitted together, their generic size and so on.  We would then agree priorities and allocate resources to them.  Crucially, the project would be structured into weekly development cycles, where we would do development basically from Tuesday to Thursday.  Friday would be set aside for testing, verification and deployment; Monday would be set aside for responding to customer feedback in the morning, planning in the afternoon, and then a view would be taken on how well we thought things were going over all.  If there were serious concerns about progress we would ‘blow the whistle’, escalate the concerns to more senior levels and work out a way forward at the earliest opportunity.  This might involve temporarily suspending the project. 

  We called this approach…  well, nothing, really.  It just seemed a more sensible and logical way of structuring and getting on with the work. 

  At this point in the article I was going to run a ‘what happened next’ competition to see if you could guess what happened when I presented the idea, but I’ll save you the trouble.

  It got turned down. I think the reason I was given was that ‘it would be seen as an admission of failure’ to go down this kind of route.  So we continued as before, and the system did eventually get delivered:  it didn’t turn out to be the horrendous abboration it could have been, on the contrary, in fact.   Towards the end I even got paid for some of the extra overtime, and managed to get home at a reasonable hour.

  I promise you I’m not complaining.  Projects like this are what they call ‘character building’ and do give you an interesting insight into many things you won’t get from any formal training.  The fact that I came up with the new (to our company anyway) approach to project structure in about 2 hours I also find quite interesting when I look back and I’m rather proud of.   Nowadays of course, ‘agile’ is an industry, with dozens of books, conferences, training, communities and so on.  It makes you think. To me, though, most of the ideas in agile (though not all of them, I can assure you) are just common sense and there isn’t that much to diagree with.   So perhaps ‘doing the work’ is now the way forward.

• 08Feb

  PICK your database

  Uncategorized No Comments

  Whilst clearing out the loft recently, I came across some manuals for Prime INFORMATION which was a database management system I did some work with many years ago. INFORMATION was a dbms which ran on Prime Computers (minicomputers) and was what we were using before we graduated up to the likes of Paradox and Access, if you can call that a graduation.

  INFORMATION was a clone of a database implementation called ‘Pick’. There are many variants - some of which are still around today, but all have the same central concepts:

  • multivalued fields: It is possible to hold multiple occurrences of the same data item in the same field (assuming of the course the field was created as ‘multivalued’).
  • associations: fields that should always be populated together as a group, and would generally be retrieved or processed as a single ‘entity’ can be defined as such, which helps to give them some additional meaning.
  • fields in a table (or file) can represent either actual physical data (called ‘D’ types) or derived or computed data (called ‘I-descriptors’) which enable the field to contain the results of a calculation. This calculation might be operating on fields in that particular table/file, or can be operating on fields in entirely different tables/files. If you wanted, say, to display an employee’s workplace location (which you might have to get to by joining to the relevant reference data) you would do this in INFORMATION by creating a field with a ‘location’ containing some code that would join to the relevant table and/or perform the necessary calculation and provide the result you wanted.

  All very non-relational, of course.

  The idea of mini and mainframe computers always seemed rather exciting and glamorous to me, and Prime INFORMATION also held it’s own attractions. For one thing it seemed to actually mirror the real world, in terms of how data was structured. This always appealed to me, and despite spending subsequent years working with relational databases, the Pick approach, just seemed more logical somehow.

  Lets have a look at how data is held in an INFORMATION file, based on an example in the manual. Each file (analogous with a relational ‘table’, or ‘entity’) is described by a data dictionary file, which can be queried and updated using the same language and editor that you use for generating queries or writing updates.

  

  An INFORMATION data dictionary

  In this example, the command LIST DICT EMPLOYEES has been executed to list the dictionary of the employee file. We can see that the file contains various fields of different types.

  The dictionary has 7 columns:

  • Field Name: self explanatory really, but is the internal, unique field name;
  • Type: as described
  • Location: position in the file, or the calculation that needs to be performed to retrive the data
  • Conv: Any conversion to be performed. From memory I think this is very similar to data type
  • Display Name: self explanatory - simply an alias, but you cannot refer to this in queries
  • Format: Alignment etc.
  • SM: Whether the field is single or multi valued

  In the example, the first 5 fields are data fields (’D’ types) representing phyical data that has been entered. These have a location of 0-4 merely identifying their position in the file. Note that number 2 - FNAME is multivalued, which make sense as employees can have several first names. The currency fields SALARY and MTH.SALARY have conversions applied, presumably to define them as numeric. The last 4 fields are interesting. FULLNAME has some code as it’s location and is simply concattenating the full and last names together. JOB.GRADE contains code that is going to a different file and retrieving the grade based on the Job title that has been entered.

  The following gives some simple examples of queries:

  Query example

  Lets look at some more examples of the command syntax for simple queries:

  

  Query syntax example

  And some more advanced examples, working with multi-valued fields:

  

  Multivalued fields

  Arrr.. the memories.

  This approach to database management always appealed to me, and as I mentioned earlier, it just seems to make intuitive sense. It’s also worth remembering that the proponents of such databases always claimed that concepts such as multivalued fields and so on reflected the ‘true state of nature’: people do have more than one phone number or more than one first name and these aren’t separate fields (or detail rows in another table) but genuine multiple instances of the same value in one field. The structure allows you to have a master-detail relationship in the same record, which is incredibly powerful. The concept of fields consisting of derived data, perhaps from entirely different tables, also makes sense to me. As a developer, the notion of having a database which already contains structures that map easily into your class model (which I believe this would) must hold some appeal.

  It’s all rather ironic since I have spent years with relational databases - and I have been happy to do so, since RDBMS has been so successful and reliable.

  So where does this get us? Well, relational won the database war many many years ago and I don’t believe in fighting wars that don’t need to be fought. So is it a rather fruitless debate? Many people would say yes. On the other hand, though, occasionally you do get people questioning relational, and the debate tends to drift on to object oriented databases (yawn) which people have been banging on about for decades - and even more fruitlessly since they have never been used in any large scale commercially. At least Prime INFORMATION, Pick, and all the other variations did make an impact and were widely used - and in a characteristic irony of the computing industry, perhaps they were just around at the wrong time: a time before development tools were good enough to properly harness them.

  If people do fancy a change, I’d like to think people looked around at genuine alternatives based on problems that have already been addressed and products that already exist and build on them, but as is so often the case, I doubt it.

• 09Jan

  Testing is overrated…

  Uncategorized No Comments

  Someone pointed me in the direction of this recent presentation, which gives some very interesting views and insights into how we deal with software defects, it also gives some surprising metrics on the effectiveness of different types of testing, it’s also quite amusing.

  http://www.infoq.com/presentations/francl-testing-overrated

   

   

• 04Jan

  A slice of Cucumber

  Uncategorized No Comments

  I have recently been asked to do some work with the Cucumber framework.   To cut a long story short, this allows you to write automated tests against a User Story (Feature) and it’s associated scenarios.   To get it working, you need to set up Ruby, Watir and the Cucumber framework.  I don’t (yet) want to get too bogged down with the set-up details - mostly because it detracts from the real issues I want to talk about. A description of the set up is here: http://github.com/aslakhellesoy/cucumber/wikis and here: http://wtr.rubyforge.org/rdoc/ although there are many other resources starting to appear (I’ll add links in the future).  

  Once you have the thing set up and working, and written your Features and Scenarios, the cucumber command-line interface allows you to execute the feature and will give you a listing of which Scenarios have yet to be implemented, which ones pass and which ones fail.   The behind-the-scenes implementation is written in Ruby, and simply allows you to map your scenario to the actual implemented system, or whatever is under construction at that point in time.  Those scenarios that are implemented will execute automatically in a browser, and will simulate and reproduce whatever actions you have defined: This starts with the obvious things:  entering values into text boxes and and clicking buttons through to interacting with Javascript and so on.  There are add-ins to work with Firefox, and even to allow you to interact with legacy/terminal applications that might have a telnet-esque client.  All good stuff.   

  At this point I was going to start presenting some examples and actual code, and I probably still will in the future. For now, though, I wanted to concentrate on some general thoughts I have about this approach. Mainly because my involvement is still in it’s early stages and I don’t have a huge amount to present yet.  For another, once you get over the initial euphoria, some nagging concerns emerge about it.  Some recent converations with friends and colleagues would indicate i’m not alone in this.

  I was recently chatting to a couple of people from other companies.  One I used to work with years ago when we were both developers:  He now works as a development manager.  The other I have never worked with, but he works for a company who - believe it or not - only does testing.   I thought that if this wasn’t a good group to get some views from I didn’t know what was.

  Let me be clear about one thing before I get started:  I am a systems analyst and not a tester.  This might be why I put a slightly different perspective on things. Also, It is I said, quite early days - not just in my use of cucumber but for cucumber itself.  So one ought to give things time, perhaps.

  After having a slightly more drawn out converation on this than I had bargained for, we ended up with the following themes:

  • “How do you know your User Stories are correct?”
  • “How do you know your Scenarios are correct?”
  • “Do you have any notion of ‘completeness’ ?   Are you certain that there is not hidden functionality or features that the users are unaware of and didn’t raise?  Is there not a danger of new features coming to light later, simply because you didn’t unearth them?”
  • “Why not get an end-user to do it? They might identify new things?”
  • “Does the test-driven approach give you any additional insight into how your application works?”
  • “How long are people going to spend writing the Ruby implementation?  Is that going to result in a better understanding of the system?”
  • “Is there a danger of people getting emmersed in the implementation of the tests themselves and not thinking about their actual meaning, and how much knowledge they have of what they are testing?”

  These points perhaps go a little beyond testing but nonetheless I was interested they came up as they have been going through my mind for many months. 

  To me, there are two groups of issues here:   The first is the correctness, completeness (or otherwise) of the User Stories and Scenarios themselves.  The second is, to put it bluntly, whether people get so engrossed in the implementation and execution of the tests that they loose track of why they are doing them, what the application is about, and whether they even have sufficient knowledge to begin with.  The analogy I used in the chat - which i’ve used before actually - is that it is rather like writing exam questions for a subject you don’t know very well.   Can you do this, and produce exam questions that are ‘good exam questions’? The answer, worryingly, is yes you can (and I’m pretty sure I’ve read about people doing exactly that). They are ‘good questions’ but you haven’t covered everything, and not covering all the subject runs the risk of creating an air of false success:  As Alexander Pope put it: ‘A little knowledge is a dangerous thing’.

  Another more serious danger is that you create a culture where people are worried about looking into things too closely or uncovering new information because they are concerned about undoing or breaking tests/implementation code that has been previously written.   Slightly like avoiding pulling the refrigerator out because you’re worried about what you’re find and what work you will create.

  I don’t (in this article at least) want to get too engrossed in a debate about User Stories versus Use Cases: But Use Cases do have one advantage if they are done well, in that they do make an attempt at addressing the ‘completeness’ issue, and can tease out some of the less obvious functionality the user didn’t ask for.   I sometimes come up against a slightly scary notion along the lines of ‘if the users didnt ask for it we shouldn’t do it’:  This scares the hell out me to be honest: On most of the applications I’ve worked on the users didn’t request some pretty obvious and fundamental things, so it’s not a principle I personally share. Nonetheless it does crystallise a further potential problem:  If User Stories are as Mike Cohn states, i.e. simply ‘placeholders for a conversation’,  to go from them into scenarios and then into executable tests, seems to me on many projects to be a very simplistic view. In the case of some projects i’ve worked on it borders on fantasy. The problem with Use Cases is of course that there is plenty of opportunity to do them badly - not least because the Use Case descriptions aren’t defined in the UML. The solution is to do them well! But the fact is that none of the artefacts we work with (and User Stories are no exception) are handed down by god:  They can all be wrong or incomplete - we just don’t know it at that point.  If like me you are suspicious of taking a ‘user driven’ view (on the basis that very often the users don’t actually know as much as we’re led to believe: they are just trying to make the best of the systems they got given when they joined), it simply isn’t good enough to take User Stories and drive out tests from that without a layer of systems analysis on top. IT development isn’t a car dealership: The Customer isn’t ‘always right’ - Sorry and all that.  As I said in a previous post here, if you think you can get all the detail you need from a set of User Stories, good luck: I personally think you need more: Not to replace, but to augment and provide a clear statement (to those that need to know - and that might not be the developers [unless they are interested]) of how you got to where you are. No amount of automation can surpass that.

  But It’s early days of course…

• 08Nov

  The kids are alright

  Uncategorized No Comments

  Some time ago I attended a seminar about future trends in new media and broadcasting.  I almost always come away from these things with a mixture of disbelief and mild anger. This is because what is presented is often dubious in the extreme and just doesn’t seem to have much connection to what is really going on.  Enevitably people centre on the notion that traditional ‘broadcast’ media is finished and we’re all living in an on-demand world with everything else in some way null and void.  As I said here The Braodcast ere is finished, there is not the tiniest fragment of evidence to support this: We simply have additional technologies and means of distribution available that people can choose to use or not.  The technology ‘visionaries’ always seem to think in terms of replacement and revolution, and the theory that technological developments result in the wholesale replacement of any other way of doing something.  They can’t seem to grasp the fact that this rarely actually happens. The world of technology does not operate on revolution, it works by giving people choices they can choose to adopt or not as they see fit.  

  One other thing that got wheeled out at this event was the issue of what the kids are doing.  Younger people are not consuming traditional media but going elsewhere for it - Bebo, Myspace, Youtube, LastFM, you name it. They don’t see buying music as ‘cool’ - they prefer to get it free from sharing services - Limewire, BitTorrent and the like.  Traditional media outlets are struggling to connect with this audience.  We’re doomed, the industry landscape is changing, there is a seismic change  etc..

  This is interesting, and there is certainly some truth in it.  The problem I have with this assessment though, is that it always seems to contain the (subliminal, admittedly) message that this is how young people will behave throughout their whole life.  In other words, young people aren’t watching TV so therefore they will never watch TV at any point when they get older. So, by interviewing and analysing what young people are doing we are building up a vision of the future:  We are predicting the habits of the adults of tommorow.

  Researching the habits of young people to predict the future in this way is extremely dangerous in my opinion - quite simply because your views and opinions change. Interview young people today and they might well be glued to Bebo and Myspace (or at least that is what they’ll tell you).  Interview them 5 years later and you’ll get a very different opinion.  Obviously technology will have changed in the interim, but there is no evidence to suggest they won’t come back to TV, Radio, printed media or whatever else.  TV and Radio audiences are actually holding up well at the moment, with TV viewing actually higher in the UK than it was 10 years ago.  Obviously we won’t be back to the era of shows getting 21 million viewers, but (as I have had to remind people on ocassion) those days were over long before broadband.  So what are we to make of that? Beware of ‘Visionaries’ predicting the future, I’d say….

« Previous Entries