Hacker News new | past | comments | ask | show | jobs | submit login
Why Software Jewels Are Rare (1996) [pdf] (msu.edu)
93 points by tjalfi 42 days ago | hide | past | favorite | 73 comments



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."


I personally think that the web development industry is the software industry's peak form of rushing things to market.

So many frameworks, so many concepts repeating their form every 3-5 years...and only with pure luck you pick the one framework that will be there for the next 2 years to come.

Nobody refactors. Everybody reinvents. Everybody abandons. It's an endless cycle of catching your own tail.

If you read a software engineering book about patterns and architectures you'll quickly realize how many framworks reused a concept that is 30 years existing already, yet selling themselves as the hot new cool kid on the block.

I don't understand why lately architecting software doesn't result in refactoring anymore. I think that only through refactoring you can really understand and learn from your own mistakes.


The original arrogance is believing that you know which problem is most valuable to solve. Yes, the constant cycle is annoying but framework producers are under the same incentives as those delivering applications. There's only so much runway and at the end of the day you need something useful if anyone will adopt in slightly more useful than switching cost if you want anyone to change to your framework from another. From each attempt we gain insight and perspective that we can use to feed in to a slightly better implementation on the next tool or implementation.


Intesting - that's my impression as an outsider (mobile, not web).

> Everybody reinvents. Everybody abandons.

There's that saying about haute couture - "out of fashion" is just highly avantgarde.

That's why I build CGIs. They as up-to-date today as they were 15 years ago.


Psst, serverless computing.


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.


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/


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.


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.


So, my language is basically a DSL for Java in many regards. I basically translate Adama code to Java, and then build on the fly.

A comparable framework for some of the workloads I envision would be https://akka.io/docs/ , but then you have to live within the framework or bad things happen. My idea with the language is that I eliminate all the bad things and keep thing simple.

Where I've scratched my head on this problem with existing solutions is that you need a lot of things to align. For instance, making it possible to coordinate players easy requires having a language support async/await semantics. This lets the server coordinate you playing a card which another player can interfere with, and another player could interfere with that.

The challenge with async/await in modern languages is what do you do with the process if the future takes... hours to return? How do you handle upgrades? operations in the cloud of cattle? This is where I started to re-invent a logger for board games, but then you must treat all your game code as deterministic. If you don't, then you are in for a surprise as the server replays the log. Instead of trusting myself, I'm forging the standard library such that everything is deterministic.

The final component that gives me confidence in needing a language is the reactivity. My language is basically a text-based Excel engine with tables, objects, and global values. This means that when a player makes a move, I simply need to manipulate the state appropriately and then everything bound to that state gets computed on the fly as needed. The state also is annotated with privacy controls such that important information doesn't leak between players, and this is something that is really hard outside of a language context.

All in all, I don't really need a language to ship a single game, but if I want a platform to enable anyone to build a board game, then I need to make it accommodating.


> 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.


> 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_attribu...


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.


> 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.


I personally don't agree.

Even with something like a login form. If you keep on improving it with what you learn whenever you need to re-implement it or extend its requirements you end up with at least a re-usable "architecture", and most of the times you probably end up with big chunks of code that you can use, either the JS part, or html, or back-end logic. You now have a nice show/hide password field, your html is semantic, issues that were on the first quick and dirty were ironed out a bit with every iteration.

> But the power of software lies in it's mutability (else it's better and faster in pure hardware)

This doesn't seem at all right? The power of software lies in it doing what it's supposed to do, not introducing problems that might be costly or annoy users to the point they don't use it anymore or something better comes along and not doing what you don't expect it to do. And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it?

I also think that if you can rewrite it in one afternoon, perhaps it's ok, but I doubt the things where some semblance of quality and effort matter is when whatever is the software isn't rewritable in an afternoon.

> so the vast majority of software will break due to changing requirements or dependencies

This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.


> And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it?

You do realize that "mutability" means "ability to be changed", correct? It's value comes from being able to be rewritten piecemeal, as opposed to hardware where you'd have to design a new PCB, manufacture it, then snail-mail it to all the places it should be, then install it.

>> so the vast majority of software will break due to changing requirements or dependencies

> This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.

What you said literally had nothing to do with that except you quoted from my comment.


I’m not sure the same developers would produce much better software given more time and less pressures. It may very well end up more complex and over-generalized. I think jewels are more the outcome of passion and relentless iteration.


I have experience working in non-profit/academic open source software.

It's not any better. And has the added challenge that since it doesn't need to make money, sometimes projects keep going when they aren't doing very much useful on the order of the resources put into continued development. "Sunk cost fallacy" can be enormous.

Software is just hard.

Another context than the software industry is the "enterprise", where software is being created to support some internal business process (in the broadest sense of 'business process'). That has it's own pressures. But that software too ends up looking much the same.

The OP article really struck me, I have to think more about what to take from it, but I think there's a lot there.

This article to some extent suggests a kind of "software pessimism" -- is all software just destined to be a garbage pile? (Although the authors say "we can and must do better", the text doesn't leave me confident in that).

Software is just hard. It's also eating our world though. If it's all destined to be a garbage pile, we're in trouble -- forced to spend our lives fighting with buggy, hackable, inhuman software that acts like it wants to kill us.

one way or another, we probably need a lot less software in order to make it better software. That seems pretty unrealsitic, I realize.

I've thought before about, what would a "slow code" (like "slow food") movement look like?


Let's make it a little easier by talking about a slow code project instead of a movement. I think that could look something like Jon Blow's development of the Jai programming language, which is in closed beta after being developed for several years already. He's emphasizing the joy of programming.

He also has millions of dollars, thus, years to devote.

We might exploit this example to say about a slow code movement "people in the slow code movement would recognize at the start of a slow code project that they will be working in relative secrecy for several years".


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.


I don't have any Apple products but I think they have a reputation of valuing quality.


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.


> 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!


Software that does this: https://discussions.apple.com/thread/250315803 is likely worse than nothing at all.


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


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.


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.


There are many iTunes stories like that. A friend of mine who is a composer and singer had his original songs erased from his library, irreplaceable live recordings, because of Apple's open hostility toward files they didn't create.


iTunes was SoundJam MP with an Apple makeover. Both SoundJam MP and Audion were the shit at the time, so I recall being thrilled at the acqui-hire.

Why specifically do you hold iTunes in such low regard? The bolt-on, beyond-music functionality has always sucked, but I didn't find it wanting from a music management POV. (Although I never used it for ripping. dBpoweramp for me, thank you.)


iTunes was never as good as any of the free music managers out there at the time. It lacked most serious features that users with a real collection (of their own) might need. Anything related to finding, sorting, organizing, naming, changing metadata, moving, sharing, re-ripping, ripping at all, etc. were severely crippled. Perhaps that's because SoundJam didn't build those features. But they stayed unbuilt because Apple didn't want them.

As far as the raw UI, they were shown to the door by Zune which was a massive failure! Couldn't Apple with its money and music business success have made Zune or something even better? Of course they could. They had an early lead. My point is they chose not to because openness and control in music (or anything else) is antithetical to their business model. This adversarial view of users is also what lead to terrible iTunes bugs like eating your music, which others also recall well.


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.


> 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.


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.


This answer is how you should preface your argument. Gives people like me context. Saying Im long time mac user in a vacuum misleads small minds like mine


How's Pharo in practice? It seems really cool in demos.


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.


Agreed about their software quality, but their laptops are still the best. The keyboard was an very real issue for awhile, but now they seem sorted out and are one of the best keyboards out there. Not to mention I cannot find a non-Apple laptop with the quality of screen and especially touchpad. It's a shame too because I am trying to move further out of the Apple ecosystem, but I can not find an acceptable laptop.


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.


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.


Corporations absolutely value craftmanship. Factory owners and research labs will pay a huge premium for well designed, reliable tools and skilled employees/contractors that repair and maintain them to a high standard. I do a lot of electronics repair work for my businesses, and I dropped $200+ on a Hakko soldering iron.

I have not found the same willingness to pay for quality amongst consumers, though. Counter-intuitively, the sort of hyper-knowledgeable "pro" consumers I come across are typically less willing to open their wallets than people who know nothing.


My favorite factoid in support of this is the "craftsman home" which is mainly a marketing thing that stuck into being a descriptive thing, not so much that they were high in craftsmanship.


I think part of the problem is that in software we are not allowed to iterate like other crafts are. A carpenter may make a table every week. They only have to live with the choices made, like tool choice, wood, screws, etc, for a week and then can try something different.

When we write software it lasts for years. It's not like anybody says a year in "oops Django was a bad choice, lets try this again in Node."

We want to care about craft, but we work on the same application longer than it takes to build most buildings. We more than any other craft are saddled with choices made years ago that were made with way too much information.


Depends on the type of software. Lots of games have large application specific codebases that are written at least partly from scratch per title.


But not by the same person.


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.


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.


You say that, and yet you probably do still use perl/shell/other obscure tool that is rather old. In particularly, at the foundation layer.

BLAS and friends would be a good candidate for old software.


Right, right, but it's fresh (compiles with today compiler, links to glibc etc.) not some archaeological artifact I'm boarding.


Fair... I am not sure that changes the idea, though. TeX, as an example, stands as a jewel. Even if it has things we could and probably do criticize today, it has proven ridiculous value.


Right, right. Not arguing with article premise, just mentioning that a useful effect of useful open source software is that this stuff generally remains true.

And I'm not a zealot or anything. I just like this aspect.


I would avoid ES File Explorer Pro - requests permissions it shouldn't, has dubious ownership, and see e.g. this https://www.bleepingcomputer.com/news/security/es-file-explo...


Yeah, you should only run a version from before they got bought out. It'd be nice to have a replacement but as far as I can tell nothing comes remotely close to being as good. Tabbed browsing with source-agnostic windows (local storage, USB drive, network shared folder all treated the same) editable clipboard, editable app associations, nothing else comes close.


Used to be that there were lots of repositories of this very sort of thing. Seems they've dried up in the face of the Google algorithm.

Any leads?


I work in VFX and with the world premier bit of special effects software: Side FX's Houdini. Sure, it's a bit old and has a little bit of ui cruft (they have to get less technical users in). But overall it's a treat to work with. Such low level control over a scene and lots of easy customization.

If anyone's interested : https://www.sidefx.com/

The industry standard Autodesk's Maya, on the other hand, is a bloated POS. I've quit two jobs that made me use it and have taken it off my resume. Thinking about using it for doing my job makes my hands curl in disgust and pain.


What’s your opinion on Blender?


Haven't used it in production. I've seen some good stuff come out of it and heard its many praises. It seems like its users and devs really care about making a good bit of vfx software.

Unkindly, it looks like a kludged together unorganized open source monster with functionality smooshed every which way without consideration for how it actually gets used. Slightly better than Zbrush, which is a ui abomination.

Overall I bet it's fine and dandy if you take the time to learn its eccentricities. I fear it's very low on discover-ability due to the lack of strongly opinionated and efficient visual metaphors. But I haven't taken the time to dive into it to make a full and comparative review. Nor would I. I'm old and don't have the time or ambition to do so.

tl:dr Blender seems cluttered but ok. Use Houdini if you can, but Blender if you must. Death to Autodesk.


"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


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.


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.


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.


That is exactly what those companies do in domains whose business is not to ship software, all development is driven by external contractors, in many cases hired on per budget basis, e.g. hire contractor XYZ to deliver 5 Jira tickets, by the next budget round another contractor will do another set of Jira tickets.


What changed my mind was moving from product development into enterprise consulting, specially in industries whose main business is completely unrelated to software.

All the bonsai-like rules about software jewellery have zero value in those industries.

What those company owners and management departments care about is their main business line, as long as those boxes keep shipping or people keep buying their stuff, they couldn't care one second how the sausage is made.

It is easy to blame all the major consulting sweet shops for the quality of delivered work, while in most cases what gets delivered is what customers (e.g. management board) are willing to pay for.

Just ranting out loud, not targeting anyone.


That ability to make an informed decision is itself notably rare though. Most businesses have to rely on trust & abstract consideration, for they don't have people running the show who can visualize & see many of the forces they are working to weigh against each other.

More generally, I feel like tech needs some breakthroughs in the "create more value than you capture" (Tim Orielly 2008) sense, where it is tech itself that is the product, rather than a product built of tech, that is trying to be created. Exposing & opening the tech, making the tech accessible. This is a far off point, not one I'd want to reduce the discussion to, but I think in general we've had a lack of technical leadership that's deflated our general sense of how core, critical, & powerful this general drift is.

I very much agree, that it's all very complicated.


Isn’t it much easier to build on top of a good code base?


Yes no doubt but good and bad code is not binary. There are different levels of good and bad code. The tricky part is determine for this feature what is good enough and not so good it took me 5x for when 1x of goodness would have given me the same return on investment. As my new role of someone who pays the bills this is a lot more important where as a dev I was viewing things from an academic lens.

We don’t always do good enough... some times we need extremely well done due to the sensitive nature of the code.. it all depends.


Reading comments like this gives me hope.

There seems to be a polarized view of "jewels are worthless, just ship" or "we need more jewels". Both perspectives are dangerous.

Software-jewels have a place, but you have to be selective about what code needs to be that level of quality. And like so many decisions in software development, it's about the trade-offs.

If we're writing experimental code with a low shelf-life or internal tooling, we are better off writing code we expect to throw away completely. Writing high quality code here will take time away from making code quality high in areas where it's important.

On the other hand, if there are some subsystems critical to our business--we want them robust, extensible, and fast--they are good candidates for "jewel" quality. But you have to allow the time needed for a potential rewrite and more thoughtful architecture.


Thanks for your point of view!


> Rarely are technics given first seat at companies

Except Google, Microsoft and Apple.


Apparently you haven’t worked at those companies recently. Sounds like you may have been a very early employee.


Zilog is a famous example of what happens when no one reins in the engineers.


Famous engineer driven failures are rare. And I havent heard of zilog. Were they as famous as.. the British Aircraft Corporation..?!


Software jewels are also fragile. Change 1 requirement, and the jewel may turn to dust.


SQLite is one




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: