4 ms·

The best programmers I've ever worked with are also good business analysts. They understand the technology and the business process. Furthermore, they are also

The best programmers I've ever worked with are also good business analysts. They understand the technology and the business process. Furthermore, they are also able to communicate technical concepts to a variety of stakeholders. What Bruce is advocating for isn't new. To me it's just a logical step in any IT career. Anyone with 2-3 years experience will need to spend some time talking to end users or business stakeholders. Honing those skills will make you more employable and put you on track for a BA / Senior developer role.

da_chicken 5y ago
> Anyone with 2-3 years experience will need to spend some time talking to end users or business stakeholders. And yet, except for software that has literally been designed for use by and for developers, virtually every piece of software I've ever used feels like the person who wrote it has absolutely no idea how work is actually done. They'll take data or configuration elements that need to be seen at the same time to understand how something is coded or configured and put them on different screens. They'll create processes that are not flexible enough to support real-world situations. They'll allow nonsensical configurations or have absurd design choices -- not just "we don't operate like that" but "it's logically impossible to operate like that." Unless a developer is intimately familiar with the business process, which in my experience means they're required to eat their own dog food, then their software will suck. Unfortunately, there's a very narrow range of software that developers will be familiar with through personal, direct experience. It will be developer-specific software (IDEs, text editors, version control, compilers, service desk software, etc.) or broad, general purpose software (Excel, Word, Outlook, etc.). It starts to fall apart once you get outside those tiny spheres. Hospital Information Systems will not have a design that enforces sensible patient coding. Student Information Systems will not have a sensible system for scheduling students, taking attendance, etc. The developers don't understand what the realities and difficulties are of operating a hospital or operating a school. There are dozens or hundreds of different positions that all need to use the same system in different ways, but the system itself is only set up one way: whatever makes sense to the internal data model. It's like the the parable of the blind men and an elephant, except these blind men are trying to feel their way through building the Brooklyn Bridge. Then when the people trying to cross the bridge say it keeps falling down the developers say, "It's working according to the spec." Well, yes, because you're in the business of selling bridges, not understanding bridges.
- magicalhippo 5y ago
  > virtually every piece of software I've ever used feels like the person who wrote it has absolutely no idea how work is actually done That's why I like taking support calls every now and then. Very often I end up having to connect to the user via TeamViewer, and almost every time I learn something. It might be something trivial like some input boxes being in an illogical order, it might be something bigger. It's amazing what users put up with without complaining to us, so getting the chance to view how they work is gold for me.
- chexx 5y ago
  > The developers don't understand what the realities and difficulties are of operating a hospital or operating a school. Why not just focus on this issue? Is this expectation correct?
- kbelder 5y ago
  That just made an idea click about Excel's incredible popularity. We all talk about how it's a horrible tool for building apps and databases in... but usually the spreadsheet is build by an expert in the business domain. Sure, maybe the SKUs are randomly interpreted as text half the time... but at least it has all the columns you need, in the proper order for efficient entry and sorting. Maybe a crappy, buggy app built by a business domain expert is _better_ than a wonderfully architected app built by a developer that doesn't understand the business process.
magicalhippo 5y ago
> spend some time talking to end users or business stakeholders That's part of why I love my current job. I often have to do the whole project from figuring out requirements with customer, all the way to developing the solution. I find getting close to the customers really helps me understand how to deliver a good solution, and is also very motivating in that I see my concrete suggestions making a real impact for the customer. For example, not long ago a user asked for a new private feature. I knew that we had some customers that might be interested in it, or at least a variation of it. So I rang up a few users from those companies that I knew worked a lot on the module in question, chatted a bit with them about how their workflow was and what kind of data they had at which times etc. I used this info to come up with a much better general solution for the original customer, which was very useful for several of our customers. When sales is doing demos I frequently hear about jaws hitting floors and questions about "how soon can we be up and running?" before any price has been mentioned. It's the sum of those features that has that effect.

da_chicken 5y ago

> Anyone with 2-3 years experience will need to spend some time talking to end users or business stakeholders. And yet, except for software that has literally been designed for use by and for developers, virtually every piece of software I've ever used feels like the person who wrote it has absolutely no idea how work is actually done. They'll take data or configuration elements that need to be seen at the same time to understand how something is coded or configured and put them on different screens. They'll create processes that are not flexible enough to support real-world situations. They'll allow nonsensical configurations or have absurd design choices -- not just "we don't operate like that" but "it's logically impossible to operate like that." Unless a developer is intimately familiar with the business process, which in my experience means they're required to eat their own dog food, then their software will suck. Unfortunately, there's a very narrow range of software that developers will be familiar with through personal, direct experience. It will be developer-specific software (IDEs, text editors, version control, compilers, service desk software, etc.) or broad, general purpose software (Excel, Word, Outlook, etc.). It starts to fall apart once you get outside those tiny spheres. Hospital Information Systems will not have a design that enforces sensible patient coding. Student Information Systems will not have a sensible system for scheduling students, taking attendance, etc. The developers don't understand what the realities and difficulties are of operating a hospital or operating a school. There are dozens or hundreds of different positions that all need to use the same system in different ways, but the system itself is only set up one way: whatever makes sense to the internal data model. It's like the the parable of the blind men and an elephant, except these blind men are trying to feel their way through building the Brooklyn Bridge. Then when the people trying to cross the bridge say it keeps falling down the developers say, "It's working according to the spec." Well, yes, because you're in the business of selling bridges, not understanding bridges.

magicalhippo 5y ago
> virtually every piece of software I've ever used feels like the person who wrote it has absolutely no idea how work is actually done That's why I like taking support calls every now and then. Very often I end up having to connect to the user via TeamViewer, and almost every time I learn something. It might be something trivial like some input boxes being in an illogical order, it might be something bigger. It's amazing what users put up with without complaining to us, so getting the chance to view how they work is gold for me.
chexx 5y ago
> The developers don't understand what the realities and difficulties are of operating a hospital or operating a school. Why not just focus on this issue? Is this expectation correct?
kbelder 5y ago
That just made an idea click about Excel's incredible popularity. We all talk about how it's a horrible tool for building apps and databases in... but usually the spreadsheet is build by an expert in the business domain. Sure, maybe the SKUs are randomly interpreted as text half the time... but at least it has all the columns you need, in the proper order for efficient entry and sorting. Maybe a crappy, buggy app built by a business domain expert is _better_ than a wonderfully architected app built by a developer that doesn't understand the business process.

magicalhippo 5y ago

> spend some time talking to end users or business stakeholders That's part of why I love my current job. I often have to do the whole project from figuring out requirements with customer, all the way to developing the solution. I find getting close to the customers really helps me understand how to deliver a good solution, and is also very motivating in that I see my concrete suggestions making a real impact for the customer. For example, not long ago a user asked for a new private feature. I knew that we had some customers that might be interested in it, or at least a variation of it. So I rang up a few users from those companies that I knew worked a lot on the module in question, chatted a bit with them about how their workflow was and what kind of data they had at which times etc. I used this info to come up with a much better general solution for the original customer, which was very useful for several of our customers. When sales is doing demos I frequently hear about jaws hitting floors and questions about "how soon can we be up and running?" before any price has been mentioned. It's the sum of those features that has that effect.