Home > commentary > MarkLogic decidedly wins development competition

MarkLogic decidedly wins development competition


The challenge

A few weeks ago I got called out of my coding lair and was brought into a meeting with management where they informed me and 5 other people that there was going to be a friendly internal competition. A web application for tracking portfolios, initiatives, projects, and deliverables had been thoroughly designed for desktop\tablet and phone use. There would be two teams, each consisting of 1 QA and 2 developers. We were to stop our current work and devote our time and efforts on this, and in 1 week the two teams would reveal what they had done. Management would take care  of clearing our schedules. At the end of the week, the implementation that won would go on to being used for real by our group (about 120 people) and possibly other groups within the organization.

We were allowed to use any technology we wanted. The requirements (if we could meet them) were that the web application used our organization’s login accounts, was behind SSL, worked on a desktop and tablet (which had one design) and phone (which had a modified design). We were given high-fidelity mockups and access to the designer and the main user, and we were told to come back in a week and show how much we got done.

The requirements

I can’t post any screenshots because I don’t have permission, but I will describe the application a little. The main page of the application showed a timeline of all the projects for all the initiatives for a given portfolio. There may be 10 to 15 initiatives and each initiative may have 10 projects. Projects are 1 to 12 months and have usually a few deliverables. There are about 12 portfolios. The timeline on the main page has different colors for each deliverable indicating status, which can be modified via the main page if the user has permissions to do so.

There are three levels of access in the application: View, Edit, and Admin, and users are scoped to the particular portfolios that they should have any access to. Admin users can add other users and assign portfolios and roles. Users are added just by entering the user’s existing internal organization account username and the web app will import the user information from LDAP.

Editors can add and modify initiatives and projects, which each have their own screens. Initiatives have names, descriptions, year, and a few other fields. Projects have name, description, start and end dates, overall budget, dependencies on other portfolios, labor calculator (list of individuals and their bill rate, percentage engagement, number of days engagement, etc with dynamically calculated labor rate total), deliverables (with name, are delivery date) and a few other fields. Adding and removing labor rate line items and deliverables is in-browser, not a screen refresh, and the deliverable dates are scoped to be between the start and end dates of the project.

There is also a summary screen that is similar to the timeline page except it show all the initiatives and projects for a portfolio in sort of a spreadsheet view where you can collapse and expand initiatives to show or hide their projects. The budget totals are also shown for initiatives and projects.

That’s the gist of this application. It is non-trivial and had a very rich design and interaction. My team had an excellent QA, excellent front end dev, and me who was the only one who knew MarkLogic. The other team chose to implement theirs using a Javascript front-end architecture communicating with CouchDB (later Java with MongoDB) on the backend. The two teams involved very skilled people. If these two technology approaches were going to go head-to-head, these were the people to do it.

The results

So how did it turn out? We deployed our implementation to a server behind SSL hooked up to our auth scheme in my organization. We implemented all the requirements, and then some. We had three experiences fully implemented: desktop\tablet, phone, and dumbphone (meaning no CSS or javascript and limited functionality) which the server would pick for you based on detected device abilities. We had SOAP\XML and REST\JSON services. We had the entire application translated into 9 languages: English, Spanish, Russian, Greek, Japanese, Korean, Chinese, Arabic, and something else (I can’t remember).

We also ran the application through a series of speed, load, penetration, and injection tests. Average HTML page size was 1 or 2 KB. Average response time for HTML was 250 ms (assets were all cached after the first hit). With 1000 concurrent users, there was no perceived change in performance. There were no failures or warnings with session hijacking, cross-site scripting, malicious code injection, malicious character injection, or any other security test. This was using an old-ish former Apache server which was not even half-power for a MarkLogic recommended setup. One ED Node, no caching.

We did this all in one week.

The other team did not finish. They had a few pages that showed some data, but it was not deployed, didn’t have authentication, you couldn’t create or change data, no phone or other experiences, at least based on what they showed. No other languages than English either. No security, penetration, load, or injection tests. For whatever reason, that’s how things ended up.

What does it prove?

To me, this demonstrated hands down the speed at which you can implement non-trivial, fully featured, mature, enterprise-class, performant, and secure web applications very quickly, in only one week, with only three guys, sometimes.

So that application my team created is being used for real now, and it has had some bug fixes and other tweaks, especially with IE (did I mention it was cross-browser compatible?). Oh and did I mention the build and deployment time is less than 30 seconds?

It’s hard to argue with end results. People’s time is expensive, and the less time you need to spend on people creating frameworks, building stacks, adding in security and other enterprise stuff, the better. And with all the claims and arguments that get tossed around, all I really think is: scoreboard.

About these ads
Categories: commentary
  1. August 20, 2011 at 11:56 am | #1

    Sounds like a fun competition and a cool app. It also looks like the technology fight is still alive and well in your organization, with strong feelings all around. I don’t have a dog in the fight, anymore, but there is a strong “defensive of MarkLogic” tone that lends me to think the battle is still raging over there.

    • August 20, 2011 at 1:04 pm | #2

      The numbers speak for themselves. That’s all we need to defend.

  2. August 22, 2011 at 11:54 am | #3

    Oh, how I could use that application. Well done to the development team.

  3. jim sullivan
    August 22, 2011 at 11:02 pm | #4

    Nice job – 30 years ago (31 actually), I went to work at Mitel as a Waterloo Coop Student, the first math coop student hired by Mitel. I was working on the SX2000, the biggest PBX that Mitel had ever conceived and one that proved to be a tremendous burden on the company. Two years and three work terms later, the SX2000 team had grown to well over 100 people (from a core team of 6, maybe 8 and another 6-8 support people). Progress on the SX2000 had slowed in a similar rate to the growth of the team. I remember discussing the problems with one of the core developers (one of the original 8) as the project spiraled out of control and we agreed that if we’d remained small and nimble, we’d be done by now.

    never underestimate the power of a small, focused team.

    -jim sullivan

  4. Arnaud
    August 23, 2011 at 6:11 am | #5

    Hello,

    Could you give us technical details why MarkLogic speed up your development ?

    What are the specific features you used ?

    What about the deployment framework you used ?

    Thanks for this article. It gives me some ideas for the next inhouse development.

    Regards,

    Arnaud

    • August 23, 2011 at 8:11 am | #6

      I was thinking I’d be able to explain this in a comment reply but I realized that there’s more to it than I originally thought. So I’ll write a blog post on it today. I also think that some patterns have emerged which hasn’t really happened much in the MarkLogic community to date. So I think need a new tag on my blog about patterns, too.

      • Arnaud
        August 23, 2011 at 12:14 pm | #7

        :-) Take your time. But any details are welcome, as i did not know about MarkLogic before your article.

  5. Shaun Heath
    August 23, 2011 at 8:12 am | #8

    Not much info supplied re: the other team. Are you saying that they switched from JS/Couch to Java/Mongo? If so, why? If so, is that change why they didn’t complete? I don’t think there is enough info here for me to take your end results as proving very much. If that info exists I would be very interested in hearing more.

    • August 23, 2011 at 12:58 pm | #9

      The point of the blog post was to show the speed at which development can happen on MarkLogic, not to criticize the other team. But yes they started with one backend approach and switched. I actually cant’ remember for sure which was first and which was second, but it didn’t really matter in the end.

  6. August 23, 2011 at 1:05 pm | #10

    Did MarkLogic translate your web pages to 9 foreign languages as well?

    • August 23, 2011 at 2:52 pm | #11

      No it doesn’t do the translating itself. You have to get them from Google translate or a real person. But MarkLogic does know how to handle content in multiple languages and can word stem a lot of them.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: