18 ms·

How boring should your team's codebases be

186 points by meadsteve 4y ago

pharmakom 4y ago
Perhaps a controversial take: it’s difficult to write boring code in the common boring languages because they are not powerful enough to express the problem domain without accidental complexity.
- klysm 4y ago
  I agree with this. The biggest thing that’s missing for me is sealed sum types. We’re getting there but progress is slow.
  - therealdrag0 4y ago
    Does Scala have that?
    - erik_seaberg 4y ago
      Scala has sealed traits, which may only be implemented in the same file, and pattern matching must be exhaustive. At a glance, Java 17 has something similar (JEP 409 sealed classes).
- baby 4y ago
  It depends what you are trying to write. But I’ve seen people complain about the lack of generics in Golang, and I’ve also seen really great cryptography code in Golang (TLS implementations, etc.) I wouldn’t write a compiler in Golang though.
3045638437 4y ago
- meadsteve 4y ago
  - raydiatian 4y ago
    - 01152991766 4y ago
benrow 4y ago
Good write up. Sometimes novelty comes from outside the team. For example, cross-department re-platforming efforts, vendor changes, and long running migration projects. This can all lead to inconsistency, which needs to be managed so it doesn't get out of hand. This should be factored in to a 'novelty budget' too in my opinion. A large department may have a slice of applications considered legacy-legacy, others just legacy, and some starting to move to the new stuff. I think this is more likely to happen in companies which have been around longer - there's more accrued tech debt to deal with, there are more applications to migrate, and projects to add new functionality don't go away. Another drawback to novelty is when keeping up to date with security vulnerabilities. If you have a common stack, then the problem is less granular. Google have their monorepo, which (I believe) means their applications are all built against the same dependency tree, so it's simpler to keep track of upgrades. Novelty is essential though to keep up with the innovation around us. The question is how to find the right blend of novelty (high benefit, low risk) and stability (easier to manage, maintain, and onboard engineers).
Kwpolska 4y ago
Boring and battle-tested, not antiquated, but also not some fancy new overhyped thing. I've worked in a project with a very fancy tech stack: fancy language, fancy data stores, fancy API style. Hiring was hard (not many people know $fancyLang, most people were internal transfers working with something boring like Java), $fancyDataStore1 had weird failure conditions that made it difficult to scale, $fancyDataStore2 had even weirder failure conditions, and did I mention a custom framework for it all? On the other hand, some level of fancy is still good for everyone: functional programming patterns can make all codebases better and more correct, async and things like fastapi in Python, perhaps Kotlin in the JVM world, the new .NET and ASP.NET Core in C#/.NET land (then again, who would want to write Web Forms in 2022?). But for datastores, relational databases are always the way to go.
- baby 4y ago
  > But for datastores, relational databases are always the way to go That seems like a pretty controversial statement
KronisLV 4y ago
Edit: I rewrote this as a blog post of my own, where I expand upon some of the suggestions, might be more readable: https://blog.kronis.dev/articles/how-boring-or-novel-should-your-technology-choices-be https://blog.kronis.dev/articles/how-boring-or-novel-should-... Overall, I'm tempted to agree, whilst keeping in mind that you sometimes definitely need a little bit of novelty, which the author brings up at the end of the article as well. Here's a few bits of my personal experience, where some novelty helped greatly in these past few years. Personally, I'd say that something like 12 Factor apps are a good and supposedly new approach (using mechanisms and approaches that have been around for a while) to let you look at software written in different languages pretty much the same from the outside. For example, you use environment variables for configuration, write lots to STDOUT, don't cripple your own horizontal scalability by always reaching for local storage (e.g. when S3 might be better suited) or local application memory (e.g. when Redis might be a good idea). It's nice to have those sorts of suggestions in one place and all of the sudden you escape XML or Tomcat setup hell, and can look at Python apps and Java apps similarly from the outside: https://12factor.net/ https://12factor.net/ Similarly, adopting containers has been a good solution, both because it allows achieving what people historically didn't bother with when having the opportunity of using systemd, but also because all of the sudden your applications are like phone apps - that can be launched in a consistent format on any server that you need. And you get health checks, resource limits, automatic restarts, bind mounts, port mapping and internal DNS, all of which you will never build in environments where the DevOps knowledge or resources (time) are not there. Note: Kubernetes might be too complex for some setups, as HN loves to point you, something like Nomad or even Docker Swarm also still exists and works: https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ (just linking this in particular, because it's just a small step up from Docker Compose, the pinnacle of simplicity) Speaking of which, infrastructure as code is great! Using something like Ansible is definitely a novel thing to do at first, but cutting off my team's write access to the servers and making them use GitOps with code review for the configuration changes has been a solid idea. No more wondering why some random configuration exists, or why it was changed N years ago, now you can just look at Git. No more fat fingering bad changes, and even if you did something like there's also code review. No more risks like Knight Capital of partial deploys and if something like that were to happen, you'd get a CI notification about what's wrong. Just describe what you need on the server and let those hundreds of actions execute every morning (or after every commit/merge) automatically, ensuring a mostly consistent state - and way more lazily than learning Nix/Guix: https://www.ansible.com/ https://www.ansible.com/ Furthermore, adopting the "ingress pattern" where all of your apps are in some internal overlay network, but talk to the outside world through instances of Apache/Nginx/Caddy/Traefik is brilliant! No more wondering about how to set up SSL certificates in each of the different application runtimes or even framework versions. No more worrying about setting up rate limits for each application individually, no more worrying about context paths for how things are deployed - you can configure all of that in your web server, even if you don't use a Kubernetes Ingress controller. Oh, and forget something like jQuery from the old days, especially when you'd integrate with numerous low quality plugins that wouldn't even work that well half of the time. Just use something like Vue with PrimeVue/PrimeFlex or any other premade component library, with Pinia for state management. You avoid the trouble of using React with Redux (though React Query is nice) or the complexity of Angular, while still getting the benefits of writing small, mostly self-contained application components. No more thousand line JavaScript controllers, no more messing around with global state, or god forbid using something like AngularJS. And with JSX, it actually ends up feeling more convenient to write front end code, in addition to Vue getting hooks right, better than React IMO: https://vuejs.org/ https://vuejs.org/ But the actual applications? Most of the time, they should be more boring. Using Java? Just go for Spring Boot or Dropwizard; something like Quarkus or Vert.X are nice, but not quite ready yet. Using Node? Look at Express.js, it does everything you need. Python? Django or Flask. PHP? Laravel or Symfony. Ruby? Rails. Every time I've seen someone go for a non-standard solution or actually writing their own framework, it's been an utter dumpsterfire. Good luck debugging some uncommented code that has not enough tests when there's a production outage and the few code comments that you might stumble upon are in Lithuanian or something. Databases? As a rule of thumb, go for PostgreSQL or MariaDB/MySQL. If you need data storage, use something S3 compatible. If you need key-value storage, use Redis. If you need document storage, either store JSON in your RDBMS or cautiously go for MongoDB. In each of these spaces, there are one or two established options and using anything outside of those should only be done when you have person-years to throw at every problem, e.g. the expertise and the $$$ to innovate. In most circumstances, just use what has worked for other people well, as long as their circumstances are similar to yours. (a bit long winded, but just felt like writing a bit today)
pwm 4y ago
It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors. How to make the "right" choice of unusual is where the interesting questions lie but that is highly context-dependent and can't easily be generalised into a blog post.
- meadsteve 4y ago
  This is a very good point. There are definitely "risky novel" choices that could make your company a success. But I've also seen many teams drowning in a soup of random tech choices. I'd love to be able to write some more specific advice on this topic but mostly I just want people to be mindful of the impacts of their choices and actively choose risk rather than having it sneak up on them.
  - paulryanrogers 4y ago
    My first time as a team lead I saw value in little side experiments on non-core parts. Now I think that's only OK if there is time and budget to roll them back if they prove to be a bad fit. Otherwise they accrete and become a drag on velocity.
- rTX5CMRXIfFG 4y ago
  Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.
  - berkes 4y ago
    ...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.
samsquire 4y ago
What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there is a new framework or new library or new technology introduced. I learn from whitepapers and reading English descriptions of people's problems. I find this easier than reading someone else's code. Code is extremely powerful but it has a very high maintenance cost and change costs. Just getting up to speed on the Postgresql codebase or the Linux kernel or any other system tool is hard work and an investment. You kind of need to work 40 hours a week to get familiar with a codebase to be effective in it. But I can get familiar with a problem outside the context of a codebase by reading a whitepaper and writing some code. Reading a whitepaper feels more effective use of time than reading someone's codebase. You need to jump around a lot of code to understand the codebase. I think the effort for the ideal solution is underestimated. People abstract to their own understanding. And that abstraction might not be intuitive to other minds. I would prefer to work on a codebase that solves problems effectively than a codebase that is novel.
- sshine 4y ago
  I can't help but think that FOSS is the key to sharing the lineages. Every single place I worked, people just want to make code work, not readable.
- bdg 4y ago
  > I would prefer to work on a codebase that solves problems effectively than a codebase that is novel. I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of those teams). But it's crazy boring. There's no frameworks to download, not dependencies to update, no big brand pages. It's just following some very simple rules about where to put different kinds of complexity, very strictly. It's a hard sell in any programming ecosystem because it has no brand power. I've debated create the "no framework" spec around this. I even have a tool that can enforce the standards in CI. I just don't know if anyone would actually care.
pydry 4y ago
This (and a few other similar articles) make me feel that there ought to be more emphasis on recognizing "good novelty" vs "bad novelty" rather than "more novelty" vs "less novelty". The word "budget" frames the question wrongly, I think. If there are 4 new technologies on a project and the team were insistent that they each solved a lot of pain I'd be less averse than I would to 1 new technology that they adopted because it was "cool", "made by google" and "everybody [cool] is using it".
- bad416f1f5a2 4y ago
  > If there are 4 new technologies on a project and the team were insistent that they each solved a lot of pain I'd be less averse than I would to 1 new technology that they adopted because it was "cool", "made by google" and "everybody [cool] is using it". Programmers always insist that the new flavor of X solves a ton of pain. Occasionally they are right, but more often than not programmers adopting four new technologies- if they ship at all - deliver what Rich Hickey called “a knit house” in one of his talks: a system that solves a problem, sometimes in a pretty way, but is never able to be extended or grow. Sometimes the actual software is fine enough, but the choices are so novel that it ends up being maintained by one or two people who get it, and growing the team is a nightmare. Either way, it’s a knit house.
01152991766 4y ago
jiggawatts 4y ago
Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any such thing. Just hit the build button and "copy to deploy". For about a decade I used to turn up to that customer annually for "maintenance", which primarily involved importing some CSVs that changed every year, and also updating the logo images and icons to match any rebrands. In that time the system had two million users, went through 4 OS upgrades, 3 database upgrades, and went through the 32-bit to 64-bit upgrade also. The underlying runtime had 3 or 4 major updates, depending on how you count it. Zero outages, no problems, only the occasional performance regression that could be fixed by poking the database statistics to get things back in their groove. The problem was... You see, all of the above was a problem, because it didn't keep me employed. I was not the "hero" for saving the day. Entire teams of people weren't involved. There was no visibility at the senior management level. Nobody got scared, or had to throw money at it, or hire consultants to review it. So it had to go. It was replaced by a system that cost about 500x as much (a 9-digit sum), got rolled back for failing to meet requirements, and then got additional funding and was eventually forced upon its hapless users. That, apparently, was doing things "properly". That got everybody involved. Everyone got their beak wet. All the way up to government ministers and their lobbyists. Multiple consultancies were engaged. Reports. Audits. Reviews. This is why we can't have simplicity: because it doesn't scale.
- agumonkey 4y ago
  > You see, all of the above was a problem, because it didn't keep me employed. I was not the "hero" for saving the day. Entire teams of people weren't involved. There was no visibility at the senior management level. Nobody got scared, or had to throw money at it, or hire consultants to review it. there are a few other instances of that: - an old article about Michelin (french tire manufacturer) quoting some scientist of theirs "We can make a million hour tire.. but what would we sell" - recently people said their rust code cause too much downtime for coders because it was too stable too early flip side of the same issue: - very often people game their work to ensure benefits: stash duties for later so you can appear busy, or overwhelmed (and claim promotion because you have so much to do) The global system doesn't reward to true optimization, it allocates people on useless tasks, at best for lower risk, but smart people doing things solid and fast could be using their talents on other problems.
eatonphil 4y ago
Just as one tiny counterpoint, the company I work for [0] builds a database written in Zig, not C. We implemented our own consensus using Viewstamped Replication [1], not Raft. And we built our own storage engine on LSM trees rather than use RocksDB [2]. A lot of this we built ourselves so we can do FoundationDB-style deterministic testing [3] of the entire system which would not be possible with off-the-shelf libraries because they are not deterministic. Another goal was to not allocate memory after startup. A goal that most third party libraries would disrupt. Sometimes the boring options do not further the technical goals of your project. :) [0] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle [1] https://pmg.csail.mit.edu/vr/liskov12vr-abstract.html https://pmg.csail.mit.edu/vr/liskov12vr-abstract.html [2] http://rocksdb.org/ http://rocksdb.org/ [3] https://apple.github.io/foundationdb/testing.html https://apple.github.io/foundationdb/testing.html
- meadsteve 4y ago
  Agreed. Though not strictly a counterpoint. I do enjoy novelty (and benefit from it). I just want the right amount of it
- bazoom42 4y ago
  That is not a counterpoint. If you said your choices did not have any cost or risk compared to the “boring” choice, that would be a counterpoint.
- losvedir 4y ago
  Ah, I think this is actually a very interesting example. My understanding is that TigerBeetle started its development under the company Coil, and was eventually spun out to its own company. I think this post my almost be directly speaking to Coil's decision to fund an in-house, specialized, database project written in Zig. More power to you guys for actually getting to work on such a fun project, but I wonder if that was a poor decision on Coil's part, as reflected by their eventual decision to jettison that part of their tech?
  - deleted 4y ago
    [deleted]
valenterry 4y ago
The codebase should be as boring as the developer is experienced and the project is complex. In other words: a total beginner will find any codebase interesting/exciting and if the project is just complex enough, it will benefit from some techniques/technologies that are not familiar to most people and therefore not boring. Yeah, you can absolutely overengineer, but it's not like every codebase were better off if it's "boring". Also, we make progress. Before, statical typesystems had a benifit but also made code much more verbose and were sometimes very annoying. We improved here, but it means that someone has to be the first one to use a new language with helpful features. Is rust boring? No, but that doesn't mean it's not the best choice for some teams and projects.
Philip-J-Fry 4y ago
There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases. * Complex code can be a hindrance to onboarding new developers. Boring code can be a hindrance to onboarding new features. * You often end up in a situation where you're reinventing the wheel and you're spending increasing amounts of development time on keeping the wheel round. At some point you've got to consider a ready-made solution to your problem or consider hiring more people to deal with it. * Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high. Creating a company off the back of a flavour-of-the-month tech stack isn't a good idea. But I can't see how any large software company can scale without having a bit of spice somewhere.
- sorokod 4y ago
  Developer can be a programmer or a software engineer ( my definitions). Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Software engineers tend to be interested in delivering robust and correct features. Consequently they are more conservative. When companies hire, they should be clear what sort of developer they want. Programmer in a software engineering role will damage the code base and eventually leave in frustration.
  - thow232329 4y ago
    > Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.
lorey 4y ago
related: "choose boring technology" https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246
andrewstuart 4y ago
I disagree with the fundamental premise put forward here. Software should be written to meet specific needs. And those needs should be defined. And it’s likely a software project will have many tens of needs defined. And amongst all those needs it will become clear what technologies fit the needs. A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome. Saying “projects should be built with boring technologies” is the equivalent of saying “projects should be built to NASA launch spec reliability”. That MIGHT be true, but having a predefined idea of what the requirements are puts the cart before the horse. Requirements come first, then after that come statements about how things will be done. My guess is that systematic definition of requirements will result in very very few projects “built using boring technology”.
- qaq 4y ago
  My experience is that requirements are almost orthogonal to what stack will be chosen. CTO going to a conference, tech lead being bored, founder having a friend who knows "shit", developers padding resume and so own impact the choice way more than actual requirements. 99.999% of the projects can be done using any mature lang + PostgreSQL or PostgreSQL compatible newSQL variant.
- meadsteve 4y ago
  If I was to rewrite my blogpost to fit your second sentence I would title it: "Please consider onboarding new staff as a need for your software". This is just another consideration when architecting. I absolutely will use cutting edge tools if they are needed. But we just need to think about it a little.
  - andrewstuart 4y ago
    Indeed the availability of developers who know the tech stack is a key requirement that should be defined and assigned an importance level. And if you’re working in a business building a modern web application then it’s extremely hard to imagine the stakeholders being happy with software developed using absolute lowest common denominator tools techniques and libraries, as advocated by the “boring software” movement. Competitive advantage and the expectations of customers leads to the need to use modern tools techniques and libraries. And in fact developers deserve these things too because they tend to make things easier more powerful and more reliable. If the stakeholder who is paying for the project says “can we have an animated user education intro”, and you say “no because we use boring technologies and our developers might not understand how to use the animation APIs” them I think your job would be at risk pretty quick.
porker 4y ago
Working on a not-yet-launched Web app, where the backend and frontend both use CQRS, and hoops are jumped through in the name of "purity", a more boring codebase would be appreciated. Velocity would be higher and new hires onboarded in less time.
- berkes 4y ago
  But the two main questions are: Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? Boring doesn't have to be big-ball-of-mud, but the architectures you mention exist exactly to avoid big balls of mud from growing. And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?
  - porker 4y ago
    > Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? So far there are zero clients and multiple pivots. The boring alternative needs only to yield higher velocity to be worthwhile, otherwise funding runs out before market fit and the current architecture achieves zero. > And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data? Everything is stored in a popular RDBS. CQRS makes logging all data changes easier, but that is the only time intermediate states are used. If we did event sourcing I'd be keener on the architecture.
photochemsyn 4y ago
The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any novelty issues and help people grasp what's going on. The simplest format discussed seems the best for most cases: https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md https://github.com/joelparkerhenderson/architecture-decision...
- Kwpolska 4y ago
  Where do you see the reinvention of UML within ADR? I wouldn't consider ADRs to be that; I'd say ADRs are meant for important decisions with important consequences, not a documentation of every single design choice and every single part of the project, as UML proponents would do.
  - photochemsyn 4y ago
    Some of the ADR discussions seem to revolve around trying to create a formalized 'use anywhere' ADR model which does looks suspiciously like UML. The general concept (a historical record of the development of the architecture) sounds good, but a one-size-fits-all approach sounds like a bad idea. ADR approachs should probably be heavily customized to fit each project/codebase. Some people might say, "but if we had standardized ADRs we could efficiently compare different codebases" but that's going back to UML.
pkrumins 4y ago
If anyone wants to write boring tech full time (PHP 5, CSS 2, HTML 4, and regular JavaScript), let me know. I’m hiring!
- meadsteve 4y ago
  Php 5 would not be boring and safe. You'd have some interesting challenges writing in an unsupported language version
  - pkrumins 4y ago
    There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.
    - meadsteve 4y ago
      The excitement comes when security issues are discovered in no longer maintained code
      - pkrumins 4y ago
        There are no security issues.
        tchaffee 4y ago
        That's a laughable claim. https://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=604&sha=d8a9f07b702ae6252893a7ef73f2f2812bbcbb8a https://www.cvedetails.com/vulnerability-list.php?vendor_id=... And just 10 days ago: Code security company SonarSource today published details on a severe vulnerability impacting Packagist, which could have been abused to mount supply chain attacks targeting the PHP community. https://www.securityweek.com/critical-packagist-vulnerability-could-have-allowed-php-supply-chain-attack https://www.securityweek.com/critical-packagist-vulnerabilit... And this source says PHP is the 2nd most vulnerable server-side language in the world. https://www.thewebmonkeyonline.com/php-security-issues-you-need-to-protect/ https://www.thewebmonkeyonline.com/php-security-issues-you-n...
lifeisstillgood 4y ago
95-98% should be boring. The other 2% buys you the room to be boring - keep the meta-programming and macros in a small well defined area that does well the bits that boring programming cannot touch.
anyonecancode 4y ago
Another aspect of "boring" is note is that ideally the implementation is boring, as in not surprising. Currently working on a codebase that's a pretty standard frontend stack, but omg is it not boring. I wish it was. Instead, it's exciting as in "this function claims to remove items based on a filter, but actually it does the opposite." I might go so far as to argue that being boring (ie predictable and consistent) in your implementation is more important than being boring in your tech stack.
andrewstuart 4y ago
Here’s a question for you: “To what extent should developers use advanced programming language features?” I worked on a project once that had lots of sophisticated code in it. One of the senior developers objected however when I suggested we use typescript decorators. He said other developers might not understand it. Consider what happens when the question is phrased differently: “To what extent should developers use unfamiliar programming language features?” Well, all language features are initially unfamiliar. It’s a matter of opinion, but I think developers should use whatever language features they want, and all developers working on that should be expected to be active in learning unfamiliar techniques that they are implemented in the code. It’s extremely unhelpful to say that language features are “too advanced” or “too unfamiliar” to use.
- paulryanrogers 4y ago
  Some features are more naturally intuitive than others. Consider an 'if' statement and a monad. How much talent is available that's capable of understanding and using the latter effectively? How much time would be needed by a new hire to come up to speed? If you need intermittent help from contractors then will they be able to hit the ground running? Over time the bar does rise, and I hope that trend continues. Yet it's undeniable that there are limits like human lifespan, and how much people and companies are willing to invest in education and training before doing the actual work for which they're compensated.
  - hnthrway 4y ago
    Most companies are willing to invest just about nothing into education
twodave 4y ago
Timely—I had a conversation about this with a friend a day or two ago. There is a definite trade-off between novelty and productivity. IMO putting as much novelty into the parts of your domain logic that differentiate you from competitors as possible is the best trade-off. You want your complexity and learning curve tied up in the “magic” parts of your software, not the mundane pieces.
lr4444lr 4y ago
Unless your software's value is actually a matter of CS research, it has to serve the bottom line of the business functions its built to facilitate. Sometimes thinga like hyperscale or super intense data redundancy or functional complete provability is a consequence of these needs, but they are not the prime directive. Almost all bad choices seem to stem from that misalignment.
didip 4y ago
I have come to learned that there’s no answer to this “problem”. Even if you stick with tried and true framework, eventually that framework aged, and then developers start complaining that the framework is arcane. For example, how many HN readers here know WebObjects? But the flip side is equally problematic. How many times do we have to change frontend frameworks? Just to render some divs on a web application? Somewhere in the middle seemed to be the right answer. Just build the web application with new-ish technology like Go or Rust or Elixir, and then sprinkle some JS like HTMX for interactivity.
draw_down 4y ago
ryanbrunner 4y ago
I think something that has served me well with these decisions is only considering novel tech if it does a better job of solving a problem we have right now. If the problem can't be measured yet, it's not worth working on yet. Start with something that is as boring as possible, it'll become obvious pretty quickly where the pain points are, and consider doing something novel for those.
pawelwentpawel 4y ago
From a perspective of a coder on a team, I think that strategically selecting which novel things to learn is a good thing career-wise. Fun aspect aside, one gets paid to learn new stuff which can later result in better future opportunities. As an example, as a junior dev back in 2015 or so, I was told to use one of the very first versions of Swift to develop a production-ready mobile app. Was it fun? Totally! Did I learn a lot? Absolutely! Did we almost trash the project and had a massive delay because of the early bugs, problems, refactoring with new updates, and because we were still learning? Hell yeah! The final payoff was pretty good for developers, but not for the final business objective which was getting a product out ASAP. Our users didn't care about what tech we used. Following from the above, I think it's important to distinguish two different aspects of the novelty - one is completely new tech ('global' - new to everyone) and the second is tech that's new to the team that is about to use it (let's call it 'local'). Global: That's the hole we got into using the first version of Swift. The team got stuck with problems that no one has ever had yet and we had to invest our time to solve them. The biggest risk was ending up with a completely new problem and no guarantee that anyone on your team will be able to solve it. There is no Github issue for it and no helpful stranger on Stack Overflow. It's pretty bad if it happens in a critical area. From a project perspective, I'd say it's better to wait for someone else's time and money budget to iron those problems out first if you want to increase your chances of having a production-ready product within a predictable timeframe. Local: This comes with a different set of risks. If you're working within a larger organization, how many other developers know this newly introduced tech? If the team that has introduced it quits, will there be anyone able to pick it up? If your project is on a critical deadline, do you have enough time to let developers get up to speed? I'd think about this decision from the perspective of investment. Ironically, I have also experienced the reverse - some companies use tech so old that developers have to learn it as something completely novel. The only dev that maintained the codebase might be retiring and the option is to rewrite or hire a person with a spark for archeology.

186 points by meadsteve 4y ago

Perhaps a controversial take: it’s difficult to write boring code in the common boring languages because they are not powerful enough to express the problem domain without accidental complexity.

klysm 4y ago
I agree with this. The biggest thing that’s missing for me is sealed sum types. We’re getting there but progress is slow.
- therealdrag0 4y ago
  Does Scala have that?
  - erik_seaberg 4y ago
    Scala has sealed traits, which may only be implemented in the same file, and pattern matching must be exhaustive. At a glance, Java 17 has something similar (JEP 409 sealed classes).
baby 4y ago
It depends what you are trying to write. But I’ve seen people complain about the lack of generics in Golang, and I’ve also seen really great cryptography code in Golang (TLS implementations, etc.) I wouldn’t write a compiler in Golang though.

3045638437 4y ago

meadsteve 4y ago
- raydiatian 4y ago
  - 01152991766 4y ago

benrow 4y ago

Good write up. Sometimes novelty comes from outside the team. For example, cross-department re-platforming efforts, vendor changes, and long running migration projects. This can all lead to inconsistency, which needs to be managed so it doesn't get out of hand. This should be factored in to a 'novelty budget' too in my opinion. A large department may have a slice of applications considered legacy-legacy, others just legacy, and some starting to move to the new stuff. I think this is more likely to happen in companies which have been around longer - there's more accrued tech debt to deal with, there are more applications to migrate, and projects to add new functionality don't go away. Another drawback to novelty is when keeping up to date with security vulnerabilities. If you have a common stack, then the problem is less granular. Google have their monorepo, which (I believe) means their applications are all built against the same dependency tree, so it's simpler to keep track of upgrades. Novelty is essential though to keep up with the innovation around us. The question is how to find the right blend of novelty (high benefit, low risk) and stability (easier to manage, maintain, and onboard engineers).

Kwpolska 4y ago

Boring and battle-tested, not antiquated, but also not some fancy new overhyped thing. I've worked in a project with a very fancy tech stack: fancy language, fancy data stores, fancy API style. Hiring was hard (not many people know $fancyLang, most people were internal transfers working with something boring like Java), $fancyDataStore1 had weird failure conditions that made it difficult to scale, $fancyDataStore2 had even weirder failure conditions, and did I mention a custom framework for it all? On the other hand, some level of fancy is still good for everyone: functional programming patterns can make all codebases better and more correct, async and things like fastapi in Python, perhaps Kotlin in the JVM world, the new .NET and ASP.NET Core in C#/.NET land (then again, who would want to write Web Forms in 2022?). But for datastores, relational databases are always the way to go.

baby 4y ago
> But for datastores, relational databases are always the way to go That seems like a pretty controversial statement

KronisLV 4y ago

Edit: I rewrote this as a blog post of my own, where I expand upon some of the suggestions, might be more readable: https://blog.kronis.dev/articles/how-boring-or-novel-should-your-technology-choices-be https://blog.kronis.dev/articles/how-boring-or-novel-should-... Overall, I'm tempted to agree, whilst keeping in mind that you sometimes definitely need a little bit of novelty, which the author brings up at the end of the article as well. Here's a few bits of my personal experience, where some novelty helped greatly in these past few years. Personally, I'd say that something like 12 Factor apps are a good and supposedly new approach (using mechanisms and approaches that have been around for a while) to let you look at software written in different languages pretty much the same from the outside. For example, you use environment variables for configuration, write lots to STDOUT, don't cripple your own horizontal scalability by always reaching for local storage (e.g. when S3 might be better suited) or local application memory (e.g. when Redis might be a good idea). It's nice to have those sorts of suggestions in one place and all of the sudden you escape XML or Tomcat setup hell, and can look at Python apps and Java apps similarly from the outside: https://12factor.net/ https://12factor.net/ Similarly, adopting containers has been a good solution, both because it allows achieving what people historically didn't bother with when having the opportunity of using systemd, but also because all of the sudden your applications are like phone apps - that can be launched in a consistent format on any server that you need. And you get health checks, resource limits, automatic restarts, bind mounts, port mapping and internal DNS, all of which you will never build in environments where the DevOps knowledge or resources (time) are not there. Note: Kubernetes might be too complex for some setups, as HN loves to point you, something like Nomad or even Docker Swarm also still exists and works: https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ (just linking this in particular, because it's just a small step up from Docker Compose, the pinnacle of simplicity) Speaking of which, infrastructure as code is great! Using something like Ansible is definitely a novel thing to do at first, but cutting off my team's write access to the servers and making them use GitOps with code review for the configuration changes has been a solid idea. No more wondering why some random configuration exists, or why it was changed N years ago, now you can just look at Git. No more fat fingering bad changes, and even if you did something like there's also code review. No more risks like Knight Capital of partial deploys and if something like that were to happen, you'd get a CI notification about what's wrong. Just describe what you need on the server and let those hundreds of actions execute every morning (or after every commit/merge) automatically, ensuring a mostly consistent state - and way more lazily than learning Nix/Guix: https://www.ansible.com/ https://www.ansible.com/ Furthermore, adopting the "ingress pattern" where all of your apps are in some internal overlay network, but talk to the outside world through instances of Apache/Nginx/Caddy/Traefik is brilliant! No more wondering about how to set up SSL certificates in each of the different application runtimes or even framework versions. No more worrying about setting up rate limits for each application individually, no more worrying about context paths for how things are deployed - you can configure all of that in your web server, even if you don't use a Kubernetes Ingress controller. Oh, and forget something like jQuery from the old days, especially when you'd integrate with numerous low quality plugins that wouldn't even work that well half of the time. Just use something like Vue with PrimeVue/PrimeFlex or any other premade component library, with Pinia for state management. You avoid the trouble of using React with Redux (though React Query is nice) or the complexity of Angular, while still getting the benefits of writing small, mostly self-contained application components. No more thousand line JavaScript controllers, no more messing around with global state, or god forbid using something like AngularJS. And with JSX, it actually ends up feeling more convenient to write front end code, in addition to Vue getting hooks right, better than React IMO: https://vuejs.org/ https://vuejs.org/ But the actual applications? Most of the time, they should be more boring. Using Java? Just go for Spring Boot or Dropwizard; something like Quarkus or Vert.X are nice, but not quite ready yet. Using Node? Look at Express.js, it does everything you need. Python? Django or Flask. PHP? Laravel or Symfony. Ruby? Rails. Every time I've seen someone go for a non-standard solution or actually writing their own framework, it's been an utter dumpsterfire. Good luck debugging some uncommented code that has not enough tests when there's a production outage and the few code comments that you might stumble upon are in Lithuanian or something. Databases? As a rule of thumb, go for PostgreSQL or MariaDB/MySQL. If you need data storage, use something S3 compatible. If you need key-value storage, use Redis. If you need document storage, either store JSON in your RDBMS or cautiously go for MongoDB. In each of these spaces, there are one or two established options and using anything outside of those should only be done when you have person-years to throw at every problem, e.g. the expertise and the $$$ to innovate. In most circumstances, just use what has worked for other people well, as long as their circumstances are similar to yours. (a bit long winded, but just felt like writing a bit today)

pwm 4y ago

It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors. How to make the "right" choice of unusual is where the interesting questions lie but that is highly context-dependent and can't easily be generalised into a blog post.

meadsteve 4y ago
This is a very good point. There are definitely "risky novel" choices that could make your company a success. But I've also seen many teams drowning in a soup of random tech choices. I'd love to be able to write some more specific advice on this topic but mostly I just want people to be mindful of the impacts of their choices and actively choose risk rather than having it sneak up on them.
- paulryanrogers 4y ago
  My first time as a team lead I saw value in little side experiments on non-core parts. Now I think that's only OK if there is time and budget to roll them back if they prove to be a bad fit. Otherwise they accrete and become a drag on velocity.
rTX5CMRXIfFG 4y ago
Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.
- berkes 4y ago
  ...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

samsquire 4y ago

What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there is a new framework or new library or new technology introduced. I learn from whitepapers and reading English descriptions of people's problems. I find this easier than reading someone else's code. Code is extremely powerful but it has a very high maintenance cost and change costs. Just getting up to speed on the Postgresql codebase or the Linux kernel or any other system tool is hard work and an investment. You kind of need to work 40 hours a week to get familiar with a codebase to be effective in it. But I can get familiar with a problem outside the context of a codebase by reading a whitepaper and writing some code. Reading a whitepaper feels more effective use of time than reading someone's codebase. You need to jump around a lot of code to understand the codebase. I think the effort for the ideal solution is underestimated. People abstract to their own understanding. And that abstraction might not be intuitive to other minds. I would prefer to work on a codebase that solves problems effectively than a codebase that is novel.

sshine 4y ago
I can't help but think that FOSS is the key to sharing the lineages. Every single place I worked, people just want to make code work, not readable.
bdg 4y ago
> I would prefer to work on a codebase that solves problems effectively than a codebase that is novel. I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of those teams). But it's crazy boring. There's no frameworks to download, not dependencies to update, no big brand pages. It's just following some very simple rules about where to put different kinds of complexity, very strictly. It's a hard sell in any programming ecosystem because it has no brand power. I've debated create the "no framework" spec around this. I even have a tool that can enforce the standards in CI. I just don't know if anyone would actually care.

pydry 4y ago

This (and a few other similar articles) make me feel that there ought to be more emphasis on recognizing "good novelty" vs "bad novelty" rather than "more novelty" vs "less novelty". The word "budget" frames the question wrongly, I think. If there are 4 new technologies on a project and the team were insistent that they each solved a lot of pain I'd be less averse than I would to 1 new technology that they adopted because it was "cool", "made by google" and "everybody [cool] is using it".

bad416f1f5a2 4y ago
> If there are 4 new technologies on a project and the team were insistent that they each solved a lot of pain I'd be less averse than I would to 1 new technology that they adopted because it was "cool", "made by google" and "everybody [cool] is using it". Programmers always insist that the new flavor of X solves a ton of pain. Occasionally they are right, but more often than not programmers adopting four new technologies- if they ship at all - deliver what Rich Hickey called “a knit house” in one of his talks: a system that solves a problem, sometimes in a pretty way, but is never able to be extended or grow. Sometimes the actual software is fine enough, but the choices are so novel that it ends up being maintained by one or two people who get it, and growing the team is a nightmare. Either way, it’s a knit house.

01152991766 4y ago

jiggawatts 4y ago

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any such thing. Just hit the build button and "copy to deploy". For about a decade I used to turn up to that customer annually for "maintenance", which primarily involved importing some CSVs that changed every year, and also updating the logo images and icons to match any rebrands. In that time the system had two million users, went through 4 OS upgrades, 3 database upgrades, and went through the 32-bit to 64-bit upgrade also. The underlying runtime had 3 or 4 major updates, depending on how you count it. Zero outages, no problems, only the occasional performance regression that could be fixed by poking the database statistics to get things back in their groove. The problem was... You see, all of the above was a problem, because it didn't keep me employed. I was not the "hero" for saving the day. Entire teams of people weren't involved. There was no visibility at the senior management level. Nobody got scared, or had to throw money at it, or hire consultants to review it. So it had to go. It was replaced by a system that cost about 500x as much (a 9-digit sum), got rolled back for failing to meet requirements, and then got additional funding and was eventually forced upon its hapless users. That, apparently, was doing things "properly". That got everybody involved. Everyone got their beak wet. All the way up to government ministers and their lobbyists. Multiple consultancies were engaged. Reports. Audits. Reviews. This is why we can't have simplicity: because it doesn't scale.

agumonkey 4y ago
> You see, all of the above was a problem, because it didn't keep me employed. I was not the "hero" for saving the day. Entire teams of people weren't involved. There was no visibility at the senior management level. Nobody got scared, or had to throw money at it, or hire consultants to review it. there are a few other instances of that: - an old article about Michelin (french tire manufacturer) quoting some scientist of theirs "We can make a million hour tire.. but what would we sell" - recently people said their rust code cause too much downtime for coders because it was too stable too early flip side of the same issue: - very often people game their work to ensure benefits: stash duties for later so you can appear busy, or overwhelmed (and claim promotion because you have so much to do) The global system doesn't reward to true optimization, it allocates people on useless tasks, at best for lower risk, but smart people doing things solid and fast could be using their talents on other problems.

eatonphil 4y ago

Just as one tiny counterpoint, the company I work for [0] builds a database written in Zig, not C. We implemented our own consensus using Viewstamped Replication [1], not Raft. And we built our own storage engine on LSM trees rather than use RocksDB [2]. A lot of this we built ourselves so we can do FoundationDB-style deterministic testing [3] of the entire system which would not be possible with off-the-shelf libraries because they are not deterministic. Another goal was to not allocate memory after startup. A goal that most third party libraries would disrupt. Sometimes the boring options do not further the technical goals of your project. :) [0] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle [1] https://pmg.csail.mit.edu/vr/liskov12vr-abstract.html https://pmg.csail.mit.edu/vr/liskov12vr-abstract.html [2] http://rocksdb.org/ http://rocksdb.org/ [3] https://apple.github.io/foundationdb/testing.html https://apple.github.io/foundationdb/testing.html

meadsteve 4y ago
Agreed. Though not strictly a counterpoint. I do enjoy novelty (and benefit from it). I just want the right amount of it
bazoom42 4y ago
That is not a counterpoint. If you said your choices did not have any cost or risk compared to the “boring” choice, that would be a counterpoint.
losvedir 4y ago
Ah, I think this is actually a very interesting example. My understanding is that TigerBeetle started its development under the company Coil, and was eventually spun out to its own company. I think this post my almost be directly speaking to Coil's decision to fund an in-house, specialized, database project written in Zig. More power to you guys for actually getting to work on such a fun project, but I wonder if that was a poor decision on Coil's part, as reflected by their eventual decision to jettison that part of their tech?
- deleted 4y ago
  [deleted]

valenterry 4y ago

The codebase should be as boring as the developer is experienced and the project is complex. In other words: a total beginner will find any codebase interesting/exciting and if the project is just complex enough, it will benefit from some techniques/technologies that are not familiar to most people and therefore not boring. Yeah, you can absolutely overengineer, but it's not like every codebase were better off if it's "boring". Also, we make progress. Before, statical typesystems had a benifit but also made code much more verbose and were sometimes very annoying. We improved here, but it means that someone has to be the first one to use a new language with helpful features. Is rust boring? No, but that doesn't mean it's not the best choice for some teams and projects.

Philip-J-Fry 4y ago

There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases. * Complex code can be a hindrance to onboarding new developers. Boring code can be a hindrance to onboarding new features. * You often end up in a situation where you're reinventing the wheel and you're spending increasing amounts of development time on keeping the wheel round. At some point you've got to consider a ready-made solution to your problem or consider hiring more people to deal with it. * Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high. Creating a company off the back of a flavour-of-the-month tech stack isn't a good idea. But I can't see how any large software company can scale without having a bit of spice somewhere.

sorokod 4y ago
Developer can be a programmer or a software engineer ( my definitions). Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Software engineers tend to be interested in delivering robust and correct features. Consequently they are more conservative. When companies hire, they should be clear what sort of developer they want. Programmer in a software engineering role will damage the code base and eventually leave in frustration.
- thow232329 4y ago
  > Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.

lorey 4y ago

related: "choose boring technology" https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246

andrewstuart 4y ago

I disagree with the fundamental premise put forward here. Software should be written to meet specific needs. And those needs should be defined. And it’s likely a software project will have many tens of needs defined. And amongst all those needs it will become clear what technologies fit the needs. A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome. Saying “projects should be built with boring technologies” is the equivalent of saying “projects should be built to NASA launch spec reliability”. That MIGHT be true, but having a predefined idea of what the requirements are puts the cart before the horse. Requirements come first, then after that come statements about how things will be done. My guess is that systematic definition of requirements will result in very very few projects “built using boring technology”.

qaq 4y ago
My experience is that requirements are almost orthogonal to what stack will be chosen. CTO going to a conference, tech lead being bored, founder having a friend who knows "shit", developers padding resume and so own impact the choice way more than actual requirements. 99.999% of the projects can be done using any mature lang + PostgreSQL or PostgreSQL compatible newSQL variant.
meadsteve 4y ago
If I was to rewrite my blogpost to fit your second sentence I would title it: "Please consider onboarding new staff as a need for your software". This is just another consideration when architecting. I absolutely will use cutting edge tools if they are needed. But we just need to think about it a little.
- andrewstuart 4y ago
  Indeed the availability of developers who know the tech stack is a key requirement that should be defined and assigned an importance level. And if you’re working in a business building a modern web application then it’s extremely hard to imagine the stakeholders being happy with software developed using absolute lowest common denominator tools techniques and libraries, as advocated by the “boring software” movement. Competitive advantage and the expectations of customers leads to the need to use modern tools techniques and libraries. And in fact developers deserve these things too because they tend to make things easier more powerful and more reliable. If the stakeholder who is paying for the project says “can we have an animated user education intro”, and you say “no because we use boring technologies and our developers might not understand how to use the animation APIs” them I think your job would be at risk pretty quick.

porker 4y ago

Working on a not-yet-launched Web app, where the backend and frontend both use CQRS, and hoops are jumped through in the name of "purity", a more boring codebase would be appreciated. Velocity would be higher and new hires onboarded in less time.

berkes 4y ago
But the two main questions are: Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? Boring doesn't have to be big-ball-of-mud, but the architectures you mention exist exactly to avoid big balls of mud from growing. And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?
- porker 4y ago
  > Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? So far there are zero clients and multiple pivots. The boring alternative needs only to yield higher velocity to be worthwhile, otherwise funding runs out before market fit and the current architecture achieves zero. > And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data? Everything is stored in a popular RDBS. CQRS makes logging all data changes easier, but that is the only time intermediate states are used. If we did event sourcing I'd be keener on the architecture.

photochemsyn 4y ago

The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any novelty issues and help people grasp what's going on. The simplest format discussed seems the best for most cases: https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md https://github.com/joelparkerhenderson/architecture-decision...

Kwpolska 4y ago
Where do you see the reinvention of UML within ADR? I wouldn't consider ADRs to be that; I'd say ADRs are meant for important decisions with important consequences, not a documentation of every single design choice and every single part of the project, as UML proponents would do.
- photochemsyn 4y ago
  Some of the ADR discussions seem to revolve around trying to create a formalized 'use anywhere' ADR model which does looks suspiciously like UML. The general concept (a historical record of the development of the architecture) sounds good, but a one-size-fits-all approach sounds like a bad idea. ADR approachs should probably be heavily customized to fit each project/codebase. Some people might say, "but if we had standardized ADRs we could efficiently compare different codebases" but that's going back to UML.

pkrumins 4y ago

If anyone wants to write boring tech full time (PHP 5, CSS 2, HTML 4, and regular JavaScript), let me know. I’m hiring!

meadsteve 4y ago
Php 5 would not be boring and safe. You'd have some interesting challenges writing in an unsupported language version
- pkrumins 4y ago
  There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.
  - meadsteve 4y ago
    The excitement comes when security issues are discovered in no longer maintained code
    - pkrumins 4y ago
      There are no security issues.
      - tchaffee 4y ago
        That's a laughable claim. https://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=604&sha=d8a9f07b702ae6252893a7ef73f2f2812bbcbb8a https://www.cvedetails.com/vulnerability-list.php?vendor_id=... And just 10 days ago: Code security company SonarSource today published details on a severe vulnerability impacting Packagist, which could have been abused to mount supply chain attacks targeting the PHP community. https://www.securityweek.com/critical-packagist-vulnerability-could-have-allowed-php-supply-chain-attack https://www.securityweek.com/critical-packagist-vulnerabilit... And this source says PHP is the 2nd most vulnerable server-side language in the world. https://www.thewebmonkeyonline.com/php-security-issues-you-need-to-protect/ https://www.thewebmonkeyonline.com/php-security-issues-you-n...

lifeisstillgood 4y ago

95-98% should be boring. The other 2% buys you the room to be boring - keep the meta-programming and macros in a small well defined area that does well the bits that boring programming cannot touch.

anyonecancode 4y ago

Another aspect of "boring" is note is that ideally the implementation is boring, as in not surprising. Currently working on a codebase that's a pretty standard frontend stack, but omg is it not boring. I wish it was. Instead, it's exciting as in "this function claims to remove items based on a filter, but actually it does the opposite." I might go so far as to argue that being boring (ie predictable and consistent) in your implementation is more important than being boring in your tech stack.

andrewstuart 4y ago

Here’s a question for you: “To what extent should developers use advanced programming language features?” I worked on a project once that had lots of sophisticated code in it. One of the senior developers objected however when I suggested we use typescript decorators. He said other developers might not understand it. Consider what happens when the question is phrased differently: “To what extent should developers use unfamiliar programming language features?” Well, all language features are initially unfamiliar. It’s a matter of opinion, but I think developers should use whatever language features they want, and all developers working on that should be expected to be active in learning unfamiliar techniques that they are implemented in the code. It’s extremely unhelpful to say that language features are “too advanced” or “too unfamiliar” to use.

paulryanrogers 4y ago
Some features are more naturally intuitive than others. Consider an 'if' statement and a monad. How much talent is available that's capable of understanding and using the latter effectively? How much time would be needed by a new hire to come up to speed? If you need intermittent help from contractors then will they be able to hit the ground running? Over time the bar does rise, and I hope that trend continues. Yet it's undeniable that there are limits like human lifespan, and how much people and companies are willing to invest in education and training before doing the actual work for which they're compensated.
- hnthrway 4y ago
  Most companies are willing to invest just about nothing into education

twodave 4y ago

Timely—I had a conversation about this with a friend a day or two ago. There is a definite trade-off between novelty and productivity. IMO putting as much novelty into the parts of your domain logic that differentiate you from competitors as possible is the best trade-off. You want your complexity and learning curve tied up in the “magic” parts of your software, not the mundane pieces.

lr4444lr 4y ago

Unless your software's value is actually a matter of CS research, it has to serve the bottom line of the business functions its built to facilitate. Sometimes thinga like hyperscale or super intense data redundancy or functional complete provability is a consequence of these needs, but they are not the prime directive. Almost all bad choices seem to stem from that misalignment.

didip 4y ago

I have come to learned that there’s no answer to this “problem”. Even if you stick with tried and true framework, eventually that framework aged, and then developers start complaining that the framework is arcane. For example, how many HN readers here know WebObjects? But the flip side is equally problematic. How many times do we have to change frontend frameworks? Just to render some divs on a web application? Somewhere in the middle seemed to be the right answer. Just build the web application with new-ish technology like Go or Rust or Elixir, and then sprinkle some JS like HTMX for interactivity.

draw_down 4y ago

ryanbrunner 4y ago

I think something that has served me well with these decisions is only considering novel tech if it does a better job of solving a problem we have right now. If the problem can't be measured yet, it's not worth working on yet. Start with something that is as boring as possible, it'll become obvious pretty quickly where the pain points are, and consider doing something novel for those.

pawelwentpawel 4y ago

From a perspective of a coder on a team, I think that strategically selecting which novel things to learn is a good thing career-wise. Fun aspect aside, one gets paid to learn new stuff which can later result in better future opportunities. As an example, as a junior dev back in 2015 or so, I was told to use one of the very first versions of Swift to develop a production-ready mobile app. Was it fun? Totally! Did I learn a lot? Absolutely! Did we almost trash the project and had a massive delay because of the early bugs, problems, refactoring with new updates, and because we were still learning? Hell yeah! The final payoff was pretty good for developers, but not for the final business objective which was getting a product out ASAP. Our users didn't care about what tech we used. Following from the above, I think it's important to distinguish two different aspects of the novelty - one is completely new tech ('global' - new to everyone) and the second is tech that's new to the team that is about to use it (let's call it 'local'). Global: That's the hole we got into using the first version of Swift. The team got stuck with problems that no one has ever had yet and we had to invest our time to solve them. The biggest risk was ending up with a completely new problem and no guarantee that anyone on your team will be able to solve it. There is no Github issue for it and no helpful stranger on Stack Overflow. It's pretty bad if it happens in a critical area. From a project perspective, I'd say it's better to wait for someone else's time and money budget to iron those problems out first if you want to increase your chances of having a production-ready product within a predictable timeframe. Local: This comes with a different set of risks. If you're working within a larger organization, how many other developers know this newly introduced tech? If the team that has introduced it quits, will there be anyone able to pick it up? If your project is on a critical deadline, do you have enough time to let developers get up to speed? I'd think about this decision from the perspective of investment. Ironically, I have also experienced the reverse - some companies use tech so old that developers have to learn it as something completely novel. The only dev that maintained the codebase might be retiring and the option is to rewrite or hire a person with a spark for archeology.