New Tool: The Path of Least Danger [Matt Schlegel]

In the previous blog, I described the step in the problem-solving process of how a team will analyze the various ideas proposed to solve a problem. During that analysis, the team logically thinks through the pros and cons of each idea. The team will also want to consider peoples’ emotional reactions to each idea, as that will impact the overall acceptance of a proposed solution. Having done that, the team has equipped itself to formulate a plan to move forward. In order for the plan to be accepted, the costs must be reasonable and the risks must be balanced. In my experience, I have found that after bringing a team of people through the problem-solving process to this point, there is a remarkable amount of consensus around the solutions to use in order to solve the problems the team faces. Building on that consensus, the team at this point in the process decides on a plan to move forward. This plan I like to call the Path of Least Danger.

Fear is a remarkable thing. Each of us has a different reaction to fear. I will stretch myself here with my lay knowledge of how the brain processes fear. There is a part of the brain, the amygdala, that serves as the information processor that outputs the fear response to the rest of the brain. As with much of our bi-cameral brain, the amygdala has a right part and a left part. My understanding is that one side tells our brain that something is really scary and that we should avoid it if at all possible. The other side tells the brain that you should go and destroy the thing that is making you feel this way. And, just like people can be "right-brained" and "left-brained" or "right-handed" or "left-handed", some people will have a strong reaction to fight and some will have a strong reaction to flee. (Please correct me if I have misrepresented the function of the brain, this is a blog after all.)

Since we are not quite to the point in our problem-solving process where we need to fight (I will talk about that more in the implementation phase), we can tap into the thoughts of the more "run-for-your-life" types, and I put myself in this category, to help the team formulate the path to move forward. Since the team has collectively decided already to do something, they now need a plan to get them to a solution that solves their problem. And, since all the scary pitfalls and landmines have been laid out in the analysis phase, and by this I am referring to the resources that the team would need to implement each idea and the threats that would prevent an idea from being implemented, then it is a matter of finding that optimal path that minimizes both resource utilization and threats to failure. On that path the team can build the reasonable-cost, risk-balanced plan. In other words, we can use our fear response to empower the team to choose the Path of Least Danger.

Now that the team has decided on a path forward, it is time to acquire the resources you will need to take the team down the selected path. In the next blog, we will talk about the important step of advocating the plan not only to get the permission to proceed, but to get the resources, as well.

__________________________
Matt Schlegel categorizes himself as a "fear aware" type. He taps into that characteristic as he finds that it gives him the ability to create project plans, schedules, test plans and manage quality for products. He finds that he is a "natural" at worst-case analysis, and uses that natural ability to help teams avoid pitfalls, create reliable solutions, and build high-quality products.

More...

Zoom with Joomla or Drupal [Steve Mezak]

You can launch your web app faster when using a content management system (CMS) like Drupal or Joomla or other frameworks like CakePHP or CodeIgnitor – all written in PHP. These CMSs and frameworks contain built-in functionality that will accelerate you software development. But using them the wrong way, or in the wrong situation can be a disaster.

It is critical to get a web app launched as quickly as possible. No one wants to wait months (forget years) for a new web application to appear online. The promise of CMSs and Frameworks is they give you a jumpstart with pre-built functionality and an environment that makes your programmers more productive. But like most tools, they can also be misused causing more headaches than help.

These frameworks are open source and available at no cost but they have a steep learning curve. I got excited about using a CMS for a website I was creating last year. I bought a couple Drupal books and downloaded the software from the Acquia website. It installed easily and I had a working site in a day.

Customizing the site was a different matter. I was able to easily add in several contributed modules but I found it difficult to combine modules along with my custom code to create a decent looking functional application. I basically wasted a couple weeks to discover that I really needed experienced professional help.

If you are building a community website then you should consider using a CMS platform. A CMS has these features that community websites need:

• Access statistics and logging
• Advanced search functions
• Comments, forums, and polls
• Multi-level menu system
• Multi-user content create & edit
• OpenID & Facebook Connect
• RSS Feed Aggregator
• and many more . . .

CMSs and frameworks are extendable and it is common to add code to deliver your desired functionality. For example, Drupal has a list of user-contributed modules available to extend its functionality. And your programmers can create their own modules too using the Content Creation Kit or CCK.

The primary pitfall that inexperienced programmers fall into when using a CMS is adding functionality by changing the framework itself. If your programmers “hack the core” of your CMS directly they create a mess that is difficult if not impossible to fix.

Any new development team is not likely to be able to unwind the hacks. To fix any bugs they will only be hacking the core further. In this case you almost always have to start over.

First you should decide if CMS features are needed. Selecting a CMS may only add complexity if the features you need are simple or different that what the CMS delivers. A framework that enables rapid page creation and supports modern Ajax-based user interface features can be a better choice.

The look and feel of your web application is completely configurable with a CMS. Frameworks and CMSs have a way for you to deploy your design in a consistent way. In Drupal this is called Themes, in Joomla it’s called Templates.

Versions of Frameworks and CMSs change periodically. If you outsource, make sure the development team you hire has experience with the latest version, or at least the version you want to use. For example, Drupal had a major upgrade from version 5 to 6 last year. Many of the user-contributed modules did not work with the new version. It was months before most were development teams were experienced with version 6.

Experience with these modules is critical. Anyone can install a framework or CMS, but the basic functionality is not enough. Ask for examples of web apps your prospective development teams have created for other clients and the kinds of modules and custom development they employed.

Use a development team that has experience building web applications for other clients with the CMS or Framework you decide to use. You can wind up wasting your time attempting to make a sophisticated web application on your own by using one of these platforms right out of the box unless you have already gone up the learning curve. It takes professional help.

The only thing worse than wasting your own time, is wasting time and paying money to an inexperienced development team. Choose carefully and your use of a CMS can shave months off your development time line.

_______________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, has dabbled with Drupal. Use his free online Global Partner Network, containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world, some of which are experts in Drupal and Joomla. http://www.accelerance.com/

More...

Leading What [Jane Divinski]

When people talk about engineering leadership they often are referring to leading human beings, specifically, engineers, but I think that it’s more accurate to realize that one is actually leading decision making. Some of these decisions are made unilaterally by the “engineering leader” but many are the result of input by multiple people in the organization. Regardless of who’s involved, the leader needs to make sure that decisions ARE made and made in an appropriately timely fashion.

Years ago my then boss informally confronted me with his concern that I might be making decisions too quickly. He pointed out that additional information is usually forthcoming and wondered if I might not be better off awaiting it’s availability before moving forward with a decision. We actually had a lengthy and enjoyable discussion about this topic.

I asked him for specific examples of such instances and he promptly cited three. I then proceeded to spell out all the information I had factored into the decision. In addition, I described other data I would like to have had to factor into my analysis and explained why such information wasn’t yet available and when I could reasonably expect said info.

We then chatted about the impact (aka cost) of delaying the decision; for these three examples he ended up agreeing with me that each involved instances where a timely decision, based on the available data was better than a delayed decision. Obviously this is not always the case.

__________________________________________
Jane Divinski has enjoyed the challenges of engineering management consulting since 1994. Most of her gigs are as interim VPE but Jane's also tackled other interim roles including CTO or program manager. Her background is at www.jadski.com

More...