Category
0
A customer recently asked me that question
were waiting for his Notes client to finish crashing and restarting. His
favorite was 6.5.8.
For me, the correct answer is: All of
them! I don't know if I could name my favorite, but I do know the
release I couldn't wait to get - Release 3. To me, this release greatly
expanded the automation of applications over what was possible in Release
2. Release 2 seemed like discussion databases with notifications
(think Sharepoint without the security or offline operation, only 18 years
earlier).
How about you? What was your favorite
release?
Category
0
On the VERY rare occasion that I have
free time, I like woodworking as a hobby.
I started as a kid working with
my dad, and have loved it ever since.
There is just something about
that feeling you get when you complete a project (and, yes, there are other
types of projects that can give you that feeling, too!)--especially when
it comes out better then you expected.
When I bought my house, I built
a 16 foot by 20 foot shed/workshop, so I could really explore my hobby.
I have done many small projects for my house, and my kids. I've also finished
off part of my basement and built a window seat with storage underneath,
plus two closets. My list of upcoming projects includes a tree house for
my boys, a computer desk that is actually useful for my home, screening
in part of the deck, (bugs in New England are terrible), a large patio
for my back yard, and many more.
I want to buy a wood lathe to try
my skill at wood turning. That would really expand my skills and the level
of my work. (I just need to talk the wife into it).
I could make pens, bowls, cool
table legs, etc... A guy can dream, can't he?
After a day of playing with my
tools all the stress of the world has melted away. What about you? What
do you do to unwind at the end of a long day?
Category
0
One of the first things I did when
I arrived at Teamstudio
more than 3 years ago was to look at our product portfolio to determine
where there might be new product opportunities. Testing was one area that
jumped out at me. It seemed to me that Lotus Notes did not offer much in
the way of testing tools, which made this seem like a nice opportunity
for Teamstudio. Furthermore, very little is available
from anyone in the Lotus Notes space specifically targeting testing.
Before I had a chance to pursue
new product opportunities, I was asked to lead a project to develop a series
of best practices across the application development life cycle specifically
targeted at Lotus Notes. This took several months to complete, but we got
a great set of policy guides
and implementation guides
out of the effort as well as a book on IT Governance
for Lotus Notes.
The policy guides proved to be
quite popular among Lotus Notes Developers and Administrators. I had a
great number of conversations with those who downloaded the policy guides
about how they were performing various tasks, especially around testing.
I heard everything from “we don’t do testing” to “we develop in production
… that’s what the users are for”.
I quickly learned that the popularity
of the policy guides did not necessarily translate to a good product opportunity.
Testing within the Lotus Notes community seems to be at best, an informal
phase in the development life cycle. I know a lot of Lotus Notes Administrators
and a lot more Lotus Notes Developers. But I am yet to meet anyone with
the title of Lotus Notes Tester.
Regardless of the formality of
the processes used, one area of testing that is done regularly is that
of User Acceptance Testing. Even when development is done in the production
environment (OUCH!), the users usually get a crack at running through the
application before it is “officially” released to the masses.
Depending on the size and scope
of the release, different aspects of the system should be tested. For example,
a limited release may only require testing of new functionality while a
new system will require complete testing.
Remember, the purpose of user acceptance
testing is more than getting one of your users to say “looks good to me”.
Instead, you should be working to ensure that the application is compliant
with business rules, meets the users’ expectations and performs as expected
in the actual business environment.
User acceptance testing should
include various aspects of the system including:
- Functionality: Application
perform the business functions as specified
- Completeness: All necessary
information to perform a business process or user transaction is present
- Accuracy: Correct content
from the user’s point of view
- Usable Results: Information
returned after an operation, reports generated, etc., including layout
and content are in a usable format for the user
- Documented: Accuracy, usefulness
and usability of user documentation and procedures should be provided to
the user
- Procedures: Release, installation
and configuration management process should be in place to support the
application
This is an area that is subject
to scope creep. Be careful! Sometimes there is a fine line between “what
the system must do” and “what would be nice to do”. When in doubt, you
can always go back to the requirements documents. At least I hope you can.
But documenting requirements is
a subject for another day.
Category
0
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.
