Business Agnostic Software – Buy rather than Build

A solution that you can apply to any business at all, is what I might call business agnostic software. If you feel the urge to build such software, think again.  Buy it instead.

Examples of business agnostic software

An insurance company maintains correspondence with the insured.  The company buy’s or subscribes to an email service.  It does not build the email service from scratch.

A bank generates statements, and various notices that the government mandates.  For this, a bank might need a template engine that generates PDF.  Buy that template engine.  The bank itself will have to build the templates for these business documents.

All companies have business processes that they wish to start, track, execute, and end.  This is what BPM (Business Process Management) engines are for.  Buy that BPM engine.  The business can implement its business processes using the BPM engine it buys.

Health insurance companies that are in the Medicare business, receive beneficiary information from the government.  Many rules determine how the company responds to this information.  A company could use a rule engine to manage these rules.  Buy that rule engine.   The company should stick to only implementing the rules.

Wait, here is the simplest example.   Why do you buy a database management system?   You don’t build an alternative to SQL Server, or Oracle, do you?

Why avoid building business agnostic software

The primary purpose of an Enterprise IT shop is to support the business. Learning the business, analyzing it, modeling it, and implementing it, is a significant challenge in itself.  Focus on that.  Master that before taking on other problems.

Business agnostic software focus on more general problems.

Take rule engines for instance.

  • What is a rule?
  • How can rules be combined to produce new truth?
  • Devise an algorithm that can execute 10,000 rules in a few seconds.

An insurance company could use a machine that answers those questions.  Does a health insurance company want to spend time and money on building that machine?  For most companies there will be little value in it.

People spend their lifetimes studying these fundamental questions.  There are PHds galore in rule systems.  Let them build the rule engine. You confine yourself to identifying an effective rule engine, and using it well.

We do build business agnostic software though

I am surprised by how often Enterprise IT shops end up building business agnostic tools.

In my work experience, I have seen home grown solutions to these problems, which are best left to the experts.

  • A web framework
  • An Service Locator/IOC container
  • A rule engine
  • A BPM engine
  • A scheduler

We can never avoid this completely.  Start with management that lacks engineering savvy, throw in gung-ho developers, and mix with institutional inertia.  Less than optimal decisions will happen. So it goes.


Some companies do focus on fundamental problems.

They have deep pockets.  They have the means to invest in fundamental research.  Their business model, their operating ethos, includes such effort.

Their business problems are of such scale and complexity that currently available solutions are inadequate.  They must invent new solutions themselves.

Unix and C came out of  AT&T.  Ericcson created Erlang.   UML came out of research at GE, and IBM, among other places.  Xerox pioneered Graphical User Interfaces, and Object-Oriented Programming.

Ask yourself.  Are you one of these companies? I am confident most Enterprise IT shops would say, no.


Nobody told me I had to be a teacher

A Tech Lead has to be a teacher? Why didn’t someone tell me?

We have this C# method. It used to be good. Small. 25 lines or less. All at one abstraction level. See Bob Martin.

One of the kids, from offshore as it happens, had a bright idea. Next morning I wake up to find that the method is now a 100 lines.

I want to tell the kids. The method is too large. No method should be more than 25 lines. And they will chop it down pronto. They are good kids. But. There is no telling how they will chop it down. If they know how to tell a story in simple, clear steps, I have not seen evidence of it yet. They can’t seem to find the shortest, most direct route, between A and B.

Ask them how to go from D.C. to Baltimore.

They will come up with this. I-495 from National Airport to I-270 and Frederick. Then take I-70 to Breezewood. Break East on the PA turnpike to Harrisburg. Finally, come down I-83 to Baltimore.

That was fun. We got to write a lot of code. Oh what a lovely route it was.

They won’t stop, look around, and find 295, the Baltimore Washington Parkway, a straight shot between the hearts of D.C and Baltimore.

So I have to teach them how to chop the method down. But there is a problem. I know how to do the work. I don’t know how to teach it to another person.

I can say, make sure all of the code is at a single level of abstraction. They have no idea what I am saying. I don’t blame them. What does the word ‘abstraction’ even mean? I don’t know how to describe it man, I just know it when I see it. You know the button that starts your car. That’s an abstraction. You know what I mean? You don’t? Well, bloody hell.

So now on to Plan C. I redo the method myself. You know, I give them advice, and an example. Guess what happens. Nothing. Two days later the silly drama repeats itself.

It turns out, they could not care less about Clean Code. They know the programming language. They know some libraries. They are decent at problem solving. They get a kick out of flipping switches and seeing results. They are having fun. They feel no inclination to examine what they are doing. Stop, step back, dig deep, see under the surface, unlearn old habits, cultivate new habits. Further, after a couple of Sprints, they also learn that I will clean up the code myself.

It took me a long time to understand how to write Clean Code. It took me much practice to do it instinctively. Do you know how much I rewrite? How am I going to get the kids to adopt a regimen of study and practice? How am I going to get them to show interest and sustain it? How am I going to get them to care?

I am only a working engineer. You are asking me to not only teach, but also to motivate.

All of this, I have to do while a project is going on; under the gun, to deliver something.

It is not going to happen.

You are not going to get Clean Code.

Unless. You hire the right people.


Focus on skills rather than role

The project manager said, that is not your role, stay in your lane. I held my tongue. But it struck me that I no longer understand the fixation on roles.

While developing software, we must make certain choices. Some of these choices are expensive to change if you get them wrong. These choices constitute architecture. See Grady Booch. Architectural decisions must happen. How does it matter who makes these decisions, as long as they know what they are doing? We need Architecture. We don’t need Architects.

The same argument applies to other work. We need business analysis, we don’t need business analysts. We need testing, we don’t need testers. You catch the drift.

If one person can do business analysis, and solution design, why not let them do it? If one person can write code and test, why not let them do it? With each fewer person in the team, you avoid an information hop. With each fewer information hop, you avoid some information loss.

Here is another argument. A designer must know the business that she creates solutions for. Why not let her learn the business first hand? Let her do the business analysis. A developer, makes better choices in the code, when he knows the essential business. Why not let the developer talk to the business? If the developer has the necessary skills, drop the middle man. Knowing what Agile has taught us, do you still want a developer that cannot test? Let the developers test; eliminate a whole moving part in pipeline.

If one person can do a job, why would you want three? If three people can do a job, why would you want six?


Don’t make users learn codes in place of business terms

Here is a good example of bad user experience I came across recently.

In training, I was told the various status codes that health claims would be in.

  • 125 for a pending claim.
  • 483 for a paid claim.
  • And so on.

I was also told codes that indicate the results of business jobs

  • 0 means a claim has been priced completely.
  • 58 means claim has an unknown provider.
  • 26, 27,28 are violations of Wyoming state laws regarding Medicaid claims for black lung disease.
  • And so on.

Then they tested us on these codes.  I did poorly on the test. Who can remember all these damn codes?

So, I have a question.

Why can’t a pending claim simply be marked ‘pending claim’? Why must you come you convert that plain English status to a number?

If there are technical reasons for representing that status as a number, fine, do so.  However, why must I, the business user, be exposed to that number? Why can’t you keep the number to yourself, and tell me the claim’s status in plain English?

Why are you making me remember arbitrary numbers, when natural and easy to understand business terminology exist?

And last but not least, if the business user did not see these numbers, you can avoid a whole chunk of training.   Is that anything but a good thing?

This is an example of “Design is an act of communication“.

This is user experience.


Architecture I believe, architects not so much

So I am part of the Enterprise Architecture group now.  That makes me laugh.  In my admittedly narrow experience, architects have never seemed relevant to my responsibilities.   That is part of why I took the job.  See if I could figure out what this is all about.


I have come to think of myself as an engineer.  I build things that people use.   Point me to a business problem.   I can find my way from the problem to a solution, soup to nuts.  Part of this work is architecture, the decisions that are expensive to change.   The work also includes business analysis, and solution design (tech-agnostic, and tech-centric).  Then there is construction of the solution – coding, and testing.  Last but not least, deploy the solution, and support it.  Drive this whole ship forward with agility.

On a day to day basis, my job is to do whatever needs done to get work out the door.  Every day finds me doing this, that, or all the work mentioned above.


I have been a working software engineer in several different environments.   The architects that I have come across in that journey have been of little help.

  • Have architects had knowledge that I did not? Not that I ever saw.  Anything they told me, I could pick up off the internet in a couple of hours.  Often, a little due diligence on my part would reveal the weakness in their choices.
  • Had the architects created solutions, which I could use, as is, to do my work?  In my personal experience, no. Many of them considered themselves above what they called, ‘development‘.
  • Did the architects have skills that I could borrow?  Could I say, look, I have a problem, can you solve it for me, or can you teach me to solve it?  This never happened either.

So, why take the job

There has to be more to being an architect than I have seen.  If that is true, I would like to find out what I have missed.

Architects seem to have more access to both business and executive IT management.  It would be useful to see the world from their point of view.

An engineer solves business problems.   The architect role gets me closer to the essential business.  Engineering starts there.  Now, fewer people will  be surprised when I ask, wait, what business purpose does this serve; why must we do this.

In any event, the die is cast.  Let’s see how it rolls.



Build vs Buy – asking for an engineer

When a build vs buy discussion comes up, a few questions start to rattle around my head.  I suspect this is the engineering side of my brain acting up.

Skills you don’t want

Supporting a business with a computing solution is an intricate dance between several players.

It is analysis of the business problem, large and small-grained design of a solution, construction, testing and delivery of the solution, all enabled by effective communication between people, agile planning and execution.

Which of the above work are you expecting to avoid by buying rather than building?

What skills will no longer be necessary, when you buy instead of build?

A business machine

A person buys insurance from us.  Over the years, as that person and we do business, a lot of information accumulates.   This information is in various media.

  • Paper that we send back and forth
  • Electronic text that we send back and forth
  • Still pictures
  • Moving pictures – video
  • Audio recording

To run our business, we must be able to do the following.

  • This information must reside somewhere.
  • We want to be able to search for stuff in this information.
  • We want to view this information when necessary.

Now, consider a machine that promises this.

  • Here is a box.  The box has a hole.  Drop your information in this hole.
    • Anyone can do this.   My 3 year old niece can do this.
      • This is your information repository.
  • The box has a screen, and a keyboard.  When you want to search for something, ask the question on the screen.  We’ll find and show you what we think might answer your question.
    • Anyone that knows English and your business can do it.
      • This is your search
  • When you decide what you want to look at, the box will bring up that material to you, as you put it in the box.  It will come out of a second hole.
    • This is your view.

If this machine existed, I would buy it.

The interesting question is this. Look at the skills in play.  You only need people that know the business.  And you need the cash to buy the machine.  A guy with a trolley to wheel the machine in would also be useful.  You need none of the drama that we think of as IT.

What skills do you want to acquire, maintain, and manage.  There is your build vs buy decision.

Mistakes you want to avoid

What mistakes, errors, failures will buying avoid?

What mistakes are you looking to avoid?

The analyst gave the developer a table of numbers, which affects a customer’s bill.  The developer discovered that the industry specifies a formula, which generates those numbers.   He used the formula and generated the table himself.   He found that his table and the analyst’s table were different.

The developer asked the analyst to review the tables.   The analyst said she did, and the table was fine.  She was talking about her table.  The developer thought she meant his table.   The developer implemented his table.

The developer had made a subtle error in floating point calculation.    His numbers were wrong.   This led to a small increase in the bill that customers got.  We got wind of it only when the customer complained.

The developer and the analyst built something wrong.  What can you buy that will make their work, and associated error, unnecessary?

Communication problem

When two people collaborate, they will misunderstand each other sometimes.   You can avoid that ubiquitous human snafu only if they never have to communicate with each other.   What can you buy that will accomplish that?

What makes a man a man

We speak to people within and without the organization.   We use phones.  We buy phones.  We don’t build them from scratch.

We communicate via written word.   We buy paper, and pens.  We don’t make paper.   We buy a word processor.  We don’t build a word processor.

We want to maintain a correspondence with people.   We buy or subscribe to an email service.  We don’t build an email server and client from scratch.

We built a web application that accepts a beneficiary’s enrollment application.  We did not buy this application.

What makes the word processor and that enrollment web application different, which caused us to buy one, but build the other?


Developers must know the business domain – I

Knowledge of the business domain is essential to developers.  They must know the business as well as the business folks know it.

We have all worked in environments where the business analyst’s word is gospel.  The analyst specifies a solution, and the developer translates it verbatim into code.

This approach to software development is less then optimal.

Blind football

Imagine sending a running back onto the field blindfolded.  We tell him, never mind that you cannot see a thing.  The analyst will relay  instructions to your ear.  Follow them to the letter and Bob’s your uncle.

  • Run 6 yards on a 37 degree angle to the left.  Your left, not mine.
  • Now tack right, 82 degrees, and run 15 yards at a speed of 26 miles per hour.
  • Wait, 300 pound linebacker at 7 ‘o’ clock.  Wheel, dummy, wheel.
  • Uh oh, too late.  No, wait.  The linebacker got tripped by his own cornerback!

See, the defense has blindfolds on too.  In fact, all 22 players on the field are blind as bats.  They are unseeing puppets, lumbering about, whose strings the business analyst is pulling.  Don’t you think there will be stumbles?  You bet there will be.  The business analysts have to be superhuman to get everything right all the time.  Your team must loose the blindfolds.

Pre-empt the bug

Business folks and analysts are as fallible as the next person.  There will be holes in the information they provide.  These gaps can cause  errors.  Developers must recognize and fill those gaps so that they can avoid those errors.  The alternative is to let the error happen, hope that someone catches it, then fix the error.   How can this ever be better than avoiding the error in the first place?  


Agile, by First Principles

Agile gives me the warm and fuzzy, because like all good systems it can be characterized by a small set of rules, first principles, from which we can derive all other relevant lessons.

first principles

Arguably, the Agile Manifesto, is the most famous attempt to lay out the first principles of the agile approach to software development.  The Agile Manifesto comes in two forms – an elegant and concise one, which is shown below, and a slightly longer, more expository one that I will leave you to discover.

Shorter Agile Manifesto

The problem with first principles

First principles are distillations of wisdom that practitioners gained only after a lot of experience.   For that very reason, they often make little sense to the newbie engineer.  We read the words and some of us ask, “Really?  Why ?”.  We don’t have an answer.  I know that is how it was for me.   Eventually, I acquired the critical mass of hard knocks that were necessary to see the inevitability of those first principles.

These days I seem to practice Agile almost instinctively.   So much so, that I struggle to explain what I am doing, and why I am doing it.   In trying to unpack how I go about software development,  I tried to write down the working set of principles that I work by.

Once the words were on paper, I could see how they derive from the Agile Manifesto.  It reminded of a line from Gandhi, “I’ve traveled so far. And all I’ve done is come back… home.”

A very personal agile manifesto

Below, you will find my working principles for agility.  Notice that my words don’t exactly match those of the Agile Manifesto.  That is as it should be.  My own personal manifesto, so to speak, is necessarily colored by my particular work experiences, and my personal strengths, weaknesses and prejudices.

Again, let me emphasize, this is not meant to be consumed blindly.  Ask yourself why this is valid. Think about what implications these ideas have.  Don’t be surprised if you do not understand or even agree with some of these.   This works for me; this, among other things, makes me an effective IT worker.

  • The only acceptable ‘status’ is working software that delivers business value.
    • Don’t tell me the status. Prove it.
      • Where is the code? Let me read the code. Let me see it running.
      • Where is the test? Is the test correct? Is it adequate? Let me see the test working.
  • The earlier you know the status the better.
    • Short iterations.
    • Frequent feedback.
    • Continuous integration.
  • If you can’t answer the question, “what is done, and what remains”, in terms that the business understands, you’ve got nothing.
    • User stories, in strictly business terms.
  • Change is the only constant.
    • You will never get correct nor complete business requirements at any one instant.  The same applies to solution specifications.  Roll with it.
    • No design nor solution will ever be right the first time.  Roll with it.
    • Priorities will change.  Roll with it.
  • Information is indispensable.   Documentation, and meetings are incidental.
    • Putting words on paper, and communicating are two different things.
    • Just because you talk, talk, and talk, does not mean you are communicating anything useful.
  • If you are not putting software in production, for business to do business with, you’ve got nothing.
    • All the process in the world, all the fancy tools, the “best and brightest” people, mean nothing, if you are not delivering.
    • The answer to every question of the kind, “is this the correct process, is this Scrum, is this Agile”, is one simple thing.
      • If it helps you deliver, yes.  If you are not delivering, none of it matters.
  • No battle plan survives contact with the enemy“.
    • Human beings are unreliable.  Human judgment is unreliable.
      • Estimates are less correct, the farther out into the future they extend.
      • You will never anticipate everything that can go wrong.
      • Every process will break down.
      • Remember, Eisenhower’s advice, “In preparing for battle, I have always found that plans are useless, but planning is indispensable”.
    • You must be able to adjust and keep moving forward.   How?
      • There are no short-cuts.
      • This comes entirely from the attitude, ownership, knowledge, and skill, that people on the ground can bring to bear.

Is it a Bug or an Improvement – Irrelevant to agility

I see development teams struggling with the question – is this a bug, or an improvement.  A team that is agile (exhibits agility) would not care.

All the same to me

Tickets come my way.   Some are labelled bugs, and others, improvements.   To me, whose only mandate is to get the damn work done (aka agility), they all look the same.  What I do in response to either a bug or an improvement, is exactly the same.

All of the work requires analysis.   Gather all of the information that is available (documentation from client and analysts, production data, existing code, other tickets,  tests), and separate the essential business requirement from the solution that supports the requirement.  Then make sure that all stakeholders (clients, analysts, managers, developers, testers) have the same view of the matter, problem and solution.  Often, what they ask for is not what they need, and it is sometimes necessary to improve the solutions they specify. This requires constant and nimble communication.   Next construct the solution, which includes testing what we have constructed.  Finally, deliver the solution.

Every ticket is this same dance.

Why care, exactly

I can only think of two reasons for fixating on the difference between a bug and improvement.

First, the green-eyeshade brigade use the difference to figure out who to charge for the work.  A bug forces the development team to swallow the cost.  An improvement can be thrown into the client’s bill.

Second, it might help us figure out who to blame, or to use a more charitable perspective, it might point out where there is room for improvement.  A bug implies the developer messed up.  In cases where the bug is discovered in production, the finger sometimes points to the tester.   An improvement implies the business analyst, or perhaps the client missed something the first time around.

Of the above two reasons, I have sympathy only for the former, the billing problem.  This is mostly because I am low on the totem pole, and know very little about money matters.   Allow me to punt on this.

The latter reason leaves me cold, as you will see below,

What am I gonna believe – statistics or my lying eyes

Numbers can lie.

It is hard to have faith in statistics that classify work as bugs and improvements, when everyday I see my comrades-in-arms struggle to distinguish between the two.  More often than not, we shove tickets into one bucket or the other so work can move on. Typically, some power-that-be is breathing down our necks, or the task management tool is forcing us to make a selection.  Come time to review the work, we all know that the pretty pie charts, which the managers pass around, are nonsense.

I don’t need statistics to know the folks that I work with.  

I work with business folks, development managers, analysts, developers, testers, tech-writers, and so on.   After I spend a couple of weeks in the trenches with them, I know what their strengths and weaknesses are (don’t look now, that’s agility).

Take a developer for instance.   I read a developer’s code.  That tells me how she thinks through a problem.  I know if she can tell a story in simple, straightforward terms.   Can she find the shortest, most direct path between points A and B?

Consider a business analyst.   I read the documentation he creates.  That tells me if he simply knows the business or if he indeed is good at observation and analysis.  Does he see only the surface of things, or can he lift the hood, and identify the patterns and sub-structure that the surface covers?  I will know if his communication skills are adequate.   Can he accurately, clearly, describe what the business is, and what they are asking for?  The more I know the business (agility) the easier this gets.

I use the applications that they specify and build.  I know if they have empathy.  Do they know their users?  Can they walk in the user’s shoes?

I watch how they negotiate one on one conversations, and meetings.   This tells me if they know how to listen.

You get the idea.  Every little thing that a person does is a breadcrumb I can follow, especially if I know how to do that work myself (agility).

My recommendation – chuck it

If at all, only the bean counters need to worry about whether a piece of work is a bug or an improvement. Hide this question from the people that actually do the work. This question is irrelevant to the conduct of the work.   If you hear someone in your development team kvetching about bugs and improvements, make them buy lunch for the whole team (agility).


Focus on Agility, not Agile

For some time now, folks have been emphasizing that we have lost sight of agility, while frantically pursuing Agile.   There is little value in dogmatically following one Agile methodology or the other, Scrum for instance, while loosing sight of underlying purpose of such methods(in a word, agility).

So much Agile, so little Agile

To put it another way, Scrum, in and of itself, is not important.  Rather, why Scrum makes the recommendations that it does, is the important thing.

Take just one small example.

Scrum recommends we have a daily standup meeting.   I have been in teams that hold these meetings religiously.   However, it soon becomes clear to everyone attending the meeting that we are just going through the motions.   The meeting is just another way to waste 15, to 30 minutes of time every day.  In these environments I learned precious little in standup meetings.  Well, I did learn how many different ways there are to talk a lot without saying anything.

When I really want help from a team member I find a way to talk to that person on my own, one on one.   If someone else wants something from me, they come and find me, either electronically, or physically.

If I want to learn the status of the work, in my capacity as a tech or team lead, I pull down the code, build and run it.   I test the code myself, and I learn things that nobody tells me in standup meetings.

Information is essential.  The meeting is not.

If I was working with peers whose skills I had confidence in, and whose word I could take implicitly, the standup meeting may give me the information I am seeking.   However, more often than not, what I hear in a standup meeting falls well short of a full wallet.   Fine. I am not an engineer for nothing.  I don’t need that standup meeting to know exactly where each of my team members are.  I have other ways of skinning this cat.  This is not Scrum.  However, it surely is agility.