Should programmers care about their customer's businesses?

Question

Many years ago when I was a programmer I found that I enjoyed my job far more when I was familiar with my customer's business (how they made money; what was important to their profitability, their survival; what was happening in their industry). As well as enjoying my job more I think I did a better job. But that was me, I've worked with plenty of folk who've not been interested in their customer's domain, but they still did a good - often excellent - job.

Should programmers care about their customer's business concerns?

Thanks! Clarke Ching

Answer 1

Well, it's one thing to care about a customers' business and another to be interested in a customer's business domain. If I was doing consultant work for a company that sold knitting equipment, I would still not be very interested in knitting or the world of knitters. However, I would very much care that my customer not only stayed in business but did very well. If the customer does poorly then he will not have money to pay you. :)

Answer 2

I consider it is crucial to have a good understanding on the businesses that you are building the software for.

First reason that comes to my mind is that different businesses have different needs and different types of users that you simply cannot anticipate if you never seen/used a program from that field.

So, Yes, programmers should always care and know about the buissiness, and if it's not possible to understand it propery they need to bave a BI consultant to guide them in the process of building the software.

Answer 3

I think if you genuinely care and want them to be successful it has a lot of positive side effects. In general being more engaged in your work and the results of your work means you invest more in it, enjoy the successes more, and get more out of it personally.

This is the reason teams are encouraged to engage and invest as much as possible in their work. It tends to work out best for everyone that way.

Answer 4

I suppose that depends on the nature of their relationship with their customer. If, for example, they are simply doing part time freelancing or contracting, then a programmer doesn't really need to care about their customer's business so long as they deliver quality product. Then again, if you are a full time employee, then you should care.

I think that the importance of caring about your custom's business tends to show itself in the long run. Of course you can easily compensate for a lack interest in exchange for heaps money, but that over time the power of your mantra, "but it's so much money," wanes.

In other words, would you rather be a permanent employee at Initech or Google?

Answer 5

Depends entirely on who your customer is.  We have two products that address two completely different markets, and our approach is different for both.

The first product is a point of sale system for retail busineses.  The two lead developers for this app had a couple of years of retail experience when we started out with it, but it's been a while since either worked in retail and even though we use the app to create invoices for consulting work, it's not the same as using it to run a retail operation ourselves.  To make sure our application actually remains relevant to retail business owners we need to pro-actively approach them to figure out what their needs and concerns are.  If we don't drop by at people's stores from time to time to sit down with them and look at how they use our software, we risk losing touch.

The other product is a Subversion client, which we use ourselves every day for all of our software development work, maintaining our websites and even for managing our business administration.  It is still very important to listen to customers, but because we dogfood the product alomst excessively and most of our end-users have a workflow that's very similar to ours, we can rely more on public fora and emails from end-users for feedback.

Both products are grounded in a thorough understanding of the end-users business and real-world experience of their designers in the target audiences domain.  I feel strongly that domain knowledge is always a requirement to create and maintain a good product, but when you risk losing touch with reality in the domain, go out and talk with your customers – and I mean beyond the point of bug reports and feature requests, you need to understand what their day looks like.

Answer 6

If you develop along the lines of Domain driven design, I wouldn't know how that would work without some understanding of "the domain". In a business software that would probably about what the business does. I can only quote from Evans' book: If you manage to talk with your customer along the same lines, chances are you don't misunderstand each other too much and that your software can be extended at the points that matter most to your customer.

Answer 7

It is very valuable to have insight into the customer's business because you can frequently suggest better solutions rather than just blindly accept and implement a programming specification. In that sense, the customer perceives you as a partner in creating their solution.

In the extreme case, you might wake up one day and realize that your customer, a "B. Madoff", had asked you to create a Ponzi "fake earnings report generator".

Answer 8

If you build software for those customers, it speaks volumes in both your work and your interactions with your Business people if you know more than your fair share about how the business works.

This won't hurt you as it would show interest in the company and your Manager as well as other people you interact with there will notice this. Likely they will view it as you going above and beyond what you normally need to do, again a positive benefit (as long you're not spending all your time learning the business and none of it doing your job).

Last but not least, knowledge of the business will to empower you in following your requirements more carefully, providing insight and input into different areas of the SDLC process and overall become better at writing business software.

Answer 9

Awhile ago I was on contract for a fast food chain. As part of the contract I was required to work front-line cashier for 1 week. So for a time I was probably the highest paid cashier they had. However it proved very insightful in further development of my system given the problems the employees face (this was a POS and TimeSheet system).

After that, I'm a firm believer in the belief that getting to know a client company is crucial to building a better system. In fact in any future contract if I'm qualified to do so, I'd insist on spending some time in the end user's shoes and being at the front where the action happens in a company.

Answer 10

It depends a lot on your relationship with the customer.

Me, I'm a freelancer and I tend to work with my clients' projects starting at the initial conception/spec and continuing on through doing the actual programming and deployment. Throughout the process, I try to help them find the best possible ways to achieve the project's stated purpose, which requires a significant understanding of their business and what the software will be used for.

On the other hand, if you're hired as a "heads-down coder", then you aren't expected to know anything beyond how to convert the spec you're given into running code. In some cases, you may even upset the customer/client/employer if you try to make suggestions, so any knowledge of their business is unlikely to be helpful.