A Developer is NOT a Business Analyst

Note: Every time you read a word in bold, please read it again.  It will save accidental confusion.

My issue at hand is when developers are tasked to design the business solution (not technical solution) because they believe or their superiors believe that they have the skill-set to design a business solution to solve real business problems.  Stop it! A Developer is NOT a Business Analyst!

To clarify, most developers are not business analysts.  The developers that do have a skill-set that allows them better define workflow and use cases are usually described as “rockstars” or they end up in working for themselves consulting.

First let me provide background to give some context.  I live in a professional development services, dealing with business customers in a variety of domains/industries, creating business applications.  We are often approached to create a custom software solution to solve business problems or to fill a gap.  In most cases, the business solution has not yet been designed, or has been design but is arguably not the correct solution.

Lean Six Sigma

Lean Six Sigma

In my experience, most developers are not business analysts and do not have the proper experience or knowledge of business (models) or skill set to create a business solution that truly solves business problems.  Yes, we can create exactly what a user requests.  Yes, we can provide suggestions for technical or usability features.   Yes, we can create a great technical solution.  However, we need to understand our capabilities and make the customer understand we don’t own the content or are the subject matter experts. Too often developers are put into situations by themselves, leaders, or customers that they do not qualify nor should the have the responsibility for.  Just because you can create any piece of software, doesn’t mean you should define the business solution.

What I’ve noticed with a good Business Analyst, is their ability to deconstruct the problem, and build a solution with components where the result of solution is what solves the problem.  The solution is all the pieces that put together give the expected result.


I often times visualize this as a math equation.

Assume for  A + B = C.

User requests for a solution to build “C”.  What a Business Analyst actually builds is A + B, which results in “C”.

It takes understanding the business processes, business model, and actual business problem to develop a true solution.

The old quote from Henry Ford (true or not):

If I had asked people what they wanted, they would have said faster horses.

You need the skill-set of a BA to not build a faster horse.

CAP Theorem, CQRS and Eventually Consistent

First, if you haven’t heard of Eric Brewer’s CAP theorem, it basically states that you can must choose two of three:

  • Consistency
  • Availability
  • Partition Tolerance

CQRS doesn’t solve CAP issues, however it allows you to decide independently what is important on both read and write side.

For example, you could assume a systems would be ACID (Atomic, Consistent, Isolated, Durable) compliant on the write/domain site and BASE (Basic Availability, Soft-State, Eventually Consistent) on the read side.

Eventual consistency is something that requires a change of mindset.  Because of our heavy use in ACID compliant databases, thinking about possibly having stale data blows our mind.

There are two important points about I want to make about eventually consistent data.

  • The data isn’t wrong.  It’s old.  There is a big difference here.  The data you may be consuming may not be up-to-date, however it was correct at one point in time.
  • In the real world, we use stale data all the time.

A good example, from Greg Young, was if you read the newspaper/website and notice some statistics on the unemployment rate, this is obviously stale data.  If those stats were a a week old, would this matter?  How much of a difference would a week make to unemployment rate?  Probably not much. However, there are scenarios where you want to be much closer to actual, and in these cases define an SLA.

The point is, in many situations, eventually consistent data is acceptable.

TDD with Startups and Prototypes

I was watching an old video of Jim Coplien and Uncle Bob debating TDD (and other things). Uncle Bob said:

Nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test.

At first, I did not agree with this statement.  But after reviewing it a few times, there is a keyword here that is very important:  SHIP.

A code base with a test suite that provides great coverage is useless if it does not ship.

How quickly can you get out a prototype or MVP if you are using TDD?  Would you not be better off getting a MVP out in the wild as quick as possible? Then harden it with tests AFTER you start to develop a customer base?

Never underestimate the value of a shipped software providing value to customers.

Greg Young: 8 Lines of Code

Greg Young gave a good talk titled 8 Lines of Code, discussing simplicity, dependencies, and magic.

Magic is always something I try and identify and stay away from in my own code, however I really failed to realize how much magic goes on in some of the libraries/frameworks that I often use.  Entity Framework and nHibernate come to mind.  You really should understand the magic happening in these libraries to use them.  Which is very problematic.

If you take the dependency ownership seriously, then a lot of folks developing the front-end of a “modern” web applications are in a world of hurt.  RequireJS, Knockout.js, jQuery, Bootstrap, etc, etc, etc…

Video is posted on InfoQ:


Microsoft Fakes (formerly Moles)

Problem: You are writing unit tests that involve a dependency on a 3rd party concrete class. Unfortunately there are no interfaces, nor are the methods/properties defined as virtual.

Solution: Microsoft Fakes (formerly Moles)

Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims. These are small pieces of code that are under the control of your tests. By isolating your code for testing, you know that if the test fails, the cause is there and not somewhere else. Stubs and shims also let you test your code even if other parts of your application are not working yet.


[code lang=”csharp”]

// Code under test:
public int GetTheCurrentYear()
return DateTime.Now.Year;

public class TestClass1
public void TestCurrentYear()
int fixedYear = 2000;

// Shims can be used only in a ShimsContext:
using (ShimsContext.Create())
// Arrange:
// Shim DateTime.Now to return a fixed date:
System.Fakes.ShimDateTime.NowGet =
() =>
{ return new DateTime(fixedYear, 1, 1); };

// Instantiate the component under test:
var componentUnderTest = new MyComponent();

// Act:
int year = componentUnderTest.GetTheCurrentYear();

// Assert:
// This will always be true if the component is working:
Assert.AreEqual(fixedYear, year);

Idiotic Interview Questions

Interviews questions always seem to be a topic that comes up frequently at a developer peer group I attend and while at work.  In a recent .NET Rocks! podcast, they touched on this topic and brought up the Fizz Buzz Test.  We have all been in interviews where we are given some ridiculous programming question, that is “intended” to show the interviewer your problem solving skills.  Or maybe (I think likely) they ask these questions because they are the stock questions, and everyone asks them.  It’s like asking someone for their strengths and weaknesses.  Do you really think people aren’t telling you what you want to hear.  These stock questions have stock answers.

Back to the ridiculous programming questions.   If someone asked me today in an interview some asinine array sorting question, or better yet a problem that you rarely encounter in the real world, I think my answer would be: Google.

Most of the problems that I encounter in the real world have been already dealt with.  I do not need to come up with my own solution.  I’m not arrogant enough to think that my solution is the best.  Using available resources (ie, Google) to to find the best solution to a problem seems like a better answer.  After all, wasn’t the point of the question to see your problem solving skills?  Why not ask questions related to Patterns, Practices, and Principles?  If the interviewee can discuss SOLID principles, doesn’t the Fizz Buzz Test seem idiotic to ask?

It’s not a rule book!

I was reading a blog post from a friend (@jason_pomerleau) that touched on something I have been ranting about for the last several weeks.  The idea behind this site was that anytime I felt like I was ranting or had a the slightest original thought, I would jump on here and post a short blog.  No lack of rants, just not enough blog posts.

I did have to make a quick comment on this paragraph;

And like any methodology, what’s most important is not necessarily following the recipe to the letter, but rather deriving the greatest benefit from the available techniques, and applying these in a selective and practical way to your own environment.

I agree with the statement with but want to extend it, and use Scrum as an example.  There are many Agile folks that mock the idea of a ScrumBut.  The term ScrumBut comes from the saying: “We are doing Scrum… but X”.  The problem is, the “but” isn’t always a bad thing.  Yes, often times it usually is, by masking a pain point that Scrum is exposing.  This usually results in someone saying that Scrum doesn’t work.

However, there are many situations where the “but” is because you are modifying the framework to better suit your situation, without masking a problem.  And the reason you can do this is because you understand why.

If you understand the reasons why you are practicing Scrum, then you know why each practice exists and how it applies the principles behind the Agile Manifesto.  If you’re practicing Agile, understanding the reasons behind the principles as apposed to knowing them by heart without meaning.

Jason in previous blog post was discussion “Why is more important than what” in regards to the objective of the software you are writing.  This goes much further.  Why (and why not) should be the question you are asking yourself regarding almost everything in development:

  • Why am we using document store over a relation database?
  • Why am we applying the X pattern? (and understanding the reasons behind the pattern)
  • Why aren’t we deploying more often?

Full Stack Developer

I’ve been thinking a lot lately about what is missing from a mid-level developers skill set. I was going to write a blog about how it seems like most are lacking in the area of application infrastructure (networking/servers/visualization/hosting).  This makes sense for developers who start in a larger organization and are not exposed to the infrastructure an application will be running on.

After stumbling upon a What is a Full Stack developer? blog post, it really sums up what I have been tossing around in my head.  If you notice a trend, this really goes back to my Specialization vs Generalization post.  Ultimately I believe a good full stack developer is on a good path to turning into a architect/application design.