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?
O
Category :
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.
O
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.
O
Category :
Recently, I was asked by a colleague:
"How did you learn Lotus Notes?"
I truly didn't know how to respond.
It certainly made me take a collective journey through my 20+ years of
development experience to figure out how I got involved with this thing
called Notes. Here's my story:
The year was 1994 and I was working
at Lotus as a Technical Notes Trainer. I had been training customers on
Notes Version 3 for a while and was looking for an avenue back into development.
An opportunity arose to work at Iris and I jumped on it.
I was part of a small team that was
tasked with making Notes more Internet savvy/aware. The first thing we
built was the Notes NNTP News Server Task. My role on the project
was to create the Notes databases/templates which would be used. While
I was sitting in the same building with the people who wrote the core code,
I was a little intimidated by them, so I chose to learn things on my own.
As anyone who has ever developed a Notes database knows, it's 90%
trial and error and 10% luck. I would occasionally ask a few people questions,
but the response I usually got was "I don't know, it should work that
way. Why don't you try it?"
LotusScript had just been added to the
product, so template developers were charged with finding uses for it.
Overall, it was a dynamic, exciting, frustrating and rewarding experience.
The NNTP News Server probably shipped with Notes 4.x (go ask Barb Mathers
- she would remember better than me). We next built the Web Retriever
for the Notes Client, which essentially made Notes a web browser by using
the ActiveX functionality of IE's Web Browser Control, but saving the pages
in a Notes database. At the same time, another small group from Lotus
was creating a Web Publisher for Notes which was eventually called Domino.
Somewhere in there, IBM bought Lotus and the Lotus Notes Server became
Domino--and I needed a break!
After taking a seven year hiatus from
Notes, I was afraid of being lost within the many enhancements to Notes
in versions 6, 7 and 8. Fortunately for me, it was like riding a bike,
or putting on a comfortable pair of slippers. That's not to say that some
amazing things didn't happen while I was away--I think Eclipse is one of
the best things to happen to Notes in a long time. And, here at Teamstudio,
we are jumping on the Eclipse plug-in bandwagon with a new version of our
flagship design tool, Teamstudio CIAO!, which is context-sensitive within
the Eclipse designer. For a Notes developer to have that kind of integration
is something I thought I'd never see.
With the understanding that Notes is
a dynamic and ever-changing platform, here is my advice to new Notes developers:
1. Forget everything you've learned
about development in other products/ It doesn't apply to Notes!
2. If you're ready to hit your
head against a wall, put it away for a while and wait for an "aha"
moment.
3. If something isn't working
consistently, bring somebody else into your office. It will behave
for them.
4. If you're having trouble with
it, somebody else probably has, too--so Google the problem and you'll likely
find a solution.
5. In order to preserve your
sanity, use Teamstudio CIAO! as your Notes source code control system.
So, to answer my colleague's original
question: I never learned Notes, I just grew up with it.
O
Category :
For those of you who don't know what
deposit bottles are all about, check out this old Seinfeld clip:
http://www.youtube.com/watch?v=TEpDBQ_Ww6k
So how do deposit bottles relate to
change requests? Nobody returns their bottles as soon as they are
done with them, so don't release your changes as soon as you finish them.
But wait--isn't reacting quickly to all change requests the responsive
thing to do? Well, yes... But remember that things are constantly changing.
And nobody likes change, let alone constant change.
And the other extreme? I was returning
my one re-usable bag of bottles the other day and saw someone with several
shopping carts full of bags of bottles. Must have run out of room
under the porch to store more (hopefully it wasn't the result of the weekend's
festivities). That would be a metaphor for storing up change requests
for way too long. You'd be explaining all the changes to your users
for days, just like it will take several days for that guy to put all his
bottles into the return machine.
So what's the right mix, and what do
you do in the meantime? Well, you have to touch that database anyway,
so why don't you leave it better than you found it? Any hard-coded
server names? Recently, I found a formula agent from R3 days. It
had that old
fldName := fldName
stuff all over it. It also checked
to see if it was running on OS/2! A few deletes and a much better
agent. Nobody sees those changes, but you won't have to go back in
there for another 10 years, just because you got a new server.
Maybe you could run a spell check...
Here's a fun one: Search the 8.5.1 client help contents for lotuscript
with one "s." Just sayin' - it can happen to anyone.
How often to release new code? There's
something magical about the number 7, so try releasing seven changes at
a time. And tell them I told you to.
O
Category :
best practices change management
|
|
