Selling XPages - what matters?

April 4 2014

The XPages community has had an active two weeks of discussions, kicked off by my coworker Mark Roden's post Why learning JavaScript is more critical to XPage developers than Java. This inspired many comments and other posts and videos. The best of those were:

Tim Tripcony - "Do I Need to Learn Java?": a brief conversation with a composite character
Mark Roden - When the community comes together we get the right answer
Steven Wissel - Learning a new language or platform
Jeff Byrd - Life without xPages # 3 – a little more JAVA please

I think David Leedy's Notesin9 was brilliant and hilarious. If you have not watched this, you should. NotesIn9 141: Java vs JavaScript Throwdown. Mark also responded appropriately (And the gloves are off…… and An open letter to Mr. NotesIn9).

I have been reading and watching on the sideline. I no longer write code, so the technical discussion going on here is something I don't feel like I should provide an opinion. Mark, Tim, David and many more are much more qualified. But as the discussion morphs from technical to interacting with customers, I feel I can contribute to the discussion.

Selling XPages isn't actually selling XPages for me. I rarely sell technology. I focus on selling a solution to a business problem, using technology. One of the advantages I have is that I have a broad range of solutions I can sell. Besides XPages and other IBM solutions, PSC has practices that work with SaaS solutions such as and, Microsoft Dynamics AX and CRM, Microsoft technologies including Microsoft SharePoint and .NET and Azure - even custom Microsoft Office development, and open source solutions around Java, Python, and LAMP. We specialize in integration of multiple of these systems, and do quite a bit in REST and libraries such as Node.JS, Backbone.JS, and Angular.JS. Because of our broad range of skills, I can focus on the solution before selecting a technology. Now, for sure, customers and prospects come to us and say 'we want you to build this and use XPages' or 'we are a Microsoft shop, pick a technology that works within that.' By selling solutions to business problems, most of my job is focused providing confidence that we can solve the problem. It is quite liberating as the selling process.

When it comes to XPages, the shift from 'we can build a XPages app for you' to 'Let's build a great application using this web platform called XPages' started 2 years ago. Our selling process focuses on customer success and user experience. For us, that means design and user experience is key. We have internal designers that focus on design patterns and look and feel. In many ways, the IBM Exceptional Design Experience process is something we have applied to XPages - and everything else. Technically, this means Twitter Bootstrap and a collection of resources such as jQuery, extJS, and other sources. We even use Java - especially with things like Apache Poi and much more. We don't limit ourselves. There is no 'you can only do it this way.'

In the past 5 years of selling, I have never once had a customer ask 'I want you to write this application in Java.' There is always an IT person asking about maintainability, future-proofing, and discussing their available resources. But rarely is it focused on 'please write this system in a specific language.' There is always talk on build vs. buy. Or open source vs. not. Selected Vendor and/or selected platform of course comes up. But never once has anyone said 'you can only write this in Language A.' Opposite that, we have had multiple customers tell us 'We don't have the resources to maintain an XPages application with lots of Java in it. Please design this to target our internal skills as much as possible.' Now, we can attribute that to the maturity of the XPages community outside of the top contributors, but it is reality. We take the stance that it is our job to educate our customers on their options, but not tell them they are wrong. Communication and direction matters, but putting blinders on to tell someone there is only one right way to develop a 'good application' makes no sense.

One thing I find interesting in this discussion is the difference between in-house and consultant and systems integrators vs. ISV's. This is a healthy discussion. I think that learning and sharing experiences on how we all see the technology helps everyone grow. What I likes most about this discussion was the 95% open-mindedness of the community. Comparing this to a discussion even just two years ago, it would have been far less.

To wrap this up, I do agree 100% with David Leedy that as a developer, you should always want to be learning. And always be practicing. I also agree that knowing Java is important, but it's one item in the XPages developer's toolbox. The best customer solutions that I have seen - those built by PSC and by others - use a mix of both and much more. The range of solutions coming from David and Jeff Byrd and Mark and Brad Balassaitis and so many more pushes the community forward. There was a time that XPages didn't even include projects like the ExtLib - look how far XPages has come in just five years!

TL;DR - don't get caught up in which language matters in a solution, focus on delivering the solution that solves the business problem. At the end of the day, the people who write the check really don't care about the language used.

8 Responses to “Selling XPages - what matters?”

  1. 1) David Leedy says:

    First off, thanks for the kind comments on the video. I appreciate it and I’m glad you liked it!

    I absolutely agree that the discussion needs to be on the solutions and not the technology or the tools. It’s about solving business problems - nothing else matters in theory. Though of course price and maintainability matter as well.

    While on paper, yes the customer is “always right” and the consultant must deliver what the customer asks for, I think there is some grey area here.

    I have a big issue with this statement:

    “we have had multiple customers tell us 'We don't have the resources to maintain an XPages application with lots of Java in it. Please design this to target our internal skills as much as possible.’”

    While a consultant has to do what the customer asks, this is a scary statement on the surface. And one where I think more often then not the customer who said that would be WRONG. I’ll give an example of that.

    First though let’s look at what that means. Mr. Consultant - please build be a solution but first let me go through your toolbox and pick out tools I don’t like. I’m not talking about platforms here, just the tools used to work with the platforms. I don’t think anyone will disagree that on the surface Java is a very powerful. To handcuff the consultant right away seems silly from the customers point of view. Maybe without the tool, in this case Java - but whatever, that it now takes longer to build. That means costs go up.

    I understand that this is a reality out there but it’s a decision that carries a bigger potential cost.

    Let’s say that the consultant compiles and uses the designated tools. That in NO WAY means that the customer will be able to support that in the future.

    I have a hammer. But I can’t build a house. I have a golf club but I can’t hit the ball like Tiger Woods. It’s a false assumption that if the consultant makes an application that the customer will be able to support it at all. The consultants by definition are TOP people and likely using techniques and methodologies that are foreign to the customer. So where now is the benefit in the customer asking to target internal skills?

    Let me give you an example:

    In the day job, my company purchased an application from a consultant that was mostly written in “LotusScript”. While I’m not exactly what you’d call a “Hired Gun” in the programming world, I’m pretty comfortable with LotusScript and have written a LOT of code in it. So I feel I can at least hold my own in that regard.

    However the LotusScript in this application was IMPOSSIBLE for me to maintain. There was no chance. Decisions that were made not just in the LotusScript but in the application were mind boggling to me. It was based on a generic framework the consultant favored that was then used in a custom solution for which it was not intended. It used “hacks” in the notes client that required hard coded server names in subforms. The LotusScript had a TON of internal setup code that always ran even if the objects the setup code referred to weren’t even used. This made it very hard to debug or do anything with even though I was a LotusScript “expert”.

    There were many other issues but I think you get the point that just because a talented consultant/programmer uses the language of the customers choice does not mean the customer will have any chance of supporting it going forward.

    If at the end of the day people writing the check don’t care about the technology used then they should not be taking a language like Java off the table in the building of the solution. That’s a contradiction. Let the experts decide what’s best.

    Just my 2 cents.

  2. 2) Jesse Gallagher says:

    On one of the broad strokes, I agree wholeheartedly: the point of development is to create good apps to solve problems, regardless of the techniques used. That's how I view XPages: a web-app development platform that I have particular expertise with, not as "the new way to do web Notes databases" or as the sole tool for all jobs.

    Where I diverge is in the notion that Java and SSJS are equivalent tools for building XPages applications. The core problem with SSJS-heavy XPage programming is that it encourages developers to bring the same sort of disjointed app structure that plagued classic Notes development to XPages. It is certainly POSSIBLE to make extremely clean XPages apps with tons of SSJS, it's going against the grain, and you end up spending a tremendous amount of time tracking down problems that are largely discouraged in the first place with a heavy Java focus.

    Admittedly, it is a problem that many Domino shops view SSJS as somehow inherently more supportable than Java, I feel that that's a problem best solved with education, not self-handcuffing. When you choose the right tool, it puts wind at your back and gets the job done more quickly.

  3. 3) Tim Tripcony says:

    John, we've gotten similar feedback from several of our customers regarding comfort level with Java. Some of our engagements consist entirely of mentoring, some are just delivery of code that we write for the customer; many are a hybrid. I do what the customer tells me to -- unless I have a moral or ethical concern regarding their request, of course, which is quite rare -- but when the customer exhibits resistance to Java on general principle (usually because they see discussions like these and have formed the conclusion that Java is inherently something to fear), I would be doing them a disservice if I didn't at least make a token effort to correct their misconceptions. I always endeavor to be respectful in providing my perspective, and when the customer maintains their original position, I deliver what is requested.

    Feature for feature, the delivered solution is always cheaper when the back end layer is architected primarily in Java, because the editor provides more robust assistance in writing the code in the first place, the compiler provides advance warning of potential problems instead of having to wait until runtime testing to discover bugs, debugging problems that do occur is far simpler, the nature of the language itself eases reusability both within a single application and across all apps in the same environment, and in many cases the same functionality can simply be delivered with less code. All of those benefits provide greater value to the customer before the solution is even deployed because we're simply billing them for less hours than we would otherwise have been required to.

    But we never force Java on a customer. SSJS is adequate. Clearly XPage apps can be developed without ever writing a single line of Java code ourselves. But feature for feature, avoiding Java in favor of SSJS costs more, both during initial development and as the app evolves over its lifespan. I'm not in sales, so my discussions with customers regarding this reality tend to remain focused on the technical, stylistic, and developer productivity differential between these languages. But just as I support whichever browsers a customer insists upon using, but always at least mention to those using I.E. (especially older versions... 10 and 11 are actually finally approaching respectability) that there's a better way, my conscience requires me to at least encourage every Domino developer with whom I interact to pursue some comfort level with Java, in the mutual interest of their own long-term job satisfaction and their employers' / customers' bottom line... even if after doing so they opt not to heed that advice. It's ultimately their decision; I can't and won't force someone to learn something they're unwilling to. But I also won't lie to them and tell them they're likely to achieve the same quality at the same cost. It would be fantastic were that the case... but it's not.

  4. 4) Nathan T. Freeman says:

    I hear Justin Beiber sells a lot of records.

    I'm curious, John, just who exactly you're talking about when you make statements like "...putting blinders on to tell someone there is only one right way to develop a 'good application' makes no sense." I asked Marky that question and he stated that Tim and Christian had *implied* by encouraging people to focus on Java, but never managed to name anyone who'd actually made such a claim. Yet here you are, trotting out the same strawman.

    What's easy to observe and what everyone seems to agree on is that there's nearly an infinite number of ways to make a BAD application, and that customers should be guided away from those practices. I don't know how that end could be served by making false claims about other people's positions or offering career advise telling people that they should prioritize one of the most popular languages in the world { Link } right after "other things I've forgotten."

    But hey, it's just people's jobs and families on the line. No reason to worry about a little hyperbole! Why so serious?

  5. 5) John D Head says:

    Tim - that was a great comment. Thanks for adding to the conversation. I agree with almost all of it, but let me focus on what we agree on first. A great relationship for a consulting firm is not developer or consultant or even partner, it's trusted advisor. Being a commodity that can easily be replaced is not only a bad position to be in, it gives you no voice when you want to explain why something is good or bad. There is much written about the trusted advisor relationship out there, so I won't dwell on it, but it's the goal of every client relationship I have. Yes, it will never be 100%, but that is the goal. You have to earn it. And one of the ways you earn it is by providing advice that is well balanced. Of course, explaining to customer why targeting IE8 may be bad or costly is the right thing to do. Explaining all of your options on making a platform choice matters. And yes, talking to a customer about their options on building an XPages applications and the languages used. It might shock you, but we use Java at PSC ;-)

    Being a consultant vs. being an in-house developer or ISV means you always have constraints. You can showcase how those constraits might make what you are doing more difficult, costly, and any of the other possible issues. But at the end of the day, the customer gets to pick what's in your toolbox for this project. That happens every time. But you have to be a consultant to experience that.

    The one thing I disagree with is "But feature for feature, avoiding Java in favor of SSJS costs more, both during initial development and as the app evolves over its lifespan." - I have just not seen that specific case in our business. I am open-minded to be shown a specific example, but have not seen it yet.

  6. 6) John D Head says:

    Nathan - I heard the Beattles sold a lot of records as well.

    Thanks for your comment. And the website. Have you checked out as well? Great read.

    "People will generally accept facts as truth only if the facts agree with what they already believe."

  7. 7) Nathan T. Freeman says: right now: c# 620737, java 612044, javascript 584742 So your data point agrees with mine that Java is a hugely popular language, especially if you factor in Microsoft's implementation of it.

    "I have just not seen that specific case in our business."

    Well, of course you haven't. Your own technical leadership is saying there's no reason to use Java over SSJS, so how could you possibly compare developer productivity and code reliability between them when you're only using SSJS in your practice? People like Tim and Jesse are experts in both languages, have actually used both options in multiple client contexts, and therefore have experience to draw upon in comparing. Who on your team would be capable of doing that and what opportunity have they been given to compare?

    But you STILL haven't answered my question: Who is "putting blinders on to tell someone there is only one right way to develop a 'good application'?" Can you answer that question? And if you can't, will you and Marky admit that this entire discussion has been about a strawman?

  8. 8) John D Head says:

    Thank you Nathan for providing the best wrap up to this conversation - better than I could do myself. I am closing comments so we can all move on to the next discussion. Thanks!

Leave a Reply

Discussion for this entry is now closed.