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.
> 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.
> 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.
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.
> 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.
With how I see software being developed in most companies, I don’t think there is much time left to consider social aspects in any significant ways. Today’s development is too agile for that. Analyzing social aspects and impacts would require deep thinking and there is no room for that in agile development.
Having interacted with him in real life over the years I have to second that hilarious site. He never disappoints. Taher Elgamal is another giant of the security space who never disappoints as well.
We may need to re-think fundamental concepts of software design
For instance, code reuse. Should we really reuse that piece of code in a radically different context?
Or versioning. Is the next version really better for all users?
Or software size. Right now, we seem not to care whether software is kilobytes or gigabytes, as long as it seems to have the same behavior. Is that reasonable?
Well, maybe we shouldn`t [do it yet one more time], because they have been already rethought. It`s just that most programmers are not familiar with them. But some rediscover them. Have you ever heard of David Parnas?
To make code reuse possible one has to design it the way that makes it possible. And anyway it can be reused only if requirements to this piece of code are same (or weaker).
And obviously, code reuse can happen only after "code use" has happened successfully. And some (many?) programmers struggle with this too. :)
19 comments
[ 3.2 ms ] story [ 66.3 ms ] threadWhat 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.
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.
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.
Why not just focus on this issue? Is this expectation correct?
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.
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.
> Bruce Schneier taught his dog to do a secure handshake
https://www.schneierfacts.com/
https://en.wikipedia.org/wiki/Taher_Elgamal
For instance, code reuse. Should we really reuse that piece of code in a radically different context?
Or versioning. Is the next version really better for all users?
Or software size. Right now, we seem not to care whether software is kilobytes or gigabytes, as long as it seems to have the same behavior. Is that reasonable?
To make code reuse possible one has to design it the way that makes it possible. And anyway it can be reused only if requirements to this piece of code are same (or weaker).
And obviously, code reuse can happen only after "code use" has happened successfully. And some (many?) programmers struggle with this too. :)