Get the most from Notes®

Category Notes Threats
Very interesting post on Ed Brill's blog recently, though I don't think this is as unique to any one platform as Ed wants you to believe. This is just as easy to do in Domino as it is in Google and comes down to the management of security policies.

How many organizations out there are dutifully managing ACLs using groups? If an unknowing admin were to add say, the "Everyone" group to a group that was nested, at some level, inside the "LocalDomainAdmins" group, how long would it take you to discover that? How many apps would be affected? How long had it been since the change was made? My guess is that there are very few people who would have even known that it happened, let alone, what the damage was.

A deep understanding of the contents of ALL (yes I said all) the groups in your address book is incredibly important. However knowing the effect a group has on the access to applications (mail included) is even more important. The problem is being able to quickly learn what the effective access is to your applications at all times. This can be a full time job and very difficult to do on a regular basis. Just knowing that a group was changed is one thing. Knowing what effect that had is what is really important.

Exactly this issue is what led to the creation of Teamstudio's Admin Suite of solutions. If you are having difficulty knowing who changed what and when, who has access (really!) to which applications, you are not alone. Feel free to give us a call, or contact me directly at craig_schumann@teamstudio.com. I would be happy to show you how we can help.

Posted by Craig Schumann At 4:13 PM | Location Beverly, MA USA | Permalink | Comments (3) |      

Category Layoffs
Layoffs are happening all around us. One big problem that management tends to overlook when laying off people is that, especially in Notes shops, the people being laid off are the only ones who can perform certain tasks. What happens when the only person who knows the process for deploying changes to a mission critical application is let go?

In order to stay lean and still be able to respond to changes in business, it is critical that you have automated processes in place that reduce the dependency on specialized knowledge. Consider the following areas when looking at how your application environment is managed:

• What controls the movement of the application from development to production?
• If using contractors, how are you tracking what changes they make to applications?
• Are you sure that all changes are being tracked so the next person can get up to speed quickly?
• How secure is the production environment? Are employees still capable of making changes directly to live applications?
• Do you even know what applications exist or what is being accessed in production? Are you wasting time maintaining under-utilized applications?

There are usually way more places to save money than blindly laying off key employees. (read more)

Posted by Craig Schumann At 9:21 AM | Location Beverly, MA USA | Permalink | Comments (1) |      

Category Delta Design Compare Match

Today's tip comes to us from John Kingsley....

We all know there is never enough time to do something over, but if you ever have had to work on a database and seen something like a form called, 'Copy of..." and wondered what was changed between that form and the original, here is a crazy idea. Compare the database to itself using Teamstudio's Delta!  
(  read more...)

Posted by Craig Schumann At 10:45 AM | Location | Permalink | Comments (0) |      

Category LotusScript Free tools

Finally! A new version of Script Browser is ready! This has a bunch of new things, and it finally fixes the limitation regarding large classes.....
(  read more...)

Posted by Craig Schumann At 11:43 AM | Location | Permalink | Comments (2) |      

Category Best Practices
I stumbled on this article (again) and it got me thinking about how most of us don’t really want to change, we just want change to happen to us because it is too hard to do the actual changing.

A lot of times people will come to us looking for help with issues they are having with implementing development policies for things like rolling apps out into production. They see a demo for Build Manager and think, “WOW! Perfect! Just what we need!". Almost every time they are right, Build Manager would be perfect and could solve quite a few of their problems. The trick is, development policies are more human related, than technology. Tools don’t work if the users are not committed to the practice of using them. It’s not until we go out and start helping them implement Build Manager, or CIAO! or anything else that we (and they) realize that to really get the most (or any) benefit from the tool, there needs to be some fundamental changes to the way they work. Build Manager for example really needs you to think about signer IDs, segregated environments like dev, test, and production, template strategies, etc., before it’s even possible to use it. This wasn’t what the customer was really after though. They were looking for the ‘Best Practices’ pill. Something they could just install and poof – all their problems are gone, the fact that a lot of their problems simply came down to how they operated didn’t occur to them.

Best Practices take work and discipline, tools can help ease the interruption and sometimes even allow you to do things you didn’t think was even possible before. Don’t go looking for a ‘Best Practices’ pill, ‘IT Governance’ pill, or any other type of quick fix like that, rather look for things that can help support a healthy lifestyle, or development practices.

Posted by Craig Schumann At 8:30 AM | Location Beverly, MA USA | Permalink | Comments (0) |      

Category Performance Tips and Tricks Coding Practices Development
Subtle differences….

My fellow Teamstudio-ite John K just posted about GetNth not actually being as bad as it’s reputation. But I noticed something very interesting in the screen shot of the results.



It’s something that everyone can probably encounter because it’s very subtle… The lines that are highlighted are what caught my eye. Each of the blocks of code are doing virtually the exact same thing, and could easily have been seen in the wild as an attempt to optimize that bit of code. After all we all know, and John alluded to this, that views are faster than collections. But as I looked at this I was stumped…. Why was that simple statement costing so much? Then it dawned on me….

(read more)

Posted by Craig Schumann At 11:39 AM | Location Beverly, MA USA | Permalink | Comments (4) |      

Category Source Code Control Coding Practices
CIAO! is one of our most popular products, from a governance and change control perspective it is almost vital, but it is also the one that we hear the most grumbling from customers about. Most often the grumbling is from the fact that it’s perceived as an added step that just makes developing much more painful and time consuming. However, we also hear a lot of feedback about how much people love it and rely on it though. To me, CIAO! (any source control really), is an essential tool for any developer. When I don’t have to check-out/check-in code I feel like I’m doing something wrong. This doesn’t come from being brainwashed (I don’t think… but I guess I’ll never know) but from realizing that the act of checking in does something so much more than just make the form or script library available for the next developer to make a change, but from the fact that at the end of the month, I know exactly what changes were made. From that I get a complete fix list I can send out with my changes that show exactly what was changed in the new version of the template and why the change was made. So without CIAO!, I would be grumbling about that every time I released a new version because that is *way* more painful than the check-out/-in steps. And this is despite the fact that, for most projects, I’m the only one working on the template at the time, so technically, the check-out doesn’t actually matter because I don’t have to worry about someone else making changes at the same time.

So I have two sets of questions and I want completely honest answers. This is true even if you just want to trash the product … though I reserve the right to rebut to anything untrue.

First, for those that don’t like CIAO! (or source control in general)… Why? What is it exactly that is bugging you most?

Second, for those that do like CIAO!, what was it that got you to use the product, and what made you keep using it? Did you seek it out or was it forced upon you? Do you have any advice for others that are trying to implement a source control tool and make it stick?

Posted by Craig Schumann At 2:09 PM | Location Beverly, MA USA | Permalink | Comments (5) |      

Category Build Process Worst Practices

1. Not doing it for the right reasons--If the only reason you are changing your current process is to satisfy management, then you will fail. If you have not realized that you have a problem, then why are you changing? As any addict will say, unless you accept that you have a problem, you will never change.
   
   
2. Not realizing you have a build process--It could be just a single step to prepare the design for production like emailing the template to the admin, or refreshing a database, but regardless of the number of steps, you still have a process. Once you look at it from that perspective, even the simplest process can be made easier, less error prone, or more auditable.
   
   
3. Not simplifying far enough--Before you begin to automate a build process, make sure it still makes sense. Many times people have adopted a routine that was completely relevant in say an R5 environment, but is unnecessary with an R8 environment.
   
   
4. Automating things that happen only once--Only automate processes that happen the exact same way every single time you do them.
   
   
5. Not including everyone in the analysis--There are probably lots of steps that can be included in the build process that you as the developer or admin don’t do yourself. In order to make sure that you don’t miss out on a piece of the process, get everyone involved together and write down everything you do from start to finish.

Posted by Craig Schumann At 3:08 PM | Location Beverly, MA USA | Permalink | Comments (0) |      

Category IT Governance Best Practices ALM
In a follow up to a series of posts I made before:

RAD: The Reason the Domino Development Platform Isn't Taken Seriously?
Notes Developers Making Changes to Production Apps
You Change It, You Own It
What's Your Policy on Changes in Production?

I'm not trying to dig all that up again, but I would like to point out that it's not just the Notes/Domino world that is dealing with these problems. The JAVA world has them too, they just happen to be part of a much bigger world with a lot more support from a much bigger community that includes a lot of academic types. The guys over at our sister company Enerjy Software have a blog (and a really cool static code analyzer for Java - and did I mention it was free?) where they post short interviews with industry experts talking about different topics. In the most recent interview (http://www.enerjy.com/blog/?p=260) Bob Martin, the CEO of Object Mentor is talking about programmer professionalism and overall code quality.

The lesson I get from this is that it's up to us as developers to ensure that things are done right. Sacrificing quality for speed by developing directly in production, for example, is only going to look bad on you and Notes in the long run. It is up to us, as developers, to ensure that the apps we are working on are developed and tested in such a way that the speed that Notes affords us with it's RAD aspects. Don't let RAD be taken advantage of and perverted into an excuse for doing things sloppily and not adopting good practices and policies. There is no reason why Notes should be so disrespected when compared with other development platforms.

Good practices should be more than using GetNextDocument instead of GetNthDocument (which isn't as bad as everyone lets on BTW).

Posted by Craig Schumann At 10:44 AM | Location Beverly, MA USA | Permalink | Comments (2) |      

Category Development
How many people out there actually trust their development environment? I bet there are not that many. When you are going to make a design change how many people go to production and make a design only copy of the app to a different location and make the change there? Why is this the case then? I have seen development organizations that cause more trouble and hassle than they realize when they bring a copy of an application from production into their “development” ( and I use the term loosely) environment, make a change and then copy it back up to production. Why bother? What have you actually accomplished? All you are doing is paying lip service to the ‘no development in production’ policy…

Development should be cleaner and more controlled than production I would say! Who knows what dirty applications you are bringing back from production. Where has that application been, and who has it been hanging out with? As the last developer to touch it are you willing to take responsibility for the egregious bug that lies lurking in there that was put in by some administrator messing around?

Posted by Craig Schumann At 3:54 PM | Location Beverly, MA USA | Permalink | Comments (4) |      

Category Production
How do you ensure that know one is making changes to a production application design? Administrators: Do you even exercise that level of control? IT Managers: Are there policies in place that prohibit development (or anyone else for that matter) from making changes directly in production? Why not? At the very least you should be using the catalog to get the last time the design of an application was changed. If this change does not correspond to a scheduled design upgrade, it should be investigated to find out what the change was and then who made the change. If changes are showing up in production unannounced, they probably didn’t go through testing, and the development team may not even know about it. At the very least development should be prevented from making design changes in production, but I would say that administrators should be as well.

Posted by Craig Schumann At 5:04 PM | Location Beverly, MA USA | Permalink | Comments (4) |      

Category Lotusphere Migration Upgrades
At the 'Ask the Developers' session on Thursday at LotusSphere there was an interesting question asked. How do you make upgrades easier for admins when there have been changes made to a standard template like mail? This is actually a big issue for a lot of organizations, but no one is thinking about it in the right way.

The simple answer is that you don't migrate changes over, at least not directly, you need to re-implement them. Also there are 2 reasons why so many organizations get stuck here. First they are treating this as an admin problem, when it is clearly a development problem. Admins should not be held responsible for ensuring that migrations do not break existing functionality in custom applications, this is a development responsibility. Second, the customized version of the mail template is now no longer an IBM product, but your custom application so you need to start treating it as such. You forked the code base of the mail template to create a new application that, at one point in the past, was based on the standard mail template. Once you do that, you are on your own and, the farther back in time you forked, the harder it is to merge changes. (more)

Posted by Craig Schumann At 1:51 PM | Location Beverly, MA USA | Permalink | Comments (3) |      

Category Migration
Ed Brill has a new post commenting on a white paper from a company that wants to help you modernize your Notes applications. Hey that sounds nice! Count me in, Composite Apps/Portals, Web 2.0, RSS, Web services those all sound great and I could probably come up with some pretty useful solutions to a lot of tricky business requests. There are all sorts benefits I can get by modernizing my Notes applications, it would improve ROI, I'd probably be able to speed up my application deployments, and even minimize my disruption to my user base – all while preserving my original software investments!

But wait a minute… this company wants to convert all my Notes apps to Java or .NET... HUH? How on earth would that help me accomplish any of the things I just mentioned, especially since I already have that functionality in Notes today? Adding a J2EE or .NET infrastructure is not going to help me with any thing relating to ROI, application deployments, or disruption to my user base, let alone preserve my software investments... No thanks, I'll just make what I currently have better by upgrading to Notes 8. (more)

Posted by Craig Schumann At 1:47 PM | Location Beverly, MA USA | Permalink | Comments (6) |      

Category RAD Notes 8
There are a few people talking about things that are really important to me:

Tim Tripcony "Domino Developers Are an Afterthought"

Sanity Check

I've commented on those blogs directly, but I felt I needed to put all my thoughts into one place.

All these threads have 2 basic themes in running throughout the comments: Has IBM ignored the Domino development community? and, Is it time for the Domino developers out there to grow up?

Both of these are coming out of the same conversation because I think we are at a point where, in order to improve, we, as Domino developers have to grow up. To put it simply, we need to examine our practices using Rapid Application Development (RAD). (more)

Posted by Craig Schumann At 10:35 AM | Location Beverly, MA USA | Permalink | Comments (16) |      

Category Testing
Recently I have been doing a lot of thinking about how to improve some of the testing we do here on our internal templates. Like most Notes development shops, we do pretty comprehensive testing, but it is mostly manual and not as structured as it could be. One of the biggest problems we face is just the sheer number of templates we have to test. As of our latest release we have 20 templates that ship with the English language version our tools. We also maintain a Japanese language version of most of those templates, which brings the grand total to 36 templates. (more)

Posted by Craig Schumann At 1:55 PM | Location Beverly, Massachusetts | Permalink | Comments (3) |      

Category Source Code Control Coding Practices Best Practices
There is a common misconception that design locking or check-out is all that a source control system delivers. In reality, checkin/out or locking is only a minor feature and probably not even a necessary one. Preventing someone else from making a change while you have the design element open is a nice feature to have, but in reality how often does this really happen? If the answer is ‘a lot’ then I would argue that your development efforts are not as organized as they could be! What a source control system is really about is providing a robust and automatic way to document all the changes that are happening to an application. (more)

Posted by Craig Schumann At 2:48 PM | Location Beverly, MA USA | Permalink | Comments (0) |      

Category Worst Practices
Why are Lotus Notes developers allowed to make changes design changes to production apps? Why is this even remotely tolerated by IT managers, or administrators? For that matter, why do developers even allow themselves to be taken advantage of like this?

This is an honest question, I don't understand why this sort of unprofessional behavior is tolerated? It's not tolerated in any other technology, so why do Notes shops act this way?

Posted by Craig Schumann At 1:45 PM | Location Beverly, MA | Permalink | Comments (20) |      

Category IT Governance
...for governance that is. Don’t get me wrong, I really like the idea behind composite apps. However, after playing around with the new ND8 feature “Composite Applications” a bit over the last few days, I have come to a disappointing conclusion: I can’t recommend them for any use that would require strict controls.

Maybe it’s just me, but there are two glaring holes in the way they have been implemented. First, when you are using the Composite Application Editor (CAE) you are actually editing a live application. Every time you make a change the app gets saved meaning anyone who is accessing the application at the same time will instantly start using your change. This particular point has been mentioned on the Notes 8 forums over at LDD so I know I’m not the only one who sees this as a problem. Good news is that apparently IBM realizes this is a problem also and has given it a high priority for the next release.

The second problem is that I can’t see any way to test composite apps in a compliant manner. When you create a composite application you have to test two major aspects: the components and the wiring. If these are Notes apps, in order to get them to react when one of the other applications changes states, both applications have to interface with the Notes Property Broker. Since this is a new functionality, you have to modify the applications to add this capability. You can’t just modify apps without documenting those changes and testing them (especially given the newness of these features), so this has to happen in a development environment. (more)

Posted by Craig Schumann At 11:10 AM | Location Beverly, MA USA | Permalink | Comments (9) |      

Category IT Governance
To read the first part of this post, click here.

When an organization has issues with segregation of duties, what needs to happen is that the process itself needs to be treated as the two distinct phases it actually is and the responsibilities assigned to the correct groups/people. First, the template contains changes that are development's responsibility, so they should be in charge of delivering that portion of the process. By setting up a staging area where templates can be copied to give the development staff the ability to completely configure the template as needed. No more changes to the design happen after this point. The second step of updating the appropriate applications should be left up to the administration staff. You could even go further, and possibly give the application owner a say, which gives them the ability to control when the changes are actually implemented. During this implementation phase is when things like the ACL of the application or the agent schedules will be adjusted to match any design changes. ACL and agent schedules are not applicable to the template and have the potential to be quite different across instances of the design anyway. Designing your deployment process in this way also lets you have obvious hand off points where reviews can be conducted. Segregation of duties is not just a matter of locking developers out of production. In fact, it can't be. Rolling out a design change in production needs to be handled by many different groups. However, when you are designing this new process, make sure you are not just shifting all the responsibilities from one group to another.

Posted by Craig Schumann At 10:26 AM | Location Beverly, MA USA | Permalink | Comments (2) |      

Category IT Governance
One of the key tenants of many IT governance initiatives is something called segregation of duties. The basic concept is that there should never be a single person who has control of any single process. In the Notes development world the most common place this shows up is when you want to deploy some new design changes to production applications. There are usually a number of things that have to happen during this process, the most important being to prepare the template, move the template, and then update all the designs for the applications based on that template. In the past, this process is usually handled by development. Development knows what the changes are so they can just apply the changes directly to the applications (assuming they haven't already just been developing in production, which is a completely different problem). Sometimes these changes may go beyond the design and affect the scheduling of agents and what roles different people get in the ACL. Segregation of duties in this case is usually seen as straight forward to implement--developers will not have design or manager rights to those applications in production and the administration staff can do the deployment. However, this just shifts the problem from one group to another. The problem wasn't that the development staff was applying the changes, the problem was that they were in control of the entire process. The risk is that whichever group is doing it, other changes could be made at the same time that were not authorized. You can't just have the administration team do it as they could be doing the same thing.

In the second part of this post, I will talk more about what you should be doing to actually make segregation of duties work. IT Governance for Lotus Notes: Segregation of Duties--Part 2

Posted by Craig Schumann At 10:41 AM | Location Beverly, MA USA | Permalink | Comments (2) |      

Category IT Governance Notes Threats
I think that one of Notes/Domino's greatest strengths in the past is now actually threatening to be the reason for it's end - and probably already has in many development shops. Over time, power users grew into a position they were not properly trained for. They probably didn't see it as their job function or, most likely, didn't know what was even possible or needed when it came to controls and just good development practices. As the value and importance of business applications grew so did the demands of governing them. Applications that may have, at one point, served as the travel expense database for a small part of the company grew into a powerful standard corporate application. At the same time, the processes and policies that governed how they were created and maintained did not keep up. The application was still developed in the same nonchalant way as when it was first deployed to a handful of people. For most companies the business function is important, the technology that it is delivered with is not. An organization is not going to just throw out one technology for another without a good reason. If bad development practices and an impression that Notes is not controllable, manageable, and/or governable are heard too far up the chain or even in the board room, that gives solid leverage to force Notes out. CIO's don't (in a perfect world) care what the underlying platform is that delivers the critical business processes, unless the platform is causing them to fail audits, or otherwise look bad - after that Notes is out and something else (probably with just as many, but slightly different, issues) is in.

Posted by Craig Schumann At 12:00 AM | Location Beverly, MA USA | Permalink | Comments (5) |