5 ms·

Ask HN: Does any body work on a huge (and old) code base that is not a mess?

• scotch_bright 9y ago
  In case you see this and feel like the code base you work on is also a mess, then I think it would be a good idea to post something like: "I work at XYZ, and the code base is a mess." (Maybe leave out the company name if not comfortable. Just a size of the company will help.) I am urging you to do so, since atleast then we can move ahead and accept that this is the state of affairs. If we don't do that it will not be clear weather this is a problem or just an un-interesting discussion.
  • ttoinou 9y ago
    People won't do that it's not good for their company's public image.
    • scotch_bright 9y ago
      I know. Thats why I was suggesting there should be some anonymous way of acknowledging the problem without dealing with the consequences. (I am open to suggestions about this) I feel like it's a widespread problem but since there is some "shame" associated with it people don't want to talk about it and accept it. But that is silly because, considering that the problem is widespread it must be super hard to get right. So, by accepting that it is hard to get right, at least we will not say that we are stupid for getting it wrong. Anyways, this is my attempt to really understand the true state of things. (And what better platform than HN)
  • k_ 9y ago
    I work for a small company (< 10 developers until last month, and suddenly growing) working on a project since around 2013. I arrived a month and a half ago, and am leaving tomorrow. I haven't been able to make much sense of the current state of the application, which constantly needs new features (to be delivered yesterday). For each task you need to dig into countless files with a filename of ~50 characters, often with several classes, with a size ranging from 300 to 7000 (for a few files) lines. You are asked to copy paste existing solutions and modify some things to make it work for your feature. The code is a total undocumented mess (the copy-pasted javadoc all over the place doesn't help at all, since it's only rewording the function/variable name.. when it's not utterly outdated). Dead code everywhere, hundred of warnings (they use the closure library) due to bad code annotations (which do nothing at all), unreachable code, mistakes (comparing to NaN), or code doing nothing (often due to a type annotation mistake). I'll try to find another company, maybe with a recent project or an old one which they are rewriting _right now_. My current company's pitch was that the goal was to migrate the current application (in closure library) in something like react, but the reality was something else entirely and I doubt they will begin the transition any time soon. My previous companies were having similar issues (I left my previous company because the main project was falling appart and the CTO was refusing any attempt to rewrite the product, even if it's beginning to cost less to rewrite it entirely than to meet the clients needs by adapting the current version..), and I really hope I'll find myself in a situation where I am not silently swearing a dozen time a day at poorly written code.
    • scotch_bright 9y ago
      Wow. Thanks for that. Sadly enough it does seem like things like this are very common. This is super important because “software is eating the world”. A car/aeroplane/subway system etc all have code powering them. So our lives depend on software that other folks (just like us) write. Yet nobody here has said that the code they work with in their companies is not a mess. And the norm seems to be that code always turns into a monster that nobody can control. At best we seem to test pre and post release and hot fix things till they work satbly.
• carlsborg 9y ago
  I have seen large c++ code bases extremely clean and well structured even at scale, a real pleasure to work with. These projects were mostly birthed in the early/mid 2000's when architecture and design patterns were religion. Somewhere along the way "design" became a dirty word.
  • scotch_bright 9y ago
    That is a great point. Design Pattern and CS fundamentals are old and have not changed for 20-30 years. These are problems that have been solved ages ago. I can completely imagine what you are saying about the old C++ code bases to be true. What do you think happened to us? Uncle Bob says the web happened. Maybe back in the day when you had to make a program that ran on the console things were simpler. Now for a standard web application we need to worry about JS and CSS and HTTP and HTML and WebSockets. (And then the app needs to support different clients like Web, Mobile Web, Native etc.) I am talking about this since thats the kind of software I build and I know that it is always a mess. But there are still C++ programs written today that are not for the web. Are they also a mess? If they are then the web is not the problem.
    • carlsborg 9y ago
      I think there are different classes of applications, - some that don't really need any time spent on design at all, and some that absolutely do - and for a while the former class of applications became predominant (possibly because of the rise of quality middleware and frameworks that did the heavy lifting ), and the methodologies became mainstream, and adopted universally. Hard to generalise beyond that.
• ttoinou 9y ago
  I don't understand your point. You would like to know which techniques that minimize work involved in maintaining a codebase / adding features ? It's true that it's a topic not very well researched but you also have to take into account others factors (economic, management, incentives, planning etc.). For example, following Conway's law ( https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law ) the software codebase complexity and the way the team is organized are connected. There might be no silver bullet at all (e.g. it's a hard problem involving human coordination)
  • scotch_bright 9y ago
    Okay. I will study more about Conway's law. Thanks for that. What I want to get at is: Is this the "normal" state of affairs? Do all projects devolve eventually? There seems to be a lot of work that has been done on Deign Patterns and best practices to write code etc etc. And this work was done 20-30 years ago. So, what explains the mess we see everywhere? Thats what I want to find out.
• segmondy 9y ago
  There are such code bases, look to the OSS projects to learn. Linux, FreeBSD, MySQL, Postgres, Apache, a lot of your favorite projects have been around for quite a long time. We don't consider them legacy, but they are if you use that to refer to software that has been around for a long time.
  • scotch_bright 9y ago
    Great so OSS projects also have a very large number of people coming together and collaborating. How do they stay clean? Why is there a mess in the code that gets made within companies? What do you think the difference is?
    • chatmasta 9y ago
      You’re making a huge generalization (all OSS is clean code, no internal projects are clean code). Ignoring that, let’s hypothesize a reason why you might find higher quality code in OSS. Perhaps it’s because company code has deadlines and pressures unrelated to the code quality, whereas OSS is solely about code quality. For company projects, the customers are the users. For OSS projects, developers are the users. Requirements for companies revolve around customers, who never see the code (other than companies building products for developers). Requirements for OSS revolve around developers who will be using the code. Given this, and the fact that OSS is a much lower pressure environment, it’s not surprising you might see cleaner code in OSS software than internal company software. tl;dr OSS focuses on code, companies focus on customers.
      • scotch_bright 9y ago
        Yes. I am simply accepting the premise given and trying to explore from there. I am aware of the generalisation. But, your answer does help us move ahead. It basically says that there is a way to produce a high quality code base. It is not impossible. The right set of circumstances seem to be: 1. No deadlines 2. Focus on code quality The "no deadlines" part I take to mean that within OSS projects there is time to refactor to perfection. There is time to design, comment, document and indent to perfection. So, your point is it is possible. But it seems like within the context of a company, it almost never happens. (Nobody has still posted here to saying that their code base is not a mess. A lot of people have now seen this.) When one thinks about that, it is just weird right? The people who get paid to make software do things that make their work un-productive. And the opposite is true for good OSS.
• PaulHoule 9y ago
  The unappreciated key to rapid software development is having a realistic plan: https://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005 https://www.amazon.com/Rapid-Development-Taming-Software-Sch... "Point the boat in the right direction and row" is the dominant paradigm in the industry. The concept of "technical debt" is I think harmful because it is a two word phrase that stops thought. In the real world if you want to take on commercial debt, the bank and/or bondholders and originators are going to want to see a detailed financial analysis that will indicate they will get their money back. Probably 80% of effort on software is maintenance, but it is rare for any project to start out thinking about the cost of maintenance.
  • Jtsummers 9y ago
    As a maintenance programmer, you're 100% correct. Our systems are not designed to be maintained and so our ability to work is severely hampered. Within the area of maintenance programming, if you inherit a program with a poor testing infrastructure (or even worse, have to produce it yourself) you will make the system worse over time or move at a snail's pace. Automated testing and unit tests need to be present to make effective changes during maintenance to systems. Otherwise too many of our changes are shots in the dark. They add the feature we wanted (we can test that much), but may have broken a dozen other things that we won't see until much later in the schedule. A lack of automated testing and good unit tests also motivates managers to adopt more waterfall-styled schedules. Pushing integration of the various change requests to the last possible moment, with a comprehensive test suite run after that. This creates huge schedule risk, but from their perspective is necessary. Why? Because they don't want to spend the time/money running that huge, comprehensive, largely manual test suite more than once in a year. They don't accept that a partial test suite (a representative sample, if you will) could be executed with greater frequency and give similar results, with the full suite run once for certification testing at the end.
    • PaulHoule 9y ago
      You're definitely right that unit tests are a part of the solution. https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... can be read in a few different registers (making a case for what unit tests should be in a greenfield system, why and how to backfit unit tests into a legacy system) but it makes that case pretty strongly. It can seem overwhelming to get unit tests into a legacy system but the reward is large. I remember working on a system that was absolutely awful but was salvageable because it had unit tests! Also generally getting control of the build procedure is key to the scheduling issue -- I have seen many new project where a team of people work on something and think all of the parts are good to go, but you find there is another six months of integration work, installer engineering, and other things you need to do ship a product. Automation, documentation, simplification are all bits of the puzzle, but if you want agility, you need to know how to go from source code to a product, and not every team does.