What made this particular codebase stand out above others? What did the original authors of the code do well?<p>Documentation? Tests?<p>Perhaps nothing about the code itself, but rather the surrounding environment?
I inherited EASTL (EA's internal implementation of the C++ STL designed to be more suitable for use in games) for a while after the original author left EA, although I'd already done some work on it while he was still there. It's now open source on GitHub. There's also a paper out there outlining the original motivation and design goals.<p>It was generally very well written and where it differs from the standard there's usually an interesting reason why. It had extensive unit tests that ran automatically across a very wide range of supported platforms and compilers including all major desktop, mobile and console platforms. It is generally much more legible than the STL implementation used by Microsoft (which was one of its design goals) while also often more efficient. It's the STL so it's mostly fundamental algorithms and data structures and widely useful utilities of general interest rather than very domain specific business logic.
19 upvotes, 1 hour, no answers...<p>How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code?<p>Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is.<p>Sorry OP, I got nothing positive!
I inherited a popular open source charting library. People like it because it has a data model - you can automatically brush and filter between charts.<p>It is intentionally a leaky abstraction so that there is always a way to customize it if it doesn't work the way you want.<p>There is only enough design to make it reusable, no claim to a "grammar" or other highfalutin abstractions.<p>There have been dozens of contributors and many parts are inconsistent.<p>Yet it still gets a ton of use 7 years on because it does 80-90% of what you want.<p>I've learned so much from this. Worse is better. Don't box yourself in with designs you don't understand.<p>Solve one big problem and after that be humble and let users work around anything you didn't think of.
Few years ago, I inherited the whole infrastructure for a fintech startup. It was few hundreds instances in AWS. The company was possibly the first to operate fully in the cloud and pass financial regulations for that.<p>At the heart of it, there was a short list of instances to run with their purposes. Most of everything was automated around that. You could add a line to order any resources in the world and have it running in the next 5 minutes. Instance provisioned with standard OS setup and patches, DNS and aliases up, permissions for developers and services deployed.<p>It was extremely efficient and well organized. I'm not sure who wrote it but I'm pretty sure it's the only guy in the world who figured out how to use AWS, accidentally.<p>While I worked there, I updated it to support provisioning in any region, EBS backups, automated firewall groups and a few other things. Everything was tagged consistently with purpose/team/environment for identification and billing.<p>It was neat. I doubt I will ever find again a company that can setup hardware or manage resources any decently.<p>To conclude this. A coworker told me that new guys were hired after I left and they undid most of it in the next 2 years.
Well, I'm only a lowly WordPress developer, but I'll say that most WordPress plugins are a PITA to extend the functionality of, but that the WP Store Locator plugin was very nice to work with. Just sensibly implemented object-oriented programming and extensive use of WordPress hooks.
I inherited an internal tool from someone who left the company. They weren't a software developer. Everything had comments (not function comments/XML headers), behavior comments.
Some were "someone who knows how to code should clean this up", "I want to do x but couldn't figure it out, this is close".
It lacked clear abstractions, it was mostly one file. It wasn't even in a repository.
The program was however purpose built for use by the developer, and people in a similar role at the company.<p>The team who was supposed own it hated it, so I get to work on it :)
My current works codebase.
I've never seemed to like other peoples code. Not even my own after 1 month
But this code is very good. I would attribute it to the strong set of rules and design patterns everyone follows. All code/services are broken up into `unit` which all follow the same pattern, of how it's called, how the code is arranged etc. This means there is no ambiguity for any new starters trying to contribute to the codebase. In addition to that our linter doesn't allow you to push code if it detects any errors. There are a few other elements, involved too, but I think the most important thing is keeping a standard of where each bit of code should live, how it should be called, and ensuring everyone uses the same conventions (i.e. single quotes instead of double, all this small things add up)
I've inherited a couple codebases at work that were pretty nice. They stood out among others because they did a good job at doing one simple thing very well. Libraries that start having a lot of feature creep, such as trying to support a bunch of different other libraries or trying to do things too cleverly to support a ton of different ways to use it, always end up being a mess.
So if the codebase were good, I would not be assigned to it. However, I always look to fix the following issues:<p>1) lack of extensibility. This comes from poorly scoped projects. Both previous dev and product manager didn't understand the value in what they were making.<p>2) built in headaches. This is related to (1) but it's kind of the opposite problem. I see deployment tools that don't make the options object available to read in all contexts, or unhelpful automations, like silent failures. This is often from someone inexperienced trying to be clever.<p>3) terrible engineering practices - storing prebuilt native binaries in git, deploying a custom (read unsupported) version of a tool like gpg or perl. This can represent just a terrible engineering culture, but I often find these practices can be sourced to someone with a title like Director of Research<p>4) Lack of scalability - this is the least worrisome thing I run into. It takes experience in big problems to know ahead of time with any accuracy where the bottlenecks will show up. If this were the only problem I ever ran into, I'd be a happy camper.
I once "inherited" an Adobe ColdFusion codebase that hadn't been touched in about 15 years. I guess the reason it hadn't been touched in so long was because it simply worked. It was a well structured project and easy to get in to. Implementing some minor new features was straight forward and thanks to an existing test suite easy to test.<p>Needless to say I was pleasantly surprised by that.
I inherited a well-unit tested JS MVC frontend written with classes using Resig's Simple JavaScript Inheritance and jQuery, it pretty much looks like modern React code with Pythonic style to match Python backend (self=this everywhere, snake-case etc), but written in 2009. Currently in process of migrating it to vanilla TypeScript with very few difficulties so far. A few months later and I could have be dealing with a coffeescript POC.<p>On the other hand I also inherited an angularjs frontend written by an ape.
I was new in development, had some notions about how to program, and stumbled upon sup (<a href="https://sup-heliotrope.github.io/" rel="nofollow">https://sup-heliotrope.github.io/</a>), a mua written in Ruby that basically incorporated all Gmail wisdom into a local, curses client. I was hooked. Looking at the code everything was clearly defined and understandable, with boundaries set exactly where'd you expect them. I owe William Morgan, its creator, for my interest in programming and the reason I started this career. Maybe some of it is also due to Ruby itself ?<p>If you don't know wmorgan, he's the one who created trollop and the leveldb-ruby gem. Any Ruby practitioner should know what I'm talking about.
Code written in Haskell is often really easy to pick up. Due to it's pure functions it can easily be picked up function by function and the GHC repl gives you an easy but powerful way to poke around. Of course there are also the crazy type level EDSL libs which are hard to disect, but in general Haskell has been the best language for me to pick up code written by others.
Inherited <a href="https://broadbandmap.nz/" rel="nofollow">https://broadbandmap.nz/</a> the frontend was done by a external contracting company, the frontend looked like it should once i got it to run.<p>They gave us a stock rails CMS/static site generator that did the frontend part.<p>almost full rewrite as we where a Python shop and there was a mess of JQuery pubsub involved so you wouldn't know what was happening in what order or if there would be a bug because something wasn't subscribed to this event bus in time. almost goto level.<p>We met with the external company a few times and they made it clear to us they wheren't getting paid to fix tech debt or make the handover process smooth for us just that they where getting paid to make it look like the design.<p>This is actually a better state than the other projects i can think of, more because its a small project and the levels of technical debt are thus lower because theres not as much code/complexity, not that the code that is there was good.<p>All the tests where failing (very flaky by design, using browser driving to check for very specific parts of text on the page that had long been replaced), we also deleted all their tests/writ our own aswell as the almost full rewrite.
I needed to extend a framework on which a thesis was written about.<p>The thesis explained all the high level concepts.<p>And every line of code was commented.<p>It made it quite easy to understand why and how he was doing things.
Deis Workflow is a really nice codebase, and I like to talk about it. "Team Hephy" we committed to maintain Workflow and support newer versions of Kubernetes when Deis went to Microsoft. Their release architecture and testing framework were just really top-notch. The number of things that just haven't gone wrong in 2 years since they stopped committing and we took over, is itself probably the biggest testament.<p>There are over 100 repositories with code in different languages, and I can honestly say that each time I've ever needed to go in and work on something, usually from a position of little or no knowledge about the code or internals other than as a black box, I just find really well-organized code that seems like it was thoughtfully put together by a bunch of people that assumed they were always going to be the ones who would be stuck dealing with the consequences of whatever decisions they made every day.<p><a href="https://github.com/teamhephy/workflow" rel="nofollow">https://github.com/teamhephy/workflow</a> (from <a href="https://github.com/deis/workflow" rel="nofollow">https://github.com/deis/workflow</a>)<p>If you're looking for some training wheels for your beginner Kubernetes experience, you could do a lot worse! The product itself is basically a "Bring-your-own-Infrastructure" open source Heroku work-alike.<p><a href="https://web.teamhephy.com" rel="nofollow">https://web.teamhephy.com</a> / <a href="https://blog.teamhephy.info" rel="nofollow">https://blog.teamhephy.info</a> / <a href="https://docs.teamhephy.info" rel="nofollow">https://docs.teamhephy.info</a>
Back in the day I would inherit or have to work on large codebases written in Delphi/Pascal from several different authors. While there were a few eyerolls here and there, I never recall being overwhelmed or overworked trying to discover what I needed to know.<p>But then that's Delphi; a pure pleasure to work with. I only wish I had more use cases for it. I would put back in the lineup immediately if I did.
Believe it or not, it was a large (~1M lines) in-house "CMS-generator for different clients" type of thing written in perl, this was right around the time 2nd-gen rails clones were starting to be a thing, a fair bit after perl was the popular weblang of choice.<p>The people who wrote it were competent at writing maintainable software. It was well thought out in terms of design and discoverability and tooling, it was well tested, and the authors cared a lot about not obfuscating purpose.<p>It had good dev ramp-up docs and a pretty clean commit history.<p>I think probably the largest differentiating factor for this particular codebase was that it wasn't developed under duress of time-pressure and the previous authors were past the point in their programming careers where they learned how to not overestimate their own ability or underestimate unknowns in their domain. The company was relatively small, technically competent at the top, and culturally less concerned with inflating profits than making enough money to live comfortably and do their thing.
I didn't inherit them, but I've had to read through portions of the sqlite and Mercurial codebases and found both to be very well written. Good code can and does exist. It rarely exists in the private closed source sector, however, because teams either are unwilling to invest in it, lack the proper skills in their developers, or both.
I recently took over GNU libredwg, which had an esp. nice codebase.
The infrastructure was severely lacking, not enough warnings and probes enabled in autotools, many missing configure settings, totally bonkers unittests written by some late Google Sumner of code students, but the base architecture was excellent, with a DSL like specification language (via C macros), it was easy to extend, and works as perfectly fine documentation. readable code.<p>Documentation had the proper GNU framework, of course without man pages as most such GNU stuff, but this also easy to add. The other testsuite parts were also easy to add, dejagnu still rocks, gtest would have been a horror show.<p>GNU coding standards are a godsend.
People who inherit code will always complain about something as that's just the nature of it. But often those complaints are more to do with the inheritor not understanding the intent. Code comments in those cases should describe the underlying design decisions or there should be thorough documentation of the design that explains it.
It wasn't technically inherited software, since no one imposed it on me, but when I shop around for open source libraries I tend to prefer those that some in-code docs and a few high level tests to check that the APIs keep working from a version to the next.<p>The worst code bases I inherited, on the other hand, are a lot memorable. The absolute worse was a ~500k-ish line of code WordPress/BuddyPress mess of undocumented spaghetti, complete with a slew of modifications to WP and BP core files. It took me weeks to put the latter in separate plugins in order to upgrade the mess.
PHP dev who inherited a Java Spring Boot application. Sooooo much hidden magic going on. This was a about a year ago and since then I've become more comfortable with the Spring way but I still feel a little uncomfortable with it, even though it's the cleanest codebase I own.
use a language that prioritizes maintenance and correctness instead of prioritizing speed-to-develop-a-prototype and brittle abstractions tailored for onboarding users who expect familiarity, and there will be a lot less expletives involved. These are real tradeoffs involved here. Without tradeoffs, there would be no need for choice and thus no need for strategy. Once those tradeoffs are determined, the crux of a strong strategy is how the chosen activities reinforce one and other to drive an unfair advantage.
I haven't inherited it but the C source of the simple terminal st is really really clean and good: <a href="https://st.suckless.org/" rel="nofollow">https://st.suckless.org/</a><p>I highly recommend it, it's only a couple thousand lines so it's worth the read. Never before have I seen such readable and clean C code. I read it and then implemented my own terminal emulator from scratch, which we now use on an embedded platform at work to debug problems that cannot be debugged using a PC (for example because Ethernet and serial connections to the device are broken).