[HN Gopher] Bruce Schneier wants you to make software better
___________________________________________________________________
Bruce Schneier wants you to make software better
Author : samizdis
Score : 51 points
Date : 2021-04-28 19:14 UTC (3 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| cadence- wrote:
| 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.
| Jiocus wrote:
| For anyone who's not already familiar with Schneier,
|
| > Bruce Schneier taught his dog to do a secure handshake
|
| https://www.schneierfacts.com/
| sorokod wrote:
| Also author of some symethric cyphers with funny names.
| 1cvmask wrote:
| 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.
|
| https://en.wikipedia.org/wiki/Taher_Elgamal
| meepmorp wrote:
| > Every time Bruce Schneier writes a fully general halt-
| checker, God kills a passenger pigeon. This is why passenger
| pigeons are extinct.
| wrnr wrote:
| Is he gonna start writing software? Be the change you want to see
| in the world, is what a zen master would tell you.
| elcapitan wrote:
| A zen master will hit you on the head with a stick for that
| instagram wisdom.
| chasd00 wrote:
| and tell you you're right at the same time.
| ajanicij wrote:
| That is a Gandhi quote, nothing to do with zen.
| wrnr wrote:
| I don't care about karma either
| SamuelAdams wrote:
| 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.
| magicalhippo wrote:
| > 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 wrote:
| > 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.
| chexx wrote:
| > 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?
| magicalhippo wrote:
| > 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.
| kbelder wrote:
| 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.
| chmod600 wrote:
| 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?
___________________________________________________________________
(page generated 2021-04-28 23:01 UTC)