Who Owns the Process (A.K.A. Please Just Let Me Do My Job)

I’ve worked at several places and each had a different process– each one usually very different from the others.  I’ve worked under CMMI level 5 waterfall processes as well as scrum agile processes.  Here is what I’ve learned from my experience: “Nothing can destroy a good product faster than a bad process.”

Now, let me guess.  You’re assuming I’m going to rant about CMMI level 5 waterfall’s rigidity and extol the flexibility of Agile.  You’re right.  On the other hand, if you think I’m going to rail on Agile’s tendency to lead to Cowboy Coding and praise the emphasis placed on thoughtful design by waterfall–you’re also right!  This is because:

The process is not important.

Whoa!  He didn’t just say that, did he?  I should clarify–it’s not that the process doesn’t have any impact on the product.  The right process reduces impediments, manages risk, helps maintain appropriate quality and productivity goals and fosters appropriate collaboration.  The wrong process can literally destroy high-performing teams and obliterate good software.

But, fixating on the process is like hiring a librarian to perform open heart surgery and worrying about the color of thread she’ll use to stitch you up when she’s done.

Here is my rationale:

  1. Every process is defined, modified and enforced by people
  2. Every step in the process is implemented by people
  3. Evaluation of the process and its appropriateness is performed by people
  4. Project and product goals are defined by people
  5. Evaluation of the product and its success is performed by people

Notice a pattern?  At this point it’s tempting to say: “It’s all about the people.  Hire the best people.”  This is true, but it’s a red herring–everyone knows this and it’s not especially helpful.  What I’ve learned is this:

“You must have the right people empowered to change the process as they see fit.”

The right people

This one isn’t as easy as it seems.  It really consists of two things: you need to have people representing the right concerns and you need to have people with the right personality characteristics (a topic for another blog post).  At a minimum your process team should include the following stakeholders:

  1. Representatives from the technical team
  2. Representatives from the customer perspective
  3. Representatives from the business / management perspective

The common exclusion of 1 and 2 led to the creation of agile.  The exclusion of 3 leads teams to return to waterfall.  All three must be represented and empowered for a software development team to be efficient and successful.

Empowered

There are a large number of aspects that affect how a team should tailor its process.  This includes things like: requirements volatility, developer proficiency and risk tolerance.  The following chart illustrates how various project factors impact the choice of a process:

ProcessApplicability3

If you’re writing code that controls nuclear missile launches with a team of ninth grade gym class students — waterfall is the clear winner.  In the real world no canned process will be a perfect fit.  You will need a customized process that includes some elements taken from various processes.  And this leads us back to our thesis:  The appropriate people (technical, customer and management) must be involved and empowered to change the process as they see fit.

conclusion (TL;DR)

No process is perfect and yours is no exception.  Get the right people involved in the process and give them free reign to change it as needed.

 

Troubleshooting Aurelia (A.K.A. Where are my Custom Elements?)

Aurelia is a great JavaScript framework for creating Single Page Apps (SPAs).  It’s especially easy to learn for engineers that are familiar with WPF and the MVVM pattern-the documentation even uses the familiar terminology of views and view-models.

While it’s still in beta (as of today – Mar. 24, 2016), there is a decent amount of support available on Gitter, Stack Overflow and some documentation available on Aurelia.io.

Recently, I’ve been using Aurelia in conjunction with Cesium to develop a 3-D visualization app.  I’m using Aurelia for navigation, custom components for various forms of selection and the main navigational view component contains Cesium:

.HypersonicScreenshot

One simple, but potentially frustrating issue I’ve run into is when my custom elements don’t appear in the app.  This frequently leads me into the following train of thought:

  1. Why aren’t my custom elements showing up in Aurelia?
  2. Are there any warnings / errors in the browser console?
  3. Is there a bug in my View (HTML)?
  4. Why aren’t there any warnings / errors in the browser console?
  5. Is there a bug in my ViewModel (js)?
  6. Where are the darn warnings / errors in the browser console?
  7. Is Gulp watch working?
  8. What the heck is wrong with this thing — why aren’t there any warnings or errors!
  9. Why didn’t I become a Doctor like my mother always suggested!?!

After struggling with this train of thought for a while I finally realized I’d missed the following little snippet in my containing element’s HTML:

<require from="my-custom-component"></require>

As you may have guessed from the above rant, this does not generate any warnings or errors.  Instead, you may just end up with an empty component like this:

<my-custom-component></my-custom-component>

So, next time you start asking yourself “Why aren’t my custom elements showing up in Aurelia?” make sure you haven’t forgotten a <require> tag in the containing element.  Either that or choose a less frustrating, time-consuming career and go back to medical school.