99% perspiration

Software perspectives from an ancient geek

Archive for category Software

Agile Reporting, Domain-Specific Languages, and other items

Apr 14

Posted by Jon Barcellona in Domain Specific Languages, Process and Methodology | No Comments

Well, it has been quite a while since I have made a new post. My apologies. I have been quite busy on several fronts and will have several relevant posts based on the activities of the last few months. As a preview, since I originally posted the Agile Reporting for Basecamp item, I have received much interest from others wishing to utilize these reports. So, we have decide to make this reporting available on a broader basis. I am pleased to announce that we are in the final stages of preparing this capability. As you may already know transforming an internal tool into a market ready software-as-a-service application is a big task. Look for a posting in the next 30 days or so with details related to this soon to be released SaaS. By the way, this application is hosted in the Google App Engine environment and may prove interesting as a reference app in later posts.

I was recently asked to write an article for an online technology magazine related to a recent project we executed combining several DSM / DSL concepts to deliver a Healthcare based Medical Rules Engine. Once this article is published I will repost it here and provide an expanded version with more details.

I am also heavily engaged in a new variation of Domain-specific modeling / language that is subtly, but materially, different from the mainstream activities in this area. I plan to share this “pattern driven” approach in more detail via multiple posts during the coming months.

Agile project management software surprise

Nov 5

Posted by Jon Barcellona in Process and Methodology | 2 Comments

Simplicity is the ultimate sophistication.

Leonardo da Vinci

My company recently decided to update our project management software. Being an Agile development team we evaluated a number of Agile products. Leading up to our decision, we ran a small number of mini-pilots on several products. From a feature, functionality perspective, especially in the area of Sprint management reporting, Rally is the best product. So why didn’t we select it?

To digress; the primary business purposes of project management software are as follows:

  • to synchronize stakeholders expectations on the project by organizing and succinctly communicating the requirements, resources, and timeframes.
  • to reduce complexity for the project team by decomposing a big project into smaller, prioritized, actionable tasks.
  • to provide near real-time feedback on project progress, so that adjustments can be executed in a relevant timeframe to stay on track.
  • to provide long-term trend reporting to affect macro decisions to adjust best practices and organizational effectiveness.

So, what did we choose? One of the SaaS products we evaluated was Basecamp. We almost didn’t do our mini-pilot with Basecamp, except that the simple elegance of its user experience really enticed us to try it out. The amazing thing is how easy it is to use and collaborate. The team immediately latched on in a natural way. Basecamp allowed us to cleanly synthesize communications, specifications and clarifications into the project management tasks. Using the project management features of the other products was an “additional task” that the team had to do. Using Basecamp was a natural reduction in tasks that the team did on a daily basis – in both task management and communications. I cannot emphasize this enough. Basecamp passed the litmus test of development team acceptance; it is easier to get your daily work done using Basecamp than it is to not use Basecamp.

Ok, ok, what about the negatives. Those of you somewhat familiar with Basecamp may be saying, “Basecamp is not an Agile product. How could you select that over Rally?” I am sympathetic with this viewpoint. There a few areas where Basecamp does fall short. The most notable shortcomings are as follows:

  • the taxonomy is not Agile. Basecamp is about Milestones, To-do Lists and To-do Items, not Sprints, Stories, and Tasks. The workaround on this shortcoming is really simple. We instructed our team; Sprint=Milestone, Story=To-do List, and Task=To-do Item. Training time was about 30 seconds. Basecamp could improve their product by making these field labels user configurable.
  • for complex projects, less hierarchy exists. Basecamp doesn’t really support a project organization hierarchy as complex as Agile. For a big software project the conceptual hierarchy is Vision, Epic, Theme, Story+Tasks. While the execution hierarchy is Roadmap, Product, Release, Sprint, Story+Tasks. With the common linkage between concept and execution being at the Story+Tasks level. Basecamp does not directly support some of these higher level concepts – for instance, there is no construct called an “Epic”. Our workaround, is to implement these structures through our best practices Convention-over-Configuration techniques. We have found this effective, but not really optimal.
  • no built-in concept of task sizing. Perhaps the biggest surprise to me is that Basecamp does not directly support task estimation. This seems strange since it does directly support assignment of a task to a specific person and the entry of actual time against a task. We have solved this shortcoming via convention. At the end of every task name we include the sizing estimate. We support Units, Hours, or Days with all the common abbreviations. For example, a task named “Some detailed task 6h” would have a 6 hour scope associated with it. Once again effective, but not optimal. I am hopeful that this enhancement is high on the Basecamp new feature request list.
  • no built-in Agile reporting. Certain Agile reporting is necessary to drive both real-time feedback and long-term trend analysis – such as the Sprint Burndown Chart and the Velocity Trends by Sprint Graph. We have solved this shortcoming by using the Basecamp web services (actually REST based) to retrieve the data and build our own reporting. This reporting is secure and web based, with additions on the way for iPhone reporting.

In short, we selected Basecamp because it embodies our motto; Keep the simple things easy. Make the complex things possible. It is a natural extension of how we work today, actually reducing our daily developer burden. Management feels more in control, development feels more in-sync. Basecamp’s does have some shortcomings, but these can be effectively overcome but developing and using well defined best practices with a disciplined approach.

What is holding us back? fear and human nature

Oct 21

Posted by Jon Barcellona in Teams | No Comments

“I, Galileo, … arraigned personally before this tribunal, and kneeling before you … altogether abandon the false opinion that the sun is the center of the universe and immovable, and that the earth is not the center of the universe.”

Galileo Galilei, 1633

I have been in Galileo’s situation several times during my career. I had to choose between burning at the stake or recanting vision in favor of ignorance. Most of the time these events concluded with my co-workers unbending wire clothes hangers and gathering marshmallows. Recanting left me empty and somehow feeling less human, and always proved the beginning-of-the-end of the relationship. (In defense of Galileo, if it was really my life, not employment, I would have been on my knees along side him.)

Since I am frequently baffled by the behavior of people, I can make no claim to being an expert on human nature. I have made many observations over the years, contemplated the meaning, and have some perspectives to share.

When it comes to facing the unknown, the new and the unexplored, there are three types of people: (1) explorers – those who find wonder, excitement and are energized. (2) castle-dwellers – those who deny, ignore, and are fearful, and (3) the inspire-able – the vast majority are those who follow their leaders, whether an explorer or a castle-dweller.

If you are an innovator, you almost certainly are an explorer. I do not understand, nor can I explain the castle-dwellers thought process. I just know that they exist and what to you is either self-evident or a perfectly logical proof sequence is invisible to them. To me it appears to be an almost irrational fear, a type of phobia, where extremely intelligent, highly respectable people just don’t get what to you is a clear and compelling vision.

Perhaps humanity needs this balance, and we are better for it. But if you are driving innovation, castle-dwellers will destroy your effort. There are many key roles that castle-dwellers can perform for a company, just not anywhere near an innovation project. You must get them off your team. There is no convincing them, inspiring them, or gaining their consensus. It is against their nature to support your effort. Even if they are initially “convinced to accept” your plan, eventually their nature will prevail in ways that both distract your energy and poison the team. I personally have paid dearly in both frustration and financially for having to learn this fact the hard way. I have also several times watched others suffer through these same issues.

Just in case you didn’t get the last paragraph – If you need to innovate, build a team of explorers and inspire-ables, and immediately remove the castle-dwellers no matter how talented or intelligent they are.

Have some sympathy for the inspire-ables. Sometimes when you drive new technology into an organization, you experience push-back that is based on some valid personal costs being incurred by your team. If someone spent the last ten years becoming a guru in a technology – spending many late nights and weekend committed to research and education, be sympathetic to what they are leaving behind to explore new horizons. Remember they aren’t “energized” by the innovation in the same way you are. They need your inspiration to move them forward. Acknowledge the impressiveness of their past accomplishments. Paint the mental picture of how they will be a leading edge guru in this new technology. Give them some extra attention, training, or some other deference to get them jump started. Always remember, their nature is different than yours; you may be energized by the innovation, they are energized by you.

The software paradox

Oct 6

Posted by Jon Barcellona in Innovation | No Comments

Ask any software developer and they will tell you that software’s goal is the automation of human processes. Skilled developers will passionately show you – sometimes in more detail than you want – all of their great tools that save them time by performing this or that shortcut, or that insert code snippets, or that remember API references, or that introspect existing code, … the list goes on and on. Almost all developers write software in a language that compiles code from a higher level abstracted concept like Java, C#, Objective-C, etc. into something the machine can understand – machine code. (I know many scripting languages exist, but these languages run even more abstracted from the machine code, so lets set detailed explorations aside for a later deep dive.)

Entire camps of developers wage “religious battles” of words (mostly), over which computer language or development platform provides superior productivity. It is almost universally accepted that these tools will continue to evolve and yield higher productivity into the foreseeable future.

Given the above, why is it that the majority of developers fight the idea of an order-of-magnitude increase in software automation?

We all agree that software’s goal is automating human processes. Creating software is a human process. We are all familiar with expanding automation in our daily development activities. We regularly see order-of-magnitude jumps in other technology. Is it really such a great leap to imagine an order-of-magnitude jump in software development productivity?

It is inevitable that we will have this jump. All of us should aggressively demand, explore and search out this capability.

So, what is holding us back? The key factors are (1) fear and human nature, (2) complexity and the wrong approaches, (3) cheap labor over creativity, and (4) market factors on the leading edge.

I am excited to see the core building blocks emerging that will drive this next technology curve. The eventual fusing of several current technologies will drive the jump.

In future postings, we will explore these topics more deeply.