Do you know your customer's business process? - Part I

Since I started developing software for a living, I have come to appreciate a common pattern, a rather detrimental one. It seems to me that there are many developers out there (very good ones too) who tend to neglect one important aspect of software development: the underlining business process.

Earlier in my career it was all about coding a solution. Developers loved to write code. I was victim of that. I loved to just listen to a customer narrate the story of what they wanted to do with a piece of software. They would describe to me what they wanted and I would go and code it. Please, do not try developing software this way. You may end up with a working application, assuming you have enough time. By the way, I'm also assuming that your goal, as a great developer, is to not build hack-applications.

Later on, in my career, it all became about testing. You got to test, test, test and then test some more. It probably saved me marginal amounts of time but not lots of it. Still it was taking too long to write an application that was not a hack-app.

Much later on, it became about spending time in the requirements gathering. If you have a good definition of the requirements and understand the requirements then you will be able to cut some time on the development (coding) activities. Oh! But don't forget to test! Well, this approach works marginally better than the other 2. However, in some shops, it quickly becomes about the requirement gathering process. Too much time is pent on that activity and the timelines get decided by some one else. You need to provide a solution quickly but guess what? You are out of time. You hack the app.

In the late 90's I spent 2 weeks learning how to use UML (Unified Modeling Language). That was the best 2 weeks I spent in my software development career. I learned about using a notation that would help me communicate better, easier and more emphatically with business users and tech-heads alike. At about the same time I learned about the Agile Manifesto (I recommend reading it as soon as you can spare 2 minutes). For more comprehensive background on the Agile Manifesto, please, follow this link.

I felt my value offerings to my customer multiplied many, many times over after getting the higher state of awareness that modeling software with UML brought to my life as a software developer . Even though I felt I could count with a much better set of tools to help build solutions, I still had foggy awareness of "something" that I was missing. I could not place my finger on it. Until I learned about Business Process.


At the core, business processes are what drive the economic engine of every organization. When you understand what that business process looks like and know it by heart, you will be able to write software that is not hack-app. When you understand your customer's business process you elevate your awareness and achieve clarity. You will write better more robust software.