Bruce Schneier wants you to make software better
spectrum.ieee.org
spectrum.ieee.org
> Bruce Schneier taught his dog to do a secure handshake
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.
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.
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. :)