99% perspiration

Software perspectives from an ancient geek

Domain-Specific Languages and Simplicity: Not Mutually Exclusive

Oct 12

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

The benefits of using a well-designed Domain-Specific Language (DSL) are such that once trained we frequently forget that we are using one. Consider the traffic light: Imagine the user experience if the red-yellow-green lights were replaced by text descriptions of what to do at intersections, authored by each municipality. Those simple “commands” of color, position and shape clearly communicate the intersection domain.

Imagine if building enterprise applications was as easy as navigating an intersection.
Of course, the manufacturers of the lights, poles, controller electronics, optical sensors, etc., may not think that the traffic intersection DSL is so simplistic.

Using DSLs in the enterprise today is more like being the manufacturer than being the driver. The cost and complexity involved in building a finely-tuned DSL have often been more expensive than just “doing it the old way.”

But this is changing – tools and techniques exist that can radically reduce the complexity and time to market of building enterprise applications using DSLs. A basic roadmap Digital Architects follows is:

  1. Clearly define your problem domain.
  2. Don’t build what you can effectively buy.
  3. Start small and rapidly deliver a proof-of-concept.
  4. Deliver the main project using the principals of Agile, especially “deliver working software early and often”.

A recent project for one of our clients provides a good example of how this process can work. This project was the subject of two recent articles in Dr. Dobbs Journal and InformationWeek.

Dr. Dobbs Journal
InformationWeek

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.

Kindle review from a technologist viewpoint

Oct 27

Posted by Jon Barcellona in Supporting Tools | 1 Comment

I am a heavy reader.  Much of my workday is spend reading – normally on a computer screen.  During my leisure hours I consume both technology books, non-fiction and novels.  Frequently I spend more hours in a day reading than I do sleeping – I don’t sleep much.   When  not reading, I am often composing, designing, or architecting systems – again staring into a computer screen.  Needless to say, I suffer from frequent eye strain.  The computer monitor backlighting takes a heavy toll on my over 40 eyes.

Enter the Kindle.  I was attracted to the Kindle because of its “e-ink screen” display.  Having used the Kindle DX for a month now, I can tell you it is easy on the eyes.  It really is just as easy on the eyes as paper.  After a long day of abusing my eyes, I can relax with a good book on the Kindle and simply enjoy.  I can also move PDFs, blogs and other technology or work related documents from my computer onto the Kindle and read without the normal eye stress.  I am on the road frequently, so when I do need to unwind with a novel, I can search, purchase and be reading in a few short minutes.  These were the primary reason I bought the Kindle and it has fully met my expectations.  I give it a 5 star rating in this regard.

Ok; having met my primary needs, I will succumb to human nature and consider my secondary needs – let the whining commence…

Regarding novels or other non-photo intensive pleasure books, I really have no complaints.  I do have a single concern; 20 years from now, how do I re-read one of the books that I am buying for the Kindle today.  Not having the answer to this question, has already caused me to delay a couple purchases.

Regarding technology books, the Kindle really only adequately addresses one of my three main use cases;  initial reading of the book to get an overview of the technology.  If you are a technologist, you are used to constantly balancing trade-off to find the best solution.  As an overview reader, the Kindle is great regarding ready access to materials, physical space requirements, briefcase travel weight, as well as the easy on your eyes quality described above.  It is a little slow with page refreshes for speed reading and the highlighter is not as efficient as using my yellow marker in a paper book, but overall I would rate it 4 stars.

Where the Kindle really lacks is in the other two use cases:  using the book as a quick reference, and copying code for use in building sample applications.  First the quick reference;  When I am learning a new technology, I highlight the book, sticky-note bookmark key sections, and frequently flip back and forth aiding my absorption.  The Kindle has similar constructs and capabilities, but the speed in which you can navigate is radically slower.  So much slower that it is a real barrier to effective use.  Many technology books also include a PDF, on CD or downloadable, which also allows a more rapid key word search and navigation than using the Kindle.  This speed issue is so significant to my methods of learning, that I would have to rate this capability as 2 stars.

Regarding copying sample source code from the book:  Once again the Kindle offers a way to mark text in the book, clip the text into a separate file and then copy this file to your computer, and finally search the text in this clipping file for your specific sample code.  Due to the timing and complexity, this is not really a practical sequence.  Of course, if you have a paper book you will have even less options (scan plus OCR).  But as mentioned before, many technology books include the PDF for the book or at least the sample code.  In its current state, I would rate the Kindle a 1 star in this capability.  Fortunately, Amazon can easily solve this problem.  If you purchase a book that normally includes a CD with the PDF, and you buy the Kindle version then also include the PDF in the download.

A final note: Most of the shortcomings of the Kindle for my use with technology books can be easily solved by including a Kindle Reader for the Mac (and I guess the Windows guys can have one too).  In fact, if the Kindle version had the same sync ability between the Kindle and Mac, then the solution would be far superior to the paper book plus PDF version, since bookmarks and clippings could also be synced.  It is rumored that this is on the way – see PC Week article – so at least for now I will continue to purchase tech books on the Kindle with a cautious eye towards the Kindle Reader for Mac release dates.

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.

W = IE2

Oct 6

Posted by Jon Barcellona in Perspectives | No Comments

Wisdom = Intellect x Experience2

Don’t you think this is a marvelously self serving formula for an old guy to use? Ok, so we can argue about whether experience should be squared, cubed or otherwise adjusted. Hopefully, we can agree on the basic concept that growth in experience contributes more to wisdom than having a high intellect.

Also, I think it is important to recognize that all of these elements are highly localized. Great wisdom in one area does not even mean competence in another area. (I call this the Hollywood Political Advice Rule.) After all, who would you rather perform your appendectomy – an average surgeon or a brilliant attorney?

If you are having a little difficulty with the concept of “localized wisdom”, perhaps you would feel more comfortable using “expertise”. Just be aware that I really mean more than just expertise. As Webster describes it “the quality of having experience, knowledge, and good judgment”

Experience is gained three primary ways:

  • Education is the introductory level to experience which includes learning the basics. For most of us this is some form of “book knowledge” or a formal training program.
  • Mentoring is when someone personalizes and guides you through rapid experience growth heavily influenced by their own experience.
  • Live it. Nothing helps you grow better than making a huge mistake or living through a transformative experience.

This site is about the creation of software, an area were I can share some wisdom. I will offer references to places where you can gain education, attempt to provide meaningful mentoring (your feedback will help me here), and share some of my experiences. More importantly, I hope to direct you to some key areas where I believe your invested time and passion will create great opportunities to make huge mistakes and live though transformative experiences.

Imagination is more important than knowledge.

Albert Einstein

One final note: The problem with experience is that it is based on what has already happened. My greatest career successes were things that “wise men” knew were impossible. I was too ignorant to know, so I accomplished them anyways. (More on this later.) Paradigm shift thinking normally comes from the rebellious, passionate and sometimes ignorant. So, learn from the wise, but trust your intuition.