Get the most from Notes®

Category

I was in a shop the other day and overheard a conversation between a young boy and his mother. The boy, about five years old, was after the latest 'Dr Who' comic (a spin-off publication from a popular and long-running BBC sci-fi series). What caught my attention was the boy saying, '... but mummy, I really, really need this!' To which his mother replied:  'No, you really, really wantit – there's a difference'.

Now, I am not sure if this distinction was not completely lost on the boy - at five years old I am fairly certain that I thought want and need were the same thing – but it did set me thinking about how much I still confuse the two in my adult life.

For example, I am about to replace my car. What I need is something that will get me from home to office and back, with the occasional long distance journey (which means over 50 miles in the UK) in reasonable comfort and at relatively low-cost. What I want, in addition to the obvious, is sat-nav, iPod connection, air-con, leather seats, decent acceleration and preferably something that will express the success and charisma of a movie-star (in my dreams!).

My needs would easily be met by any decent hatchback: a Ford Fiesta or VW Golf, for example. Does that stop me going for something considerably more expensive? In a word, no.

Nowhere is this lack of distinction between want and need more apparent than in the realm of software requirement specification. Look at the software you use from day to day, particularly the bespoke stuff, and ask yourself, 'How much of the functionality do I need to do my job? How much of the functionality makes me more efficient, prevents unnecessary work, or eases communication with colleagues?'

Then, turn the question around. How much is just there because it could be done? Because someone thought it might be useful? Because it was just 'cool' to program? Worst of all, and perniciously subtle, how much of the functionality actually increases the workload without generating any real business benefit? For example, the ability to generate a complex report with lots of detailed data and graphs, when the recipients are only ever going to read the executive summary.

When specifying requirements for software, rule number one is unless this feature or feature set actively supports a significant business need it should be dropped or at least heavily de-prioritised. Particularly in these lean economic times, keep in mind that implementation of any functionality costs time and money, and 'cool' features often do nothing for, and sometimes actively detract from, user productivity.

Posted by Matthew Fyleman At 9:03 AM | Location | Permalink | Comments (2) |      

Category Notes Threats
I was reading Scott’s post here and its associated thread (Notes New Threat – Salesforce.com with Google), and it got me thinking. I agree with the general view from the thread that actually there is not much of a threat from Salesforce.com and Google, largely because the costs associated with moving to this (unproven) platform would be prohibitive.

However, that is not to say that there are no threats to Domino’s long term future, and it seems to me that the biggest one is resourcing. Here in the UK at least, it is getting harder and harder to find experienced administrators and developers for Domino. I suspect that this is mostly down to new blood coming into the software industry being far more interested with what is perceived to be the cutting edge (Java, .NET, Web 2.0, etc). I say ‘perceived’ because we all know that Domino can provide a robust platform on which to build this stuff, but I think the prospect of using formula language and LotusScript strikes a lot of potential Domino professionals as a step backwards on the career development scale.

(read more)

Posted by Matthew Fyleman At 7:59 AM | Location Huntingdon, UK | Permalink | Comments (6) |      

Category ALM
Recently, I have been involved in a fair amount of what we call asset analysis work, that is, analysing a large number of Notes databases/templates for a company to highlight potential issues associated with upgrading Notes, consolidating servers etc. While you can easily analyse 500 or more databases for the relevant issues in a short space of time, it will always take much longer to remediate and test the issues that really need it. This inevitably means that the customer’s ability to prioritise the discovered issues becomes critical.

It is here that the customer usually gets stuck, with them often being forced to arbitrarily assign priority because they have no data on which to do it properly.

We can offer our customers an audit that helps them to prioritise on the basis of application usage but wouldn’t it be great if this kind of information was readily to hand? ITIL (amongst others) has the concept of an asset catalogue, which captures information about assets including owner, purpose, current version and so on. What about a Notes application that allows you to capture this information, but at the same time continuously monitors database size and would be capable of rolling a database over when it reaches a certain trigger? One that could monitor relevant usage (while ignoring the system related/housekeeping stuff), resetting to zero at the end of each day/week/month but keeping a history for trend analysis. One that could note replication settings for a database, could monitor replication traffic and flag when replication fails? In other words a proper application lifecycle management tool.

Now, I know the database catalogue can do some of the above, but it is way too limited a tool for what I have in mind. Do you think such a tool is something that IBM should provide out of the box with Notes, or would it be a waste of space, or too much hassle to maintain? If you think this would be useful, what other features would you like to see? What do you think?

Posted by Matthew Fyleman At 5:05 PM | Location Huntingdon, UK | Permalink | Comments (0) |      

Category DNUG
Well, I'm at the airport waiting for my flight home, and reflecting on a quiet Deutche Notes User Group (DNUG) conference. I say quiet, but it was a thoughtful quiet rather than a morose one. Everyone seemed to be digesting the news and previews of the upcoming Notes releases. Of course 8.0.2 was interesting, but it was the demonstration of the 8.5 eclipse-based designer client that got people thinking. There was a short spell of concern when the presenter demonstrating it seemed to suggest that there would be no support for LotusScript editing in the eclipse based designer as the developers did not have time to include one! This statement was clarified soon after however - what she meant was that, unlike the other script editing, they did not have time to switch the LotusScript editing to the native eclipse editor, so 8.5 will call on the existing designer client editor packaged to run in the eclipse environment.

What seemed to get everyone thinking though was that the capabilities of an eclipse based Notes client, hinted at in the 8.0x client, are now becoming readily apparent in the 8.5 world. However, this also highlights the increased complexity of application development in that environment, and this in turn means that the more easy-going Notes development practices of the past will no longer cut it in the future. Creating scalable, maintainable and robust applications in the future is going to require much more developer discipline. It seems Notes is finally entering the real-world as far as controlled application development goes!

Exciting times.

Posted by Matthew Fyleman At 2:44 PM | Location Bremen, Germany | Permalink | Comments (0) |      

Category Design Application Development Best Practices
I have been writing quite a lot of documentation lately, and to be honest, I hate it. It is tedious, time consuming and I have a suspicion that no one will read it, so what is the point? I am sure there are developers out there who enjoy documenting their designs, but I suspect that they are rarer than hen’s teeth.

All this said, I know from experience that there are significant benefits to having documented designs. For example, I can cite situations where having a documented design before I cut code saved time because the design had been proved ‘on paper’, where other teams on the project had to go through several revisions to get to the same point with their code.

So what is your experience? Have you had situations where design documentation was useful? Or do you feel that it is always a waste of time?

I am also interested in what tools or methodologies people use for their Domino designs. Anyone use UML? Does anyone remember the Lotus AVM?

Oh well, back to the documentation. Hang on a minute though, I think those pencils need sharpening…

Posted by Matthew Fyleman At 10:25 AM | Location Huntingdon, UK | Permalink | Comments (1) |      

Category Source Code Control Version Management Coding Practices
In my last post, "The Undisciplined Notes Developer," I wrote about discipline in Lotus Notes development. One area where such discipline is vital is around source code control and version management. It is essential that Lotus application developers should have a process for managing both. Why? Well, the main reason as I see it is that it gives you control of which design is where. To me this is the most important feature of version management, knowing precisely which version of your application is in test and more importantly which is in production.

It is also very easy to achieve. At a basic level, every time the design leaves the Notes development environment you can just take a copy of your design, label it (often with a number, but any unique identifier will work), and place it in a safe place where nobody can modify it. Then if you prohibit designer access outside the developer environment you have achieved control. (more)

Posted by Matthew Fyleman At 2:45 PM | Location Huntingdon, UK | Permalink | Comments (1) |      

Category Best Practices Worst Practices
For my first post I would like to draw your attention to this article by Jeff Atwood.

This references Scott Koon's blog entry on developer discipline. I basically want to echo the sentiments expressed, and say that nowhere is this more relevant than in the Notes/Domino development world. I would argue that Notes developers have always had a tendency to a lack of discipline, largely because the way Notes itself grew up permitting, or what some would say encouraging, a do-as-you-please approach.

But what do I mean by discipline in this context? Well, I think it is fairly well summed up as "spending the time and effort to do things in an orderly way in accordance with best-practice." This means in each project actually planning for, and doing, requirements gathering and evaluation, design, and testing. It means having in place and using a robust change management process, source code control, version management and release cycles. It means having and enforcing coding and documentation standards.

Now you may say that your timescales are always so tight you can't do all of this. I say that not to do this is always a false economy.

Posted by Matthew Fyleman At 10:31 AM | Location Beverly, MA USA | Permalink | Comments (7) |