Moving to higher levels in the Capability Maturity Model for MarkLogic applications

The Capability Maturity Model

The Capability Maturity Model is a development model from Carnegie Mellon that describes five levels of maturity in the development processes of software applications. The first time I came across the CMM was when I worked for Andersen Consulting and they had posted the levels of the CMM in the restrooms (which I think was a very good idea, actually). At the time I was a novice programmer and was just concerned about getting my stuff to work. There were two levels in my world: works, and doesn’t work. I didn’t come to appreciate the CMM until many years later.

The fact that there even could be different levels of maturity might even cause some people to realize for the first time that they really need to up their game. I’ve found it helpful when my projects start feeling pain, I review the CMM and try to see where we really are.

These are the levels in the CMM (lifted straight from wikipedia):

Level 1 – Initial (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.

Level 2 – Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.

Level 3 – Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.

Level 4 – Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.

Level 5 – Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

Of course different organizations and different projects may never want to be on a very high level because it can be costly and can be bureaucratic. If you are freewheeling, cutting-edge and don’t have much to lose, then you probably aren’t going to care much about these. But when the cost of failure or the cost of not increasing maturity levels exceeds the costs of increasing maturity levels, then you are going to want to take it that next level of maturity.

Your Technical Debt Is Increasing

Technical Debt almost always grows as a product increases in lifetime and complexity. Ward Cunningham wrote (again lifted straight from Wikipedia):

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

My experiences has been that technical debt is allowed to grow and reach a crisis point because the development process is at a low level in the Capability Maturity Model. Note that initially it’s ok to start off with technical debt and you are in that Level 1 “Chaos” level precisely because things have not yet been defined, you are in an exploratory mode, and what you are developing is new. The problem comes when you don’t switch gears properly and use a mature model to reduce technical debt as your product grows. Remember that for every new feature or improvement you must make sure that you do not break them in each subsequent release.

CMM for MarkLogic applications

I am not referring to the MarkLogic Server itself, but rather to implementations built using the server. So you as a customer of MarkLogic have decided to use MarkLogic Server to solve solve business need in your organization. Although the MarkLogic Server may provide you with technology to do things you’ve never been able to do before, it will not fix any broken or immature processes you have in your organization to develop or maintain those custom applications you’ve written. And while MarkLogic is becoming a trendsetter and is a disruptive technology, not everyone is too pleased with the success of MarkLogic and would love to see failed efforts using this technology. So don’t let your immature processes be mistaken for faults of the technology.

Once you put your business on the line, or people’s lives on the line, or your reputation on the line, or your money on the line because you chose to power your application on MarkLogic, you are going to need to be at a higher maturity level than you were when you first developed the application. MarkLogic seems to target fewer big-ticket clients so I’m guessing that the majority of MarkLogic customers have a lot on the line on their MarkLogic implementations. And rather than spending a lot of effort in improving the technical skills of your developers in writing whizbang code, I would offer that it would be more valuable to invest in having your developers develop processes, techniques, and technologies to improve the maturity for being able to improve and maintain your investment.

Descriptions of Levels for MarkLogic Development

Below is what I would describe for each level in the CMM for MarkLogic development.

Level 1 – Initial (Chaotic)

This is usually where new development on MarkLogic starts out. One or a few developers at an organization are tasked with figuring out how to leverage the technology for some new effort or offering. Usually the developers know little and must asked the developer email distribution list questions, or use MarkLogic consultants. Whatever code first produces the desired results ends up as the production code.

What you need to know\be able to do at this level: Understand XQuery, XPath, xdmp functions. Be able to load your data. Be able to use the Admin Console on 8001 to configure MarkLogic so that your implementation works.

Level 2 – Repeatable

After some time, the developers and the organization have some experience and knowledge that they share or review with each other. The “better” practices are known and settled on. Developers are knowledgeable about the XQuery syntax, XPath syntax, the xdmp functions, and features of MarkLogic Server. Developers and sys admins are confident in making changes, writing code, and running the software for business critical solutions. I would guess that most of the solutions that are 6 months or older are in this category.

What you need to know\be able to do at this level: Be well versed in the MarkLogic API. Be able to create the proper indexes for your data and queries. Know how to use cts:search and search: search. Be able to create a proper data model for your data. Be able to write HTML interfaces for your implementation. Be able to use and understand the logs. Know how to not create deadlocks. Be comfortable with Functional Programming instead of Object Oriented Programming.

Level 3 – Defined

Knowledge about the technology is recorded, shared and maintained. Policies are established around deploying, backing up, and restoring the application and scripts are created to automate many of these activities. Developers identify “best practices” for code on MarkLogic. Code and implementation is robust and mature. Standard build and deployment practices are implemented. Automated tests are used at part of every deployment.

What you need to know\be able to do at this level: How to set up Enodes, Dnodes, and cache settings appropriately. Create a deployment mechanism so that the Admin Console does not need to be used. Set up automatic backups and be able to restore from them consistently. Be able to deploy to new boxes consistently. Create range indexes. Implement faceted searched. Use a knowledgebase for MarkLogic knowledge. Unit, functional, and end-user testing using XQuery.

Level 4 – Managed

Metrics are recorded by logging statements in the code. Sys admins have configured the implementations to alert them after specified thresholds are reached for various metrics. Developers are skilled at estimating work effort, risk levels, and impact of code changes. Management is skilled at estimating staffing needs for given business requirements that will be addressed via MarkLogic implementations. Security analysts are skilled at evaluating the risk levels of MarkLogic implementations and recommending actions to mitigate them. Releases are consistently and automatically deployed from lane to lane with little or no human intervention. Restores are predictable, automated, and successful.

What you need to know\be able to do at this level: Write meaningful logging statements at appropriate levels. Set up system alerting based on applications health (not just system or OS health). Know the functions that can potentially permit injected code to be evaluated. Know how to run the application under different users with differing roles and permissions. Use amps appropriately. Use code reviews to look for adherence to coding standards and to find faulty code.

Level 5 – Optimizing

System analysts review MarkLogic implementations using historical metrics to determine optimal use of resources. Quality Assurance engineers identify areas of performance improvement. High availability implementations are possible. Maintenance costs are low, and sys admins spend little time directly attending to the implementation. Developers spend little time on maintenance and most of their time on new features, new uses of the technology, and new techniques.

What you need to know\be able to do at this level: Train new developers to MarkLogic on best practices and coding standards. Create automation tools for testing, deploying, managing, and gathering metrics of MarkLogic implementations. Know how to use xdmp:plan,  xdmp:estimate, and other profiling techniques to tune queries.

MarkLogic Server is a relatively new product, as is the community around it, which means that there are not already many of the maturity tools out there as there are for other platforms, like automated deployments, static code analysis tools, and robust IDEs. As the customers’ implementations mature, I would expect the tools in the community and from MarkLogic will mature also.

I’m interested to know what you all think about this. Do you feel like your development processes around MarkLogic development are mature enough? What have you done to create a mature process with MarkLogic?

In Order to Work With People, Understand Their Identities

Identities Drive Actions

Sometimes there are those people that you just don’t want to work with, that you can’t see eye-to-eye on, and who seem to just make your job harder. A lot of time the advice to people and teams is to improve communication, which could clear up a lot of faulty assumptions and misunderstandings. That may be true to some extent, but even when it is, it doesn’t get to the core issue: differences in identity.

Everyone creates mental models of the things around them and they use these mental models to explain how things work and predict what would likely happen in certain scenarios. Human beings are complex creatures and to explain and predict behaviors from ourselves and others we create “identities” and “types” of people to try to figure people out. Why did your cousin get so mad at your brother? Well, he’s the type of guy that easily loses his temper. Why does my car look better than his car? Because I’m the type of person that takes care of his things, and that other guy is not. Why does John always tell me how his cell phone is better than my phone? Because he is a jerk.

Greater communication may not change your mind that John is being a jerk. In order to understand why John is acting like a jerk, we need to understand more about the identities that John holds. John may have an identity of himself and an identity of you which don’t match the identity of yourself and him. John may actually think that you are a pretty good guy, but he may have an identity of himself that he always makes good decisions after weighing all the options and thinking them through. Perhaps for instant or casual decisions it’s another matter, but if he thinks that after spending time research and discussing options that he always makes the right decisions, he will need reinforcement of that decision. Other people may have already expressed to him somehow that he made a really good decision, but you haven’t. So he needs from you reinforcement that he made the right decision. So, without realizing why, he may start criticizing your phone or showing you how great his phone is, yet he doesn’t do that to other people and you couldn’t care less about his phone. In fact, he really may not care about his particular phone either, but really just wants confirmation from others that he really is a person that makes good decisions.

Everyone in your organization has a role, and everyone has an identity of themselves in that role. If they have an identity of themselves as being very proficient and believe that others have that same view, they are going to be much less likely to become defensive or difficult to work with, regardless of how proficient they really are. If they feel threatened, or feel like others’ identity of them is that they are not proficient, they will probably be overly eager to prove to you and everyone else that they are proficient. They will be very sensitive to things that to you are no big deal, but to them could reinforce the wrong identity, or weaken an identity that they want to have. They may want chances to prove themselves, and be real concerned about perceptions on how well they did. They may put up walls and wash their hands of anything and everything that they feel is outside their responsibility, lest they get blamed and have their identities weakened by someone else’s actions.

Once people have identities of themselves and others, they act in a way that reinforces those identities. If John thinks he always make good decisions after deliberation, then he is going to possibly be a jerk when he finds that identity challenges because it must be the case that he made the right decision so you must be the one that is being overly stubborn about your purchase, or else John really isn’t that great at making decisions. And if he isn’t good at making decisions, then what are the ramifications about other decisions he’s made in his life, especially big ones? If Bob thinks he’s really good at finding subtle flaws in the code, and there’s a production problem, it must not be that there is a subtle flaw in the code or else Bob really isn’t that good at finding subtle flaws in the code (so what do we really need him for?). Or similarly, Bob insists that there’s a subtle flaw in your code, when you don’t think there is…why would he being doing that? To reinforce that he is the guy that can find subtle flaws in the code and prove his worth.

People create identities for different reasons. It’s much harder to figure out why people create certain identities, rather than just acknowledging that they do. In the workplace, a person may have determined that his worth to the organization is because of X, so he will be very sensitive of anything that may weaken that perception. Another person may have been very good at Y for awhile, and will not entertain the notion that he’s not good at it anymore, or is over the hill, or has lost his edge. A person may have gotten a lot of heat for a problem somewhere, sometime, and does not want to repeat that experience, so he tries to preempt anything that would put him in the same situation. You may not be able to tell why a person has the identities he has, but you can use them to get along with him.

Understand Identities in Order to Get Along with People

Everyone has identities of himself and of others, healthy or unhealthy. In order to get along with difficult people, try to find a pattern in their behavior that might reveal what identity of themselves they are protecting, or wishing people would validate. If a systems administrator gets overly defensive about whether things are really configured correctly, instead of saying, “I think the server is configured wrong,” which would cause him to start arguing with you about how that couldn’t be the case, you could say, “I think it would be unlikely that there would be a configuration problem on one of the servers, since all the other servers have been running great for months, but maybe some key piece of information was not communicated from the dev team and there is something missing or off.” What you’ve done in the second statement is reinforce that the sys admin really does know what he is doing and that overall the servers are doing well. Any error found on his part now would not undermine his identity of himself, or his hope of others’ identity of him, that he is a good sys admin. But sincerity is key. If you really don’t believe it, don’t say it. You only get one chance to destroy trust. After that he won’t believe anything you say about his abilities.

Sometimes people create identities of themselves of being good at A, but not B, so they will gladly do A but they get real nervous if you ask them to do B, especially if they have an identity of themselves at never making errors or looking foolish. This is also called a person’s “comfort zone” but I think it really more that the person has created an identity of themselves that they don’t do B, and that they are going to look dumb or be a failure if they try that (whereas if they only do A then they reinforce that they are not a failure). So what you can do is get them to be successful at a very small thing that is part of B, and then they modify their self-identity of whether they could do B successfully.

For example, if you were to ask a person on the team to give a presentation on CSS, and the person says “I think I’ve already got too much on my plate,” but you don’t think that’s the real reason. And as you think about it, you realize that you don’t ever remember seeing that person give a presentation. So maybe he doesn’t think he is a “presentation type of a guy.” So then what you could do is say, “well can you just explain to me right now how CSS inheritance works?” And when he is half-way through say, “hold on, let me get Jim in here to hear this.” Then have him explain it again all the way through. Then say, “Alice and Greg really need to hear this. Are you sure you can’t just give the same presentation you just gave to me and Jim, but for Alice and Greg? It really made a lot of sense and would help to hear it from someone who really understands it.” Even though he really didn’t give a formal presentation, you just said that’s what he did and that all he needs to do is given it again to others, which is really all you were wanting him to do. He’ll be much more likely to give a presentation now. And if he does well in the actual presentation, he possibly even seek more of them out in the future. Once you change his self-identity about whether he is a “presentation-guy,” he may change his self-identity that in fact he is a guy who is good at presentations and want to give them all the time.

Summary

Whenever someone you work with seems to be overly critical, rude, angry, or irrational about something, try to determine what identity he is defending, either a self-identity or identity he thinks others have of him. Avoid doing or saying anything that would threaten that identity. If he sees you reinforcing his identity, he will probably like working with you and doing things for you.

Whenever someone is happy in their own world and reluctant to do anything different, help them change their identity about other things by giving them small winning experiences in the area where they are reluctant, but make sure they truly are winning experiences and that reinforce a positive identity in that area.

Keep in mind that why people have the identities they do is largely based on their past experiences and their future expectations, and they may not make sense to you. But in order to get along and get things done, if you avoid threatening their identities and if you help expand other ones, they will find you one of their favorite people to work with.