Duane Gran's blog

Process over programs

Software development, at heart, is the discipline of modeling business logic (or il-logic, if you will). The classic steps go something like the following:

  1. Document the existing process, such as an accounting form or communication need between entities
  2. Determine if there are any existing IT system driving the process
  3. Build a prototype or story board a solution, accounting for #1 and #2
  4. Supposing that the prototype solves the problem (or least makes thing better), go ahead and build it using whatever design/code methodology that suits the project.
  5. Deploy the system to production and commit to caring and feeding for it until doomsday or the process needs revision, whichever comes first

While this is a fine way to build software, it isn't a fine way to solve core problems. For that, I suggest we add step 1.5: evaluate the process.

How I saved my company one penny

Somedays as a developer you really know that your work affects the bottom line, and other days you are putting lipstick on a pig. This is my story of how I once saved my company a whole penny through a day of in the trenches code sleuthing. Money machine or hog hairdresser? You decide.

Execution matters

Many entrepreneurs invest time contemplating great ideas, be it for building a better mouse trap or solving pernicious Information Technology issues, but the investment is often squandered. Put simply, ideas are a dime a dozen, while execution of ideas is a rarity. I draw inspiration from an excellent article in Business Pundit:

If you want to be an entrepreneur, stop believing that ideas matter. That isn't what entrepreneurship is about. Entrepreneurs aren't idea people, everybody and their brother has ideas. Entrepreneurs are people that exploit ideas by matching them to market needs, executing them despite scarce resources and designing a business model that makes the idea profitable.

Good software has users

If you build software, manage a project or direct an IT division take a moment to answer the following question: Who are your users? If an answer eludes you, read on.

Good software has users. Understanding this simple statement may make the difference between solving imaginary and real problems. Information Technology, at its core, is an effort to pair technology solutions with domain problems, where a problem may range from generating reports to architecting massive systems. No matter the scope, technology solutions should be informed by the needs of users.

A guide for changing programming languages

Many projects will encounter a point of frustration with some aspect of Information Technology architecture and developers may clamor for a new technical solution. Changing programming languages may involve a significant rewrite of the software, which is a bad idea most times. However, if you are faced with a compelling technology how should a Project Manager approach the transition? Two personal examples may shed some light on the decision whether or not to change programming languages.

Pave the cowpath

At my alma mater, Ball State University, there is a dirt walkway affectionately known as the cowpath. It is a makeshift shortcut from one of the dorms (er, residence halls) to classrooms on the other end of campus. It emerged out of need and student's tendency to take the shortest line between two points. The cowpath has existed for decades, and unless something has changed in the last five years, it remains a dirt trodden path.

What does any of this have to do with producing and managing software? Put simply, when we observe people wearing a path that we didn't anticipate, like when they use our software in interesting or peculiar ways, we have a few options:

  1. Slap the user's wrist and tell him not to mickey with the software
  2. Analyze if the software's user interface created some confusion
  3. Observe the user closely to understand his motivation

If you do #2 and #3 you will most likely choose to pave the cowpath instead of discouraging the user from doing what he wants to do. While I wouldn't advise retrofitting a spreadsheet into a flight simulator, developers and project managers should keep an open mind about creative ways that people repurpose software. A practical example is the Friendster software product. From presentation notes given by Danah Boyd to the Supernova Conference:

What was successful about Friendster had nothing to do with its original purpose or design [dating]. Instead, users saw it as a flexible artifact that they could repurpose to reflect their social practices. As i learned how people embedded Friendster into their daily lives, i was fascinated by how it manifested itself as so many different tools to so many different people. Some saw it as an information gathering tool, allowing them to learn about friends and strangers. Others saw it as a performance tool and a venting site. It was also used as a gaming device, a distribution channel for the drug dealer, an anti-depressant for the voyeur, a popularity contest. Many also saw it as a cultural artifact necessary for all water cooler discussions.

At first Friendster resisted the use cases they didn't ordain, but gradually they saw value in what their user base wanted from the service. They were fortunate to have a flexible system, which helps. They revised their software in minor ways (pave the cowpath), but mostly they just needed to get out of the way.

The next time your users surprise you with the way they (mis) use your software, consider if the possibility that the user knows something you don't. As a consequence you may tap into new markets for your software, and at the very least, by adapting your software to the needs of the user you will make their experience more pleasant.