[HN Gopher] Why Software Jewels Are Rare (1996) [pdf]
___________________________________________________________________
Why Software Jewels Are Rare (1996) [pdf]
Author : tjalfi
Score : 44 points
Date : 2021-04-03 17:34 UTC (5 hours ago)
(HTM) web link (www.cse.msu.edu)
(TXT) w3m dump (www.cse.msu.edu)
| amelius wrote:
| Software jewels are also fragile. Change 1 requirement, and the
| jewel may turn to dust.
| [deleted]
| linguae wrote:
| One of the things that I have noticed in my career is that the
| industry, in my opinion, does not seem to value craftsmanship in
| software outside of a few niches. After all, for most people,
| software is simply the means to an end, and this includes the
| software industry. Those who make software for a living have to
| deal with market pressures, deadlines, and other factors that
| sometimes conflict with meticulous design. "Move fast and break
| things," "perfect is the enemy of the good," and "worse is
| better" are the mantras of our industry, and that's because
| today's economic incentives favor functional, if imperfect,
| software over meticulously-designed software. I won't name
| examples since I don't want to start a flamewar, but there is
| plenty of software that is "good enough" but isn't designed very
| well, yet happens to be widely adopted. Likewise, the jewels of
| software don't seem to be well-adopted and seem to be restricted
| to research niches, with some exceptions. I lament this, and I
| wish I could work in a niche that favors software craftsmanship,
| but this is the world we live in.
|
| Perhaps the solution to making software jewels less rare is to
| make it easier for software engineers to make jewels by creating
| more sophisticated developer tools, so that way the quick-and-
| dirty approach just so happens to align with "the right thing."
| craftinator wrote:
| > the industry, in my opinion, does not seem to value
| craftsmanship in software outside of a few niches
|
| That's because craftsmanship in software has massively
| diminishing returns outside of a few niches.
|
| Unless you're writing some VERY highly optimized kernel code,
| some physics logic that makes a simulator run correctly, etc...
| you're writing code that gets the job done until it's replaced.
|
| A login form on a website works, until the business
| requirements for it change. Is it worth going back and
| understanding all of the fine details to make sure your changes
| don't break anything, or should you just rewrite it from
| scratch in an afternoon?
|
| This is how I feel generally about craftsmanship. There are
| some places where it's warranted for long term stability and
| incremental improvement. But the power of software lies in it's
| mutability (else it's better and faster in pure hardware), so
| the vast majority of software will break due to changing
| requirements or dependencies, and will be cheaper and less
| buggy to just replace. There's no point in finely crafting
| these replacements because eventually they'll suffer the same
| fate.
| nyanpasu64 wrote:
| Writing easily understood and simple code, code easily
| maintained and extended by corporate employees, and fast code
| don't always line up.
|
| Assembler code for old 2D game consoles is unclear, partly
| because it's not structured programming, partly from rushing
| out the door and/or generational cruft, and partly from
| talking to awkward hardware interfaces, and partly from
| optimizing performance. I've seen C code with #ifdefs to pick
| different code on x86 and RISC CPUs, which might've made
| sense as an optimization with CPUs and compilers from 15
| years ago. Duff's Device is faster on older processors, but
| sometimes slower on new processors and compilers.
|
| From what I've heard, microservices address organizational
| problems more than technical ones, and dependency injection
| may be more useful in large enterprise projects (not sure, in
| my minimal experience it creates complexity).
|
| I think that all of performance, clarity, elegance, and
| replacability (possibly linked to modularity) are values, and
| software craftsmanship can encompass one or more to varying
| degrees.
| loup-vaillant wrote:
| > _Writing easily understood and simple code, code easily
| maintained and extended by corporate employees, and fast
| code don 't always line up._
|
| Am I misinterpreting your comment, or did you just list 3
| distinct items?
|
| 1. easily understood and simple code
|
| 2. code easily maintained and extended by corporate
| employees
|
| 3. fast code.
|
| In my experience, points (1) and (2) are one and the same.
| No tension at all. Easily understood and simple code _is_
| easily maintained and extended, by anyone.
|
| When I write code, I never try to cater to some junior
| idiot. I write for myself, 6 months later. Yet people who
| see my code often compliment how easy to read, use, and
| extend it is. Junior and experts alike.
| MaxBarraclough wrote:
| > Unless you're writing some VERY highly optimized kernel
| code
|
| linguae used the word _craftsmanship_ , which covers more
| than just performance. Correctness is another obvious aspect.
| (We still write production code that is vulnerable to buffer-
| overflows, for instance.) Standards-compliance is another.
| Wikipedia has a list that applies here. [0]
|
| This is analogous to other engineering disciplines. There's
| no market for supersonic civilian aircraft, but there are
| plenty of challenges besides speed to keep aeronautical
| engineers busy.
|
| Even if you're developing 'just another website', poor
| craftsmanship might result in downtime and loss of customer
| data. It might also result in longer onboarding times for new
| developers. The list goes on.
|
| [0] https://en.wikipedia.org/wiki/List_of_system_quality_attr
| ibu...
| brutal_chaos_ wrote:
| IMHO market pressures, focus on profit, lack of care for
| quality by the developers as well as management, and so forth
| are all why software is basically shit these days.
|
| > Perhaps the solution to making software jewels less rare is
| to make it easier for software engineers to make jewels by
| creating more sophisticated developer tools, so that way the
| quick-and-dirty approach just so happens to align with "the
| right thing."
|
| That would go a long, long way, but culturally we would need to
| embrace quality over profits and I don't see that happening any
| time soon.
|
| I do believe we will make some gains in the tooling due to open
| source/collaborative work a lot of us do for fun. Granted,
| without the cultural shift, it'll be a slow, gradual change.
| neolog wrote:
| I don't have any Apple products but I think they have a
| reputation of valuing quality.
| brutal_chaos_ wrote:
| Reputation, yes, however this is no longer reality IMHO.
| Think of all those posts about how the keyboard sucks on
| macbooks, think of the posts complaining about Apple's
| quality in general over the past couple years. It may be a
| somewhat recent change, but Apple does not produce good
| quality any more. Apple is useful, but a bit janky these
| days.
| linguae wrote:
| I agree. The Mac ecosystem has long valued quality,
| especially when it comes to UI/UX. One of my favorite
| proprietary software companies is The Omni Group, which has
| made a lot of very well-done software tools for the Mac, such
| as OmniGraffle. The company's adherence to Apple's UI
| guidelines is strict, and its products are wonderful to use.
| Apple itself has also made excellent software (I'm a longtime
| macOS user), though I feel that its UI/UX perfectionism has
| slipped in recent years.
| vagrantJin wrote:
| > Apple itself has also made excellent software (I'm a
| longtime macOS user),
|
| Then how would you know how good or bad Apples software
| UI/UX is if you have only one frame of reference? It's good
| or bad compared to what?
|
| I don't think you can easily make that claim.
| linguae wrote:
| I'm not exclusively a Mac user. In the past 30 years I've
| also used MS-DOS, every version of Windows since 95
| (except for Me and server-based versions like 2003 and
| 2008), various Linux desktops, Android, ChromeOS, and
| iOS. I've even played around with NeXTstep, Haiku, Pharo,
| and Plan 9.
|
| The classic Mac OS and pre-Big Sur macOS were the best
| environments I've used from a UI/UX perspective, with
| Windows 95/98/NT/2000 being worthy runners up.
| neolog wrote:
| How's Pharo in practice? It seems really cool in demos.
| rektide wrote:
| I'm not going to weigh in on Apple but raising one of the
| most monolithic, insular, biggest capitalization companies on
| the planet to talk about software craftsmanship feels so so
| so so far from the point, from the question of software
| craftsmanship in the world. Icd rather not start the
| discussion by looking at extremes.
| mimixco wrote:
| Their UI quality is more mystique than reality. iTunes was a
| particular abomination among many. Not only did it have a
| terrible interface which conformed with nobody's standards
| and looked nothing like any other Mac app, it also had a
| propensity for eating your music, especially music which was
| yours and acquired outside the Apple store. Hardly a quality
| program. Apple apps are still famous for focusing more on
| keeping you in their walled garden than on making the best UI
| for the user.
| CharlesW wrote:
| Assuming you mean Apple Music (iTunes was an okay MP3
| player/ripper, but is dead), I consider it the exception
| that proves the rule. Enjoy the schadenfreude of this
| recent Apple Music for macOS review:
| https://www.youtube.com/watch?v=gE8ZikfrpFU
| [deleted]
| mimixco wrote:
| No, I meant iTunes. Their willingness to make that was a
| harbinger of Bad Things to Come, ala the review you
| linked.
|
| Apple _had_ some good UI ideas in the past. For a
| fleeting moment, they were the best. But eons ago they
| sold out the user to sell him a lifestyle /subscription
| system built around keeping people from leaving. This
| vastly compromised their UI designs to the point of
| making them frustrating and sometimes futile.
| loup-vaillant wrote:
| I once read a composer complaining that iTunes has
| deleted his master records and "helpfully" replaced them
| with compressed files (lossy compression of course). I
| tried to find it to prove your point, but found _this_
| instead:
|
| https://discussions.apple.com/thread/250315803
|
| Software that loses data _it_ fetched or produced is an
| accident. Software that actively search for and deletes
| data it has nothing to do with (in backups!!), is
| _malware_. People went to jail over such things.
| 908B64B197 wrote:
| > iTunes was a particular abomination among many
|
| It didn't have to be really good: It was better than any
| other digital music store out there!
| loup-vaillant wrote:
| Software that does this:
| https://discussions.apple.com/thread/250315803 is likely
| worse than nothing at all.
| [deleted]
| mathgladiator wrote:
| I'm in the process of crafting my jewels over the next few
| years, but I have the position of being almost retired. I'll be
| able to take my time and focus on crafting good software.
|
| The process is not going to be commercially viable for many
| years simply, and this is why crap persists because that crap
| does solve real problems today.
|
| You can check out the project: http://www.adama-
| lang.org/docs/why-the-origin-story
|
| It's going to take a long time until I get to a 1.0 release.
| victorbojica wrote:
| That's a very interesting tool/language. I don't really
| understand how it works, but I kind o understand the idea
| behind it. I think.
|
| Will it be used to build online board games (like an engine)
| or to "generate" one?
|
| There's also another nice tool for simulating games. Not
| really in the scope if your project, but around the games
| topic. https://machinations.io/
| mathgladiator wrote:
| At core, it's an infrastructure language such that it
| enables the people to come together without fuss.
|
| As a developer, I can code the back-end for a board game
| without thinking about the failure modes for
| disk/db/network and I code as if I'm a single process (you
| know, the way we coded as kids). The mental model mirrors
| if you gather all your friends to play a game with the same
| keyboard and mouse.
|
| As a service, it is a combination of EC2/Lambda for
| compute, Ably for notifications and connectivity, some DB
| for storage of state, and workflow for orchestration of
| people transactions. All within a single package.
|
| As a game designer, my hope is that I can make it easier
| enough that the rules backing a game can be built and then
| evaluated with simulation and artificial intelligence. I
| have rough prototypes of this, but I implemented the back-
| end of Battlestar Galactica and had a random bot just play
| it. That's a remarkable achievement in a way, and now the
| question is how to train a system to search for patterns in
| looking at what decisions are made with a JSON document as
| the state of the game.
| Kinrany wrote:
| I love the idea! I've been wishing for multiplayer game
| development to be free of networking troubles for a long
| time.
|
| Commercial players are finally entering this space, with
| Roblox getting more attention and Unreal/Fortnite moving in
| this direction.
|
| Are you sure you need a new programming language? It _seems_
| like a DSL or a framework would do for the problems you 're
| trying to solve, and you'd save time for yourself by not
| writing a standard library, and for your users by letting
| them use a language they know.
| rektide wrote:
| "Why Software Engineers should become CEOs"[1] proposes that the
| engineers have a better sense of value, of what will work, &bthat
| they should be in charge more.
|
| Rarely are technics given first seat at companies. We talk about
| being product organizations or engineering organizations but I
| feel like in both cases there is still enormous political
| processes that most engineers face in their urge to do the right
| thing. And sussing out, helping the company internalize which
| bits are of lasting value, done well, &bought be enshrined &built
| upon, sharing & syndicating these notions out: it re-becomes
| political almost immediately.
|
| I had a rather long-winded reply to "software is a losers game"
| that surmized a lot of the challenges & environments of software
| development together[2]. I think it helps explain some of why the
| field so rarely, clearly excels.
|
| [1] https://www.tlt21.com/why-software-engineers-should-
| become-c...
|
| [2] https://news.ycombinator.com/item?id=26661164
| dnndev wrote:
| As a dev turned CEO, it's complicated. Very few products / use
| cases need to be more than good enough out the gate. Most
| software good enough is exactly what is needed. It's not a one
| size fits all. As CEO and CTO I need to decide what's ok to be
| good enough and what isn't.
| slt2021 wrote:
| even communicating that to developers and making sure they
| internalize this requirement can be a big helper.
|
| what I think happens is that companies try to hire the best
| talent they can find for their money and tell fairy tales how
| they are modern and foward-looking company with the vision
| that is going to change the world - and of course devs will
| internalize that and will try to apply craftsmanship to their
| daily work, and then you will have problem of shipping on
| time and on budget.
|
| if managers told exactly and upfront that the products must
| be hacked together and asap and the quality is NOT the goal,
| that the goal is to ship shiny new thing quickly to impress
| VC suits in next N months, and get their funding check and
| continue this loop until the company finds its exit in form
| of IPO/acquisition/etc - everything would be honest, upfront,
| efficient, and conflict free.
| marcosdumay wrote:
| A large part of the problem is about differing time
| horizons, and the fact that low quality is always slower on
| the long term. So, it's not ok to just say "we don't need
| quality, we need speed", because quality will imply on
| reduced speed sooner or later.
|
| On the best places, a lot of the communication problems
| come from the fact that managers tend to willfully ignore
| the fact that low quality is a losing proposition at the
| long term, and developers tend to willfully ignore the fact
| that short term only gains have value.
|
| On the worst places, communication problems tend to come
| from the fact that management wants to artificially prop
| the numbers before they get a way to jump ship, defrauding
| everybody else, so they simply can not be honest.
| 908B64B197 wrote:
| > Rarely are technics given first seat at companies
|
| Except Google, Microsoft and Apple.
| TedShiller wrote:
| Apparently you haven't worked at those companies recently.
| Sounds like you may have been a very early employee.
| TedShiller wrote:
| SQLite is one
| Causality1 wrote:
| I'm sure most HN readers have a folder somewhere full of
| installers and executables for years-old software that remains
| unmatched by anything modern. I've never seen a CD ripper better
| than CDex, or a site archiver better than HTTRACK, or an Android
| file manager better than ES File Explorer Pro.
|
| It's interesting to note that the companies behind half of my
| favorite programs were bought out and began distributing malware
| before shutting down.
| renewiltord wrote:
| Interestingly, as a predominantly Linux user, I have no such
| folder. Notably, while the utility software has consistently
| improved, the UX software has definitely had ups and downs.
|
| And I can't substitute my GUI shell that easily so I keep the
| default and suck it up.
| JulianRaphael wrote:
| I'd argue that this not only applies to software but to all of
| human creation. Very few creators are craftsmen and very few
| consumers value craftsmanship. Creating software jewels requires
| mastery of many skills, many of which are not purely technical
| but involve an understanding of human behaviour. These skills can
| only be acquired by studying a field with a certain kind of
| devotion that very few people have. Real craftsmanship happens
| when work becomes intuitive, which happens once the basic skills
| have been perfected and there is enough understanding of other
| areas that might seem tangential, but further enhance the
| craftsman's creativity on a level that can't be really learned
| from manuals or documentation. There are very few employers that
| allow you to work like that.
|
| Then you need people who are willing to pay for the product that
| the craftsman creates. Corporations generally don't value
| craftsmanship. Consumers are not willing to pay the price. In the
| past, you had royals and aristocrats who would pay for works of
| craftsmanship for prestige. Who are the modern patrons of
| craftsmanship? I would love to see some Silicon Valley
| billionaires fund software craftsmen, but very few of them put
| their money to work in such impactful ways.
___________________________________________________________________
(page generated 2021-04-03 23:01 UTC)