Quick Update from this Defunct Blog

Just in case anyone still has me in their RSS readers, a quick FYI:

We just hit a nice milestone. We have under 100 apps left in our Notes Environment.
As of right now, there are 99 apps remaining.

99 apps in our Notes Environment, 99 apps in Notes… Shut one down, archive it down…

IBM did come in and meet with us, trying to show us all the benefits of sticking with Notes, and all the new features in 8.5. Sadly, they missed the point. They showed us all the great new dev tools (xpages, udpated designer, etc), but nothing that would improve our business. It felt more like they were trying to recruit me into being their evangelist than actually listening to our needs.

Then, in regards to the migration, they said, “We are not aware of ANYONE that has actually shut down their Notes environment.”

Well, that just sounds like a gauntlet being laid down. I doubled my efforts to shut the thing down. And we now have plans in place for all of our major apps. Those plans will take time to realize due to the economy, but we have an answer for every remaining app.

This system WILL go down.  In Yo Face, IBM!

I’m Done – Behemoth Post / Explanation / Conclusions

Before I left on my vacation two weeks ago, I was starting to get more inspired about doing more with this blog. I joined twitter, I starting putting together technical content to post…
But  I was also getting tired of SharePoint, as previous posts show. I wanted to take my week offline and see if that refreshed me.

It did the opposite. I’m less inspired by SharePoint than I ever was.

So this blog is complete. I think there is enough material here that it has served it purpose. It really doesn’t add anything to my personal or professional life, so here is one big final post to close things out. I have heard from some people recently regarding my Domino work… I’ll get back in touch with you folk via email when the time is right. Not that you will know it is me.

Was/Is SharePoint a success?

Partially. We had many issues when we first rolled out our portals. The Server farms were badly implemented, the UI designs were horrid, they were thrown together badly incurring massive technical debt, and massive maintenance costs. That is where I came in. Since then, we have restructured the farm, and while that effort still has many tasks before complete, we are stable with a plan to get to our ideal infrastructure within the next 6 months. We have refactored the UI designs, and their tehcnical implementation, leaving the content publishers with as much flexibility and power as any content management system. Our collaboration areas have grown, and our management of them has evolved, so we are in good shape for oganizational collaboration.

However, the pains at the beginning mean that adoption of the technology was below expectations. Some groups gain much benefit from SharePoint, others ignore it or are downright annoyed by it. It was not the business-changing technology that was hoped for, nor did it save costs.

What would I do differently if I could go back and start from scratch.

1) Don’t use SharePoint. Sorry, but the cost of implementation and support is high, and I think even a perfect implementation would offer a poor ROI. But ignoring that…

2) Don’t skimp on technical planning. Think very carefully about long-term maintenance of the platform, and dig deep when analyzing the impacts of your decisions. Make every manager do a google search on “technical debt”, and spend at least 30 minutes following the results.

3) Don’t hire consultants — at least, not when we did, when MOSS 2007 was so new. At the time of our launch, nobody was a MOSS 2007 expert. So why pay consultant rates for people who basically are using us to learn a new technology, and then just writing .NET code anyway. Instead, hire some really good, sharp people internally, and let them run with it.

4) Don’t fall behind on patches. Ever. Microsoft knows that SharePoint has issues, and actively tries to fix them. If you are going to marry yourself to Microsoft, make it a production relationship, getting their latest patches and fixes, and keeping in communication with them for support and to know their plans.

5) Train your users. Repeatedly. Record the trainings. Make them available online. The more powerful your users are, the more time the IT staff can spend on the platform itself, or on custom code. But that power needs to come with knowledge and insights that only training, experience, and a solid support staff can provide. Put in the effort to give your community those things…

6) Do not accept mediocrity in your IT staff. We all know that the corporate world has more than its share of mediocre IT staff. There are reasons for this, and it isn’t a bad thing in many cases — Not everyone can be a superstar, and much of corporate IT doesn’t need superstars. But SharePoint does. At least as of today – I have hopes that in 3-5 years, the platform will mature into something more friendly, stable, and robust. But for now, it is plagued with problems. Any IT staff member can handle these problems in the short term. But it takes top talent to do so quickly, repeatedly, and often, for months and years on end without running into morale issues. Running a SharePoint implementation is the 100-mile run of IT. Sure, it can be done. But the people who can do it well are freaking machines, not your average IT guy. Get those people on board Day 1 if you want SharePoint to truly improve your business.

7) Code Reviews and Architecture reviews. Do them. Mistakes in design become nightmares in support. Trust No One.

So where does our Notes Migration Stand?

Over the last 18 months, I reduced our Lotus Notes environment from 6000 applications to just over 150. 35 of those are group mailboxes that are in the process of moving to Exchange. 50 of those are basic logs of what happens in our business — the SharePoint replacement is in a pilot program, and they should be gone in a matter of weeks. 50 more  are minor apps, and would only take about 3-6 months to move, but we put that effort on hold due to the recession and its impact on our business. Our 5-10 major, massive apps are slated to be replaced by 3rd party products. Again, plans are in place, but the recession has those projects on hold.

In short, we expect to have moderate usage of around 50-65 apps for 2009, with everything else being shut off with a resonable amount of effort in 2010 or 2011, depending on just how long this recession lasts.

The migration wasn’t rocket science. A lot of it was just being willing to dig in and do the work. It does require an understanding of the business, the usage of the existing platform. It also takes effective communication and negotiation skills. A consultant would not succeed by wlaking in the door, getting specs, and making plans nearly as well as a long-time business analyst who understands not only what goes on, but why. The migration requires less technical skill, and more business comprehension.

Recession?

Honestly, without the recession, I’d probably keep going with the blog, the migration, and probably enjoy it more. But being shut down into a maintenance-only mode means that there won’t be much to share anyway. Time to move my personal efforts into other projects…

SharePoint  Conclusions

1) If you are already a solid Microsoft shop… sure, go for SharePoint. You probably have the talent to make it work. If not, don’t move to a Microsoft-based platform just for SharePoint. There are other alternatives that will serve you better.

2) Don’t buy into the marketing. SharePoint is an effective collaboration tool. But nothing more. Use its strengths, but don’t expect it to transform your business in any way.

3) Everyone should revisit their stance on SharePoint in 3-5 years. Us Notes folk benefitted from the early leadership of Ray Ozzie. I believe SharePoint will, too. If you already run it, look for future enhancements. If you choose not to run it, don’t let today’s SharePoint deter you from the SharePoint of tomorrow. I think it may come together.

Lotus Notes Conclusions

If you’ve got a Notes/Domino platform running, stick with it. If you don’t like it for some reason, fix the problems with your implementation of Notes. Don’t throw it out, expecting a new platform to be better.

Personal Conclusions

1) SharePoint isn’t fun.

2) SharePoint pays well. You earn every penny. Don’t go into it for the money. Be a fan of the Microsoft Kool-Aid or it will slowly inceinerate you from the inside out.

3) The breadth of my IT experience serves me very well. I’ve been a programmer, and analyst, a trainer, a helpdesk grunt, a server admin, a technical writer, a web designer, and a manager. I have used every single thing that I learned in all of those disciplines over the last 18 months.

5) I have learned SharePoint. I have a solid bullet point on my resume and in my skill set. I don’t really care. Kinda like my Notes admin skills — sure, I can do the job, but I’ll likely never apply for that job. The SharePoint work has done well for my resume, salary, job stability, and all those things that I really should care about. But I’m a programmer at heart – none of that means much to me when the platform itself is dreary. Don’t get me wrong — I fully appreciate being blessed with a stable job at this point in time.But inspiring, it is not.

6) The past 18 months have been frustrating and educational, but with moments of great satisfaction when we finally do get things running the way we want.

7) In short, I’m getting too old for this crap.

Nevertheless, the closure of this blog changes nothing for me personally. I have the same job, the same roles, and the migration and SharePoint work will continue in my day-to-day life.

Final Words…

I intend to leave this blog up, as it does get search traffic, and I hope my old content can help some people out.
The gmail address is forwarding to my personal address. If anyone has reason to get in touch, feel free… I’ll be reachable in that way for the foreseeable future.

Thanks for reading and participating in the blog…

jQuery Performance: Problem & Solution

One of my current tasks is to refactor our SharePoint portal’s design.

The original design was done with heavily laden with tables and large images.And each new subsite had its own master page, style sheet, and images directory. It was performing poorly in the browsers, and making it painful to create new subsites.

So I’m making a CSS-based version, removing all the images, simplifying the design while improving performance and flexibility.

The end result was much faster, but the look was too simple. It needed just a little something to give the design some depth.

And that is where jQuery came in — I picked up a Drop Shadow plug-in, and put some shadows around the main page elements. It was just enough to make the page look pretty decent.

BUT — performance degraded exponentially every time I worked with web parts. I haven’t determined exactly where or why, but I do know that somehow the jQuery calls combined with what SharePoint does to a web part page in edit mode was very unhappy. As-in, browsers hang and crashes almost every time I worked with a page.

So, I turned off the jQuery when a web part page is in edit mode by just popping the following into the code:

if ($(”.ms-WPAddButton”).length == 0){
…Do the jQuery Stuff…
}

In other words, I use jQuery to look for the ‘Add a Web Part’ buttons. If they are not found, I continue with the script. Editable pages have the simple interface, and run quickly. Normal content pages have the nicer interface… and still run quickly.

There may be a better way to handle this, but it has worked for me so far.

Startup project on the side

I don’t think I’ve mentioned it before, but I’m writing a project on the side, using Domino as the platform.

I just got an initial prototype done, and am thinking about what I would need to launch it into production. The biggest cost is going to be a new Domino license for a production server. I went through the exercise about 2 years ago of trying to buy a Domino license when I’m just a random guy working out of his home. No business partners in town returned my calls. I submitted a request to buy a license on ibm.com. After 4 weeks, I got a phone call from someone at IBM who didn’t know what product I was talking about. They referred me to a business partner who ultimately did send me a quote,but it was higher than the advertised costs on ibm.com, and they seemed annoyed by my desire to purchase software.

I never did buy the license. The product I was looking at launching got delayed, and then we never picked it back up.

So — now that I am contemplating going through this exercise again some time in the next 3-6 months…

Does anyone out there have a hosting option that includes the licensing in the monthly cost? If not, how about a business partner who can give me a good deal? Or even an IBM person who can do so?
(Or even Ed, or someone in his organization — I think free licenses for startups would be a great marketing move. We pay if we become profitable, naturally, but it would remove a barrier to using Domino as a startup platform if we could do so without financial risk. Say a 6 or 12 month license to be come profitable and pay or stop using the server? )

The other topic I’m thinking about is backup / DR / etc.

And I thought I’d go see what it would cost were I to use Amazon S3 as a backup solution. Ignoring the time and effort to write the backup system itself… I estimate each user of my system will have an average of no more than 5 MB of data.

Which means 100 users, with a full nightly backup, would cost me a grand total of… $1.68 per month.

Now, I don’t know if any Domino hosting services out there offer free backup… but assuming that I need to pay something, this is looking like a very cost-effective option.

Does anyone out there have any experience trying to do a small startup project on the Domino platform that could offer any additional insights into these infrastructure-type issues?

Notes Dev Hall of Shame #2

The main topic for today is user-configurable data.

It is true that hard-coding data is bad. The values in various drop-down lists, etc, would ideally be populated from data that the business owners can update.

But somehow, the idea of “hard-coding is bad” got misunderstood. One former developer obviously missed the point… that the idea was to not require code changes when data changed.

So we have a database full of hundreds of configuration documents. When you put these documents into edit mode, a big red warning pops up. “Do NOT change these documents without checking with Notes Development staff — code changes will be required!!”

Ehh… what??

So I look at the code. While it is true that these documents populate drop-down lists, the agents that then process documents are full of hard-coded business logic…

“If docmuent.FieldA(0) = “Data from config doc” Then…”

So if the data changes, the agents all break. So not only does any data change require a code change, but we are actually inviting the business to break things, and doing so in a way we need to debug code instead of just updating a field.

And this is done all through the entire Notes platform. To the point that the business community here think that these kinds of configuration documents are a built-in feature of Notes, and all Notes apps will always work this way.

In an environment like this, is it any wonder that people think Notes is a hopeless platform? I have a strong suspicion that if the Notes system had been well built from the start, SharePoint would never even have been a consideration here.

Road map for functions in the SharePoint World

When people say “SharePoint”, they usually mean any application accessed through a SharePoint portal. In truth, this may actually be SharePoint, but could also mean .NET or InfoPath applications.

One of the challenges we’ve had is defining which types of applications really are a SharePoint app vs. InfoPath vs. .NET.

But before I go there… why does it matter?

It matters in our organization because of the various roles certain individuals play. Power users and business analysts can do some of their own work… if it is truly pure SharePoint. We’re finding that Domino developers pick up InfoPath so well, they can do more with it than many Microsoft experts. (Which is a blog topic in and of itself, but in short, we’ve spent years working with form-based platforms… we know what to do with, for example, Conditional Formatting (Hide-Whens) to simplify forms instead of making new forms and views for minor UI differences.) And… .NET — while our team can certainly write the code, it brings on whole new levels of deployment and maintenance issues. So we try to avoid it.

Which brings us to the “Road Map”. Which is not very profound… it is a very simple thought exercise for any application function that we are asked to provide:

1) Can SharePoint do it? Then make it so.

2) Well, then, can InfoPath do it? Then make it so.

3) Well, then, we’ll have to write .NET code.

After some discussions, we also added a question 0:

Does this even need server-side code? If JavaScript in the browser can do it, don’t get too clever with SharePoint… just write the script.

We had to add this question because developers who have never really been web-focused are forgetting that SharePoint ultimately renders in a web browser. Throwing some script in a master page or even in a content editor web part is sometimes a very quick, easy solution to some problems.

Our most recent example of this was a ‘Contact Us’ link. It was supposed to be available on all pages, provide an infopath form, then return the user to their original page on submit. They first wrote .NET code to do this. I talked them into just using a SharePoint list. Then they were doing some crazy SharePoint CAML stuff to make it happen. I talked them into just using JavaScript to append ‘&Source=originalpageURL’ to the HTML link.

I use this as an example to illustrate the eternal point of KISS — if 1 line of JavaScript code does the trick, don’t go writing .NET features. Find the simplest solution.

Code Quality vs. Platform Quality

If you’ve read the previous post, you know that the code quality at my current job is… questionable. Not all of it, to be sure. There is some good work. But… one bad app spoils the bunch, so to speak.

That form that took 10 minutes to open? It made people believe that Notes was a poor platform,that could not perform well… that the Client was a horrible piece of work, and that the whole platform, in short, sucks.

I’ve tried to explain to many people that any given Notes system is only as good as the people working on it. People do not judge, for example, the PHP language based on how well people use it. (Which is ironic, because as a platform, PHP is actually quite poor…)

So why do they judge Notes based on the implementation?

And yet, when SharePoint goes badly, how do the same people manage to blame the implementation, not the platform. (And yet still re-hire the consultants who screwed it up in the first place…)

Somehow, there is a marketing issue ’round these parts.

Just a few more outrageous examples of what people do not judge…

“The Pinto was a horrible car, so all cars must suck.”
“Titanic was a horrible movie, so I’ll never watch another  movie again.”
“Terry Goodkind is a violent, misogynistic writer, so I’ll never read any books again.”

See? Wouldn’t those statements be absurd? Then why is it so hard for people to grasp the concept that a platform may still be good, even if the current implementation is not?

Notes Dev Hall of Shame – #1

I’ll pull actual code samples for later installments of our Hall of Shame, but first I simply wanted to share a few choice items that have not only boggled our minds, but also caused endless amounts of helpdesk tickets.

1) The EmployeeID field in names.nsf

At first glance, it almost looks reasonable. They added a field to the person document, labelled “Employee ID”, called EmployeeID, and updated nightly from our HR system. All applications look to this field when they need to get user data, as it is the common data point between every platform in our enterprise.

Or is it??

As we started to get all kinds of calls that applications were breaking, we found that about 20% of the applications read this field. The other 80% read ‘EmplID’. Also in the person doc. NOT displayed in the UI. Nor was there and agent to set it.
Our old admin team set this field manually when they created new users, using agent local to their system. Only when we switched to a new admin team did the problem crop up.The new admin team was already setting the visible field, and we ended up hacking together a little agent to keep both EmployeeID fields in sync.

2) The Action bar of Doom and Despair

Let’s ignore for one second that this action bar has 125 actions, and all of them are the same code, copied and pasted with minor modifications.

Let’s even ignore that any given user only will see 2-3 of these actions, based on their role within the system, so there may have been a simpler way to do these functions.

Lets just focus on the hide-whens. The hide-whens that repeat the same DBLookup 5 times in each formula. Repeated across 125 actions. With some actions having 15-20 DBLookups, instead of the paltry 5.

Do the math — I counted 724 @DBLookups in this action bar just to determine which actions should display.

People wouldn’t even open the form. When I took this job, I was told that it takes 10 minutes to open that form, so they installed a Citrix system… because via Citrix, it is much faster. Really, is that the answer to an application coded so badly that it is unusable? To install Citrix to avoid the network bottleneck?

I rewrote all the code into a single function, wrote an agent that does all the lookups in a batch process each night, and sets your personal access in a profile document. One lookup to the profile document to know which actions to display. One set of actions with dynamic labels and a function call. I was left with 10 actions, 1 function, 1 agent, and 1 lookup. And the form now opens in 3 seconds.

Bad News from Work…

I got bad news today at work… No, not a layoff.

But the economy has shut down some projects, as I may have mentioned before. Specifically, it shut down projects there were intended to replace my largest, most complex Notes apps. These two apps are the ones that will make or break this migration, as they are used across the entire company, and too complex to migrate without significant custom development on a new system.

They also are no fun to maintain. I commented on Twitter that I should start a Notes Dev Hall of  Shame, and almost all the code I am thinking of comes from these two apps. My mind reels at some of the crud I am finding. Oddly, they are not all bad. One app does have some really good code in it. But it has been shuffled from developer to developer over 12 years, and the last good developer looks to have been around 6 years ago. Admittedly, that guy was awesome. His code is good, readable, and his comments not only tell me what is going on, but make me laugh, too. The guy had a great sense of humor. Sadly, his code is sparse in the app at this point.

In any case, the migration suddenly looks less likely to be completed in less than 3-5 years now, even if I do everything but these two very quickly. My job is looking to turn into a stagnant Notes development job, working on an old version, maintaining old apps, with nothing new on the horizon…

Well, nothing new other than SharePoint. I’m sure it will not come as a shock that theSharePoint work doesn’t excite me.

But when I was hired, I thought I was walking into a great team, with good code, and a company that was going to put some resources behind moving to a new platform, and gaining new skillsets to help expand my career options. Now that I know that, well, none of the above is true, it is becoming more and more difficult to stay positive about this job.

I do recognize that many people, including some excellent folk in the Notes community, are seeking jobs, so I am thankful to have a stable job.

But long-time readers of this blog will recognize that my tone just can’t stay positive. I’m craving a real development job, not sitting in a cube farm doing maintenance work on a platform going nowhere. Especially when I know that both Lotus and Microsoft offer directions for the apps…. but we aren’t choosing either path. We’re sitting. And sitting. And taking tech support calls. And fixing some bugs. And sitting.

I’m thinking I may have to look for new work, but recognizing that the odds of actually finding any are slim at this point in time.

But to combat this negative lethargy, I believe that I will start sharing some of the crud I’m finding very soon. I decided that I don’t have the time to create a separate site for it, but I’ll create a new category on here. This may change the overall theme of the blog a bit, but with the migration slowing down, there isn’t going to be a whole lot to share anyway over the course of 2009…

Philosophy on Tools

I’m always very resistant to buying tools for development work, and that is part of the reason that I have not pursued any tools for this migration. The other reason being that, while we are migrating away from Notes, it is intended to be a slow attrition, not an active push to get rid of the platform, so we don’t exactly have a budget to make it happen. We’re just doing what we can with our own internal resources.

In any case, I dislike most tools for two major reasons:

1) They don’t really do anything that a good developer could not have done on their own:

…I don’t like buying a tool when I could write it myself in under a couple hundred hours.  The migration tools that I’ve seen tend to fall in this category. They are slick, and work for many people… but if I can write an ugly simple script that does the same thing exactly as I need it to… why pay money for the fancy version, when I don’t need its functions? It actually make me somewhat angry when another team member recommends we spend thousands of dollars on something I could do myself. My “Developer” personality comes out, and I feel that I am not valued by the team. Tools like this are not only a waste of money, but insulting as well.

2) They tie you to the vendor and/or product:

…SharePoint itself falls in this category, but I’ve already expressed that I do SharePoint as my job, not my passion. One of the biggest roadblocks in getting off of Notes right now is to disconnect ourselves from some of the 3rd party tools that have been put in place in our environment. Some tools are made not to solve a one-time problem, but to fundamentally change how you create your applications, with the tools now embedded in your platform. So it becomes very difficult to stop using a vendor. I have worked in product-based companies, and the leadership was always very exited when we could write features that made the products “sticky” within the customer’s environment. While that is great for the vendor, it is not good for the customer.

These two points alone make me shy away from most toolkits I’ve seen.

But not all — there are great tools in this world. When I find them, I love them. Or sometimes, a tool will still break my first rule from above, but only cost a couple hundred dollars, so it is still worth the money.

I have not had time to deeply investigate all the tools available in the SP/Lotus world. I suspect some tools do fit my criteria as being worthwhile, but I don’t yet know which. If anyone does have any recommendations for tools that are worth their cost, please share in the comments…