13 ms·

How terrible code gets written by sane people

197 points by SarasaNews 10y ago

sadfsa 10y ago
>porting an old Python codebase to Node Node is how.
TempleOS 10y ago
I was specially chosen by God and given divine intellect to become His avatar for the divine code of TempleOS. It is divine intellect written by God himself. God says... gloried idiom's welfare's contraband carnally urchins clear's activity stalemating depressing subconsciously intentionally verbs distinguishable staunching Mooney's spanking speculate omnivore Fassbinder Ophelia vehicles kidnapping fresher mammograms kneeling exiting minuscule daydreamer's Chickasaw mattresses torpidity
arcanus 10y ago
All good examples (such as excessive importance to deadlines, a big no-no). My question: can they be truly good programmers of they write bad code? Isn't the essential product of a programmer SLOC and functionality via software? And if they do that in a manner inferior to another dev, isn't that objectively a measure of inferiority in their craft? I've met far too many 'good' programmers who were a net detriment to a project not to be wary of the term.
- jondubois 10y ago
  Under insufficient time constraints, a good developer will either produce bad code or no code at all (he will resign from the company). This is extremely common. The stuff the author said about too much emphasis on deadlines is spot-on. Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs. For example, if a lead developer doesn't choose the right framework or plan/design the API correctly, then the consequences of that will keep piling up over time. It's really easy to put the blame on people who are doing the 'small work' but in reality, they might be doing the best work possible under the terrible constraints imposed on them.
  - lawn 10y ago
    > Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs. This is very prevalent at my job. There are a couple of developers who have a reputation of being really fast. "Wow, he closed 25 tickets the last hour!". In reality he mainly rejected them or made quick fixes which didn't work or created new bugs. A not insignificant amount of time in a recent project I had was focused on rewriting code said developer had written.
- Clubber 10y ago
  Yes and no. Crazy, made up deadlines will throw even the best developer off. They want to, fist and foremost get it done. If everything else is irrelevant, then that's what you will get. Of course that ends up being bad for everybody, but many businesses still don't have a clue on how to operate their most important department. Sometimes you have a hard deadline that you just can't help like a mission critical bug, or the VP of sales promised your most important client an impossible date and there are fines involved. I'm a firm believer of setting aside time for refactoring every X number of releases. That solves a lot of this.
  - kpil 10y ago
    You know, it depends... Impossible and strict deadlines simply because of cost control is shooting yourself in the foot. Impossible deadlines because of a really important deal worth actual money, is probably worth sweating over,at the risk of code quality. If all projects tend to be the latter case, it's probably actually the first case packaged as the second...
    - Clubber 10y ago
      Sure, sometimes it's just a matter of survival. Get this code released by this date or we sink. That's an unfortunate place to be in, requires a lot of focus under stress and is rarely rewarded. It's gratifying for me to be successful in those circumstances, but too many of them and I have to find a saner place to work. Management starts to take miracles as the norm by planning them (if they even do) and it leads to burnout.
- pyb 10y ago
  So true. A 'good' programmer who commits terrible code is a bad programmer. In other words, one trait of a senior developer is knowing to pick your battles. If you can't do good work, you have to get out.
  - joeax 10y ago
    I think is is true at the earlier stages of one's career. One you get older and have to start feeding a family, the idealism wears off and you start finding yourself compromising your morals and coding shit to make a deadline. But the company you work for pays you so well, coupled with the expert domain knowledge that makes you nearly irreplaceable, you become complacent. You are a fixed cog in the system. At this point "get out" is not in your best interests.
    - pyb 10y ago
      No one said it was easy...
- JustSomeNobody 10y ago
  Even good developers have to initially poke at a problem to get it in their head. Once there, then they can write beautiful code to solve it. Therefore, if time is constrained, even good developers will have to ship ugly (but working) code.
lettersdigits 10y ago
a good programmer should be able to identify bad companies to work for, which could solve many of the issues displayed in the article. it's much like choosing a good life partner - choosing a good life partner (instead of a crazy one) will save you from many troubles that you would encounter if you married the wrong person in the first place. ps: i need to tell this more to myself. i already made bad choices regarding where i work, which forced me to quit those jobs at the end.. (edit: spacing)
- alkonaut 10y ago
  I think a lot of this sentiment overlooks the fact that in most cities the number of software companies is very limited - perhaps allowing one switch in a career if there are huge problems or conflicts, but certainly not enough to allow switching due to e.g poor development practices. What's worse, in these places the poor devs tend to stick around while talented ones leave because they either accept moving or they can find remote work due to good connections or nice SO/GH profiles.
  - lettersdigits 10y ago
    you are removing a lot of personal responsibility from the guy who is looking for the job. If you are born in a 'bad' place (regardless of the reason for it being 'bad' - a violent/poor neighborhood, a city without hope for jobs, a small country-side town with no tech industry at all, etc. etc.) - you should be responsible for improving your life/moving to a better city/etc. to analogize from soccer: Messi plays at Bercelona, but is from argentina. Ronaldo plays at Real Radrid, but is from portugal. if ronaldo stayed in portugal, which teams would he be able to play with that would even become close to matching real madrid ? same goes for messi and barcelona. he could have said something like 'i was born in argentina, and no one here plays soccer like barceolna/real madrid. therefore - i will not play soccer because i was born in the wrong place'
    - alkonaut 10y ago
      I think a lot of what you are saying makes sense, but also at some age and family status (kids in schools etc) moving doesn't make sense any more, or has more downsides than one is trying to avoid. Obviously one could have thought of this before marrying and putting kids in school in the town with one tech firm - but that doesn't make it any less a reality for a lot of people. Saying "kids we have to move because dads colleagues refuse to do proper peer reviews" just doesn't taste right :)
joeax 10y ago
Focusing on poor metrics such as “issues closed” or “commits per day” I once worked at a company that used an offshore company to work on certain modules of a large project. They would commit code that my team would have to then code review. We'd see things like large IF-ELSE blocks with minor differences among the conditions (sometimes just one char). I know everyone hates this. Turns out their internal metric was lines of code per day, so they'd bloat the shit out of everything.
- Clubber 10y ago
  There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs incentivize net without incintivizing quality, i.e. gut the company, get your bonus and get out.
  - devoply 10y ago
    Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stupidest thing rationalists ever cooked up. It destroys internal motivation and discipline.
    - Clubber 10y ago
      >is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought out process. A better incentive, in my opinion is: if you release a complete codebase with 0 medium and above defects by X date, you get a free week off, or something of significant value. A free, company branded desk clock doesn't cut it. (that's happened to me before). If a company is trying to save money by hiring the cheapest offshore developers they can, they are still really just throwing away money and aggravating people. lol. That is a perfect example of a poor incentive: cut costs without any regard to the resulting cuts in quality. Anyone can make a turd cheaply, but that's rarely what businesses really want.
pfarnsworth 10y ago
This is a fucking arrogant article. I would love to see this blogger try to maintain a large codebase after several development cycles in the real world. To come into someone else's codebase that has umpteen number of iterations and tough business realities like trying to make money, and proclaiming that it's terrible code and how he would fix it, is delusional and self-aggrandizing. Most production code needs to be revamped every few years because the subsequent unforeseen functionalities that was forced by product managers and customers. That code is usually going against the grain of the original code but you can't blame the original designers because it was never spec'ed out. The best code is the code that is easiest to manipulate and modify, but even then it gets old and needs a rewrite. There's nothing wrong with that, except thinking you can comment on the shitty code and thinking your above it and how you would never let it happen.
- lettersdigits 10y ago
  > The best code is the code that is easiest to manipulate and modify this great (IMO) article comes to mind: http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to http://programmingisterrible.com/post/139222674273/write-cod... : "Write code that is easy to delete, not easy to extend"
  - robnagler 10y ago
    Excellent article, thanks.
- jlg23 10y ago
  > To come into someone else's codebase that has umpteen number of iterations and tough business realities like trying to make money, and proclaiming that it's terrible code and how he would fix it, is delusional and self-aggrandizing. And yet that is exactly the reality one faces in such projects (because the only valid code metric is "WTFs/minute" [1]. Point is, I've never heard anybody complaining about arrogance until now - usually the devs are very well aware where and how their code sucks and they usually are overly apologetic even though I understand the constraints the code was written under (some of which you described). [1] http://www.osnews.com/images/comics/wtfm.jpg http://www.osnews.com/images/comics/wtfm.jpg
pmarreck 10y ago
The site is now 404'ing so I guess s/he isn't heeding their own warning?
- williamdclt 10y ago
  500'ing for me. A lot of websites ending up on HN frontpage aren't dimensioned for the traffic it implies, I won't blame them for it
- innerspirit 10y ago
  Whoops, I think it was a bad CloudFlare setting. Should be working now, hopefully.
dsego 10y ago
I work on a lot of projects like this. The non-techies running the project are usually clueless and programmers are out of touch with modern best practices. The funny thing is that it makes me look slow for not finishing tasks. People in charge want to see features banged out. The guys who write hundred-line if-defs or copy/paste code from one file to another, get to go home at 5pm and live their life. Someone else picks up the tab later. When they need some info from the db, they just add an ajax call and some php function to fetch that and use jQuery to change it on page. I don't even try to refactor this stuff, just breaks everything, so I go along. I won't even say anything about cleaning it up, because it will be assigned to me, while the other guys pile on spaghetti code like there is no tomorrow, good luck merging that.
- amelius 10y ago
  I sympathize with this, but perhaps it is really more economical to write software like this in your company's case (?)
  - Clubber 10y ago
    It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability (read easily add/remove/change features). Companies spend a hell of a lot of money for growth. If they don't know how to manage software development, then the software will nullify all that cost spend on growing, because the system can't handle it. I am truly amazed at how bad many US businesses are at managing their software systems. It's as if they are considered an afterthought rather than the department on which every other department depends. It's simply old fashioned thinking. CEOs are typically older, and the current crop were trained before computers really proliferated business.
    - beagle3 10y ago
      > It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability Still, it depends on the specifics. Many, many projects get redone/canceled/completely respecified after first contact with market / customer. Many are also canceled for reasons that are independent of the progress speed. For all these projects, speed-to-market has value, and long-term-maintainability has absolutely zero. The horror arrives when, in a successful project, you realize that you are going to live with the hastily, horribly, developed project for some time to come. But these might be the exceptions - depending on how you count, some stats claim 80% of software projects get cancelled before completion (Have no idea how they define that) It's a balancing act.
jelder 10y ago
Mirror?
- innerspirit 10y ago
  https://ponyfoo.com/articles/terrible-code-sane-people https://ponyfoo.com/articles/terrible-code-sane-people
deleted 10y ago
[deleted]
peter_retief 10y ago
I had a quick look at your commentary, its great, the whole issue of rushing code and debugging forever, also nice allusion to anti patterns :) I have bookmarked and will read properly very soon, maybe
erikb 10y ago
Honestly, I think the best developers are not the ones that write beautiful code and put quality above everything else. The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. Because that's real life, and not the pony farm. Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quality and code getting money requires kowtowing and overpromising to someone who currently has money. Second comes qualifying for the money (yes, in real world you get money without having what you are selling, but that's a short-term success). That means getting to ask for money again tomorrow. That is where skill and code come into play. You promised something and now when you are lucky you can deliver 80% of that. Push hard to get there. Not everybody who tries will achieve that much. And only then comes quality, which means qualifying for money next year becomes cheaper. If you realize LIFE is that way, suddenly high quality isn't all that important anymore, is it? Quality is a luxury and you must have achieved A LOT to be in a position to just think about quality. And the ohter people (management, sales) are not total idiots. If you dream the high quality dream they are the people who pay your bills. I am an engineer like you, btw. I was just in the situation already, where I had to pay my bills myself and therefore know what amount of humiliation and sweat is required to get money just for ONE person, me.
- projektir 10y ago
  > Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quality and code getting money requires kowtowing and overpromising to someone who currently has money. That has little to do with what makes development and a lot more to do with capitalism, business, and markets. What this really means is that current business environments don't necessarily value development, but that doesn't change the definition of development. At this point, you're not discussing a good developer, but a person who can hybridize development and business sense. It's a different skillset, perhaps one that's somewhat contradictory to high quality development, even. There are situations in which there is no money at all, yet you absolutely need good development skills and they are distinguishable (open source). Any given person can be devoted to selling, whether they're coding or weaving baskets, but that doesn't suddenly mean that a core factor of weaving baskets is being able to sell them. It's not. That's a different skill set entirely. It may often not be found side by side. It's a shame that we are so obsessed with money and selling right now that pure skills seem to have little value to some people, despite the fact that many crucial things nonetheless run off of these core skills... This argument is equivalent to saying that only applied science has value.
JamesBarney 10y ago
I like the article but I found the implied solution a little humorous. Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and massochistic enough to stick it out at an obviously poorly run project. Good luck Side note, for 15 years of experience the project doesn't seem that bad by a long shot. I only have ~7 years of experience and have seen some far worse code. I was just recently on a project that has some methods that take 8 call backs(project was greenfielded in Jan 2016) before that I was on a project where the development team copy and paste the source for the last web page every time they needed a new one, but not delete the initialization code that fetched the data from.the database. So the 18th screen they worked on had 26,000 lines of code and took 5 minutes to load. And every button click triggered a reload. So, add a new widget and boom, wait 5 minutes for a screen refresh.
- busterarm 10y ago
  > Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and masochistic enough to stick it out at an obviously poorly run project. This is a pretty close description of the positions I find myself in as a dev and I don't think this combination of qualities makes me more hirable.
  - psyc 10y ago
    It probably won't, because most of that isn't predictable (by the interviewer) at interview time. It could make you more valuable in your current job, though.
    - busterarm 10y ago
      invaluable, but they won't kick me more money. I asked.
      - 10y ago
NumberSix 10y ago
A number of points in the post/article are questionable. First, it assumes the developers had substantial control over the schedule for the project ("Giving excessive importance to estimates"). Certainly in my experience this is unusual. More frequently, the schedule is dictated by management, frequently by sales/marketing executives in commercial software development. It is very difficult to push back and a good way to lose your job. Sales: We have closed this great deal with BigCorp. Can you do X (complicated, challenging software project) by the end of the quarter? Developers: Err, um, X sounds like a project that will take six months. Sales: We really need to make our quarterly numbers. Our CEO Bob used to be a developer and he says any competent programmer can do it and we only hire the best. Competent doesn’t cut it here! You are a rockstar ninja, aren’t you? Can you prove you can’t do it by the end of the quarter? Developers: Well, no. The schedules are driven by some unexpected problem or problems that usually happen. But, well, if nothing unexpected happens, we can do it by the end of the quarter. Sales: Great! Bob is expecting results by the end of the quarter. So much for the beautiful, elegant software design methodologies taught in college and university CS programs and peddled by high priced consultants. Second (“Giving no importance to project knowledge”), high technology employers seem to have extremely high turnover rates of software developers and other employers. Payscale produced a study claiming that the average employee tenure and Amazon and Google is only one year. Many companies seem to target employees with more than seven years of paid work experience — Logan’s Run style — for layoffs and “constructive discharge,” (https://en.wikipedia.org/wiki/Constructive_dismissal https://en.wikipedia.org/wiki/Constructive_dismissal) where employees are made uncomfortable and quit “voluntarily.” Undoubtedly, this is costly as the author implies, but it seems to be common practice. Yes, metrics like “issues closed,” “commits per day,” or “lines of code” don’t work very well. Once employees realize they are being tracked and evaluated on some metric, they have a strong motivation to figure out how to manipulate the metric. Even if the employees don’t try to manipulate the metrics, the metrics all have serious weaknesses and map imperfectly to value added (biz speak). Third, are code reviews and unit testing proven processes especially for normal non-Microsoft companies? In the early days of Test Driven Development (TDD), Kent Beck and his colleagues made numerous claims about the success of Test Driven Development in the Chrysler Comprehensive Compensation System (C3) payroll project, an attempt to create a unified company wide payroll system for Chrysler. This project in fact had a range of problems and was eventually cancelled by Chrysler in 2000, without replacing the Chrysler payroll systems successfully. As the problems with C3 have become well documented and well known, TDD enthusiasts have shifted to citing studies at Microsoft and some other gigantic companies that claim practices like TDD and code reviews work well. Are these really true or do these case studies have hidden issues as C3 did? Further, Microsoft, Google, and other companies that have played a big role in promoting these practices are very unusual companies, phenomenally successful super-unicorns with sales in the range of 40-100 billion (with a B) dollars with near monopoly positions and anomalously high revenues and frequently profits per employee. Microsoft claims to have revenues of $732,224 per employee. Google claims an astonishing $1,154,896 per employee. (http://www.businessinsider.com/top-tech-companies-revenue-per-employee-2015-10/ http://www.businessinsider.com/top-tech-companies-revenue-pe...) This compares to $100-200,000 per employee for most successful companies. Fergus Henderson at Google recently published an article on Google’s software engineering practices (https://arxiv.org/abs/1702.01715 https://arxiv.org/abs/1702.01715) with the following statements: 2.11. Frequent rewrites Most software at Google gets rewritten every few years. This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. Note: “incredibly costly” Companies like Microsoft and Google have enormous resources including monopoly power and can follow practices that are extremely costly and inefficient, which may work for them. Even if these practices are quite harmful, they have the resources to succeed nonetheless — at least for the immediate future, the next five years. From a business point of view, it may even be in the interests of Microsoft, Google, and other giant near monopolies to promote software development practices that smaller competitors and potential competitors simply can’t afford and that will bankrupt them if adopted. Both code reviews and unit tests are clearly time consuming up front. Code reviews using tools like Google’s Gerrit or Phabricator (a spin-off from Facebook, another super-unicorn) are committee meetings on every line of code. Regarding: Imagine my dismay when I had to collaborate with a colleague on that legacy project and his screen displayed Notepad in its full glory. Using “search” to find methods might have been rad back in the nineties, but these days, refraining from using tools such as modern IDEs, version control and code inspection will set you back tremendously. They are now absolutely required for projects of any size. Using “search” to find methods was not rad back in the 1990’s. IDE’s and code browsers specifically have been in widespread use since the 1980’s. Turbo Pascal (https://en.wikipedia.org/wiki/Turbo_Pascal https://en.wikipedia.org/wiki/Turbo_Pascal) was introduced in 1983 and featured a fully functional IDE, soon to be followed by IDE’s in many other products. Version control dates back at least to SCCS (https://en.wikipedia.org/wiki/Source_Code_Control_System https://en.wikipedia.org/wiki/Source_Code_Control_System) which was released in 1972. RCS was released in 1981 and version control was common in the 1980s and since. Code reviews have been around for a long time. However, in the 1990’s and earlier they were restricted to relatively special projects such as the Space Shuttle avionics where very high levels or safety and reliability, far beyond most commercial software, were required. This speaks to the “incredibly costly” quote about Google above. Without more context, it is difficult to evaluate the use of Notepad. Simple code/text editors like Notepad and vim (formerly vi ) are very fast to start up and can be a better option for some quick projects than starting an IDE. Some IDE’s are particularly hard to use. Early versions of Apple’s Xcode circa 2010 were particularly difficult to use in practice; it has improved somewhat in the current releases. People vary significantly. Some developers seem to find stripped down tools like vim or Notepad or Notepad++ (on Windows) a better option than complicated IDE’s. I am more of an emacs or IDE person. The fact that someone else works differently than you do does not mean they are worse (or better) than you. The fact that something works well for someone else also does not mean it will work well for you — or vice versa. There are sound reasons for duplicating code, cutting and pasting, rather than creating a function or object called in several location in the code. If the developer anticipates that the code may subsequently diverge, then duplication is often best. Like grand master chess players, highly experienced developers, especially under tight time constraints (like a chess tournament), code by intuition, not by laboriously reasoning out every step. If it feels like the code is likely to diverge in the future, duplicate. If it does not diverge, no problem, it can be merged back later if needed. In the bad old days of structured design (1980’s) and object-oriented design (OOD — 1990s), software development projects suffered from Big Design Up Front (BDUF), grandiose attempts to design a perfect software system before writing a line of code. This often resulted in massive cost and schedule overruns and total failures. It often proves better to just throw (“hack”) something together quickly — a prototype, proof of concept, Minimum Viable Product (MVP). Just “get something working.” Inevitably these prototypes and early stage software projects are going to compare poorly to some theoretical perfectly designed system with 20-20 hindsight. That is what seduced people into BDUF twenty, thirty years ago. Modern Agile software development methodologies are foolishly trying to have it both ways, have an initial quick iteration BUT that first iteration should be perfectly designed up front — beautiful, elegant, with hundreds of tests, endless committee meetings on coding style and design (code reviews), all sorts of supposed best practices, no code duplication, etc. This is a seductive fantasy doomed to fail in most cases.
EliRivers 10y ago
"mixed spaces/tabs for indentation" If that's the second thing in the list of problems, the problems aren't nearly so bad or the author's got a savage case of mixing in the trivial with the important.
- jinglebells 10y ago
  I'd say it's like smelling smoke. If your team can't even agree on a standard indent and stick to it, and you haven't got a linter which picks it up, what else are they missing?
doggydogs94 10y ago
The key word is "deadline". Horrible code that works beats beautiful code that has not been thoroughly tested.
- JustSomeNobody 10y ago
  Along those same thoughts, you put many developers in a room and they end up converging on "the one true architecture" and nothing ever ships but you have this monstrosity with some very beautiful code in it. Put few developers in a room and you get decent code and a solution to the problem that actually ships.
dahart 10y ago
It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking about ground up rewrites. All 3 had people complaining about every single example the author used. Two of them undertook the ground up rewrite estimating one year. Both admitted to having made a huge mistake 3-5 years later. My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. We all have code ideals we believe and talk about that don't work as well in the real world as we imagined. We all have deadlines that are shorter than we want -- it's a universal constant. We all imagine we can write code and fix big problems faster than we really can. And we all fail to fully understand what's working right in a messy large codebase and tend to focus on what's wrong. I don't know how to fix this, but it's very possible the author ran into thoughtful paradigms he just hadn't seen before and didn't fully understand. Some styles seem messy if you haven't seen them before. React is an intentional lack of separation of concerns between code and markup. Some projects are required to mix tabs and spaces depending on tools. For that matter, bash scripts alone require mixing tabs and spaces for some features. And so on, it's important to have context for why things are the way they are before jumping to the conclusion that it's bad.
- SatvikBeri 10y ago
  > My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases. I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication.
SatvikBeri 10y ago
One thing I've been thinking about more and more is code that's easy to delete. For example, we recently built a data pipeline that did a bunch of processing and wrote data to a SQL database at the end. For various reasons, there was an unscalable, quick way to implement the write, and a scalable, slow way to do it. We wanted to get the product to testing ASAP, so we chose the quick way initially. In order to make sure that we could easily replace that code, we ended up creating a separate write function for each table, where the function did nothing else except the write. That involved a lot of duplication, but made it easy to move the tables over to a better method one by one later. It seems like having functions with one purpose, pure if possible, is a pretty good way to ensure "upgradeable" code–even if the internals of the function are messy, you just have to write a new one that copies the same functionality. Furthermore, I've found single responsibility functions to be easier to enforce in code reviews than single responsibility classes.
- VLM 10y ago
  I would agree with that goal and extend with a different anecdote that the articles "project knowledge" section should include documenting the weird requirements and unusual interfaces to other projects. Many times I've run into five year old program logic, pondered why in the world anyone (me) would had done something that weird, and realized the project or tool requiring that weirdness was cancelled three years ago long enough that I've forgotten about it. Its not as simple sometimes as just baking into the single function that talks to the API, sometimes it gets baked into weird corners of the application logic.
- iaml 10y ago
  What you are describing seems very familiar to the idea in this [0] talk that I saw mentioned in the other thread on HN. Basically, the speaker argues that any codebase has a tendency to become a big bloated mess. The proposed solution to that is writing highly modular code that you can easily rewrite from scratch in a week. [0] https://vimeo.com/108441214 https://vimeo.com/108441214
  - SatvikBeri 10y ago
    This is great! Much more fleshed out than my post.
mannykannot 10y ago
"The authors created their own framework..." I cannot say this was an issue here, but I can say that some of the worst messes I have seen have followed from this decision. In all such cases in my experience, it was not a technically justifiable decision, and I strongly suspect it was driven by developer ego and overconfidence. The very worst included a roll-your-own language.
- Pica_soO 10y ago
  Eh, DSL scripting languages have a right to exist.
  - mannykannot 10y ago
    If someone was suggesting otherwise, you might have a point worth raising. But now that you have introduced this non-sequitur, I will freely assert that our rights trump those of bad DSLs to exist. I suspect that if you had seen the specific case I am referring to, you would agree.
- tonyedgecombe 10y ago
  We've all done it though.
lunz 10y ago
Perhaps the team planned a rewrite long ago and stopped worrying about the quality of their code, which seemed obsolete in the moment it was written. Over the years, however, there was always something more important than the "soon-to-be" rewrite.
hinkley 10y ago
I work with a team that managed to write the code he describes in a little over three years. it's really just chaos and I only trust a few of them. So why do I keep talking myself out of looking for a new job? Hell if I know.
Animats 10y ago
Converting Python to node.js seems terrible in itself. Converting to Go might be useful, if you need more performance or scalability.
- ManlyBread 10y ago
  [citation needed]
macawfish 10y ago
I know how. Cause I just wanna get something done! Then later I come back and rewrite it with a dose of patience. Then my code is much better.
codingdave 10y ago
The other way terrible code gets written by good developers is focusing more on deliver working code that meets the business needs, more than elegant code that meets the needs of future maintainers. Ideal code meets both. I'm sure we all agree on that. But when working on deadlines, under pressure, with poor management, you sometimes write bad code. And if the code is 15 years old, that great engineer you are talking about today was, at the time, an inexperienced new coder. So you didn't inherit his greatest work. You inherited his embarrassment where he made mistakes. I suspect the original authors of the terrible code in question could give much deeper insights into exactly how and why it was done that way.
partycoder 10y ago
Imagine you have a sales team. Initially you tell them: sell $10000 in 1 week. Most of them will go through the traditional selling process. One of them will make a loan on behalf of the company for $10000, and hand you the money right away. If you are smart, you will say that you are not interested in having that money if it comes from a loan. If you are not smart, you will say: "wow, this guy is a 10x salesman, we will give him a bonus". Meanwhile the company gets into an unpayable debt beyond any possibility of paying. Then, when the company is about to die from debt, they declare bankrupcy and start over or sell themselves to be acquired. Now, imagine it's not salesmen, but software engineers, and it's not actual debt, but technical debt, and it's not bankruptcy but starting your project again.
bartread 10y ago
I sort of lost the will to read further at this point: "An important component of this project was the focus on deadlines, even to the detriment of code quality. If your developers have to focus on delivering rather than on writing good code, they will eventually have to compensate to make you happy. " AAAAAAAARGH!!! Seriously? What do you think you're there for? Good code can be a means but never an end. Of course you're there to deliver. And of course it's more important to do that than to write beautiful code. Give me strength.
alexeiz 10y ago
* Giving excessive importance to estimates Seen this one. It was used as a excuse not to do code reviews because they cause to miss estimates. "Look, the feature is done, but because of the code review requirement I cannot mark it 'done' in the project plan." Solution: abolish code reviews. * Assuming that good process fixes bad people This one is a big one. It's everywhere. Especially in big software development companies, such as Microsoft and Google. They tend to believe that once they institute a perfect process, everything works out perfectly. Perfect coding guidelines lead to perfect code, no matter who writes it. Perfect testing process - testing can be done by monkeys. Perfect project management process - now we can hire project managers with just basic Microsoft Excel skills. They don't understand that without actual talent the company enters a "spiral of death" which is impossible to escape. * Ignoring proven practices such as code reviews and unit testing This is done frequently by people who never tried such techniques as code reviews and unit testing. If you do it consistently through, say, one release cycle, you start to value those techniques and understand their importance. Unit testing, for example, helps me to avoid painful debugging complex issues in production. All features that I unit tested usually just work when integrated into the rest of the product. In fact, the last bug I had to fix happened in code that I neglected to unit test, because the unit test setup was too complex for that component (in itself an indirect sign of a problem). Unit tests also lead to components usable independently of each other, thus reducing the overall system coupling. * Hiring developers with no “people” skills This is a double edged sword. On one hand a developer who can't communicate well will eventually produce code that doesn't do what's intended. On the other hand there are people with too much "people" skills who can't code shit. They just bullshit their way through. I'd say there are too many of such bullshitters. A lack of communication skills in a developer is a problem fairly isolated to that developer. A lack of coding skills in a bullshitter is much bigger problem that affect many people around him.
pmarreck 10y ago
> When I found out I would be working on porting an old Python codebase to Node "Out of the frying pan and into the fire" is not a programming direction I would recommend. (I don't think I've met a single Node developer who isn't bitching about it.)

197 points by SarasaNews 10y ago

>porting an old Python codebase to Node Node is how.

I was specially chosen by God and given divine intellect to become His avatar for the divine code of TempleOS. It is divine intellect written by God himself. God says... gloried idiom's welfare's contraband carnally urchins clear's activity stalemating depressing subconsciously intentionally verbs distinguishable staunching Mooney's spanking speculate omnivore Fassbinder Ophelia vehicles kidnapping fresher mammograms kneeling exiting minuscule daydreamer's Chickasaw mattresses torpidity

arcanus 10y ago

All good examples (such as excessive importance to deadlines, a big no-no). My question: can they be truly good programmers of they write bad code? Isn't the essential product of a programmer SLOC and functionality via software? And if they do that in a manner inferior to another dev, isn't that objectively a measure of inferiority in their craft? I've met far too many 'good' programmers who were a net detriment to a project not to be wary of the term.

jondubois 10y ago
Under insufficient time constraints, a good developer will either produce bad code or no code at all (he will resign from the company). This is extremely common. The stuff the author said about too much emphasis on deadlines is spot-on. Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs. For example, if a lead developer doesn't choose the right framework or plan/design the API correctly, then the consequences of that will keep piling up over time. It's really easy to put the blame on people who are doing the 'small work' but in reality, they might be doing the best work possible under the terrible constraints imposed on them.
- lawn 10y ago
  > Some developers who code really fast might appear like they're being extremely productive but behind the scenes, you end up having a whole team of developers who are just fixing that developer's bugs. This is very prevalent at my job. There are a couple of developers who have a reputation of being really fast. "Wow, he closed 25 tickets the last hour!". In reality he mainly rejected them or made quick fixes which didn't work or created new bugs. A not insignificant amount of time in a recent project I had was focused on rewriting code said developer had written.
Clubber 10y ago
Yes and no. Crazy, made up deadlines will throw even the best developer off. They want to, fist and foremost get it done. If everything else is irrelevant, then that's what you will get. Of course that ends up being bad for everybody, but many businesses still don't have a clue on how to operate their most important department. Sometimes you have a hard deadline that you just can't help like a mission critical bug, or the VP of sales promised your most important client an impossible date and there are fines involved. I'm a firm believer of setting aside time for refactoring every X number of releases. That solves a lot of this.
- kpil 10y ago
  You know, it depends... Impossible and strict deadlines simply because of cost control is shooting yourself in the foot. Impossible deadlines because of a really important deal worth actual money, is probably worth sweating over,at the risk of code quality. If all projects tend to be the latter case, it's probably actually the first case packaged as the second...
  - Clubber 10y ago
    Sure, sometimes it's just a matter of survival. Get this code released by this date or we sink. That's an unfortunate place to be in, requires a lot of focus under stress and is rarely rewarded. It's gratifying for me to be successful in those circumstances, but too many of them and I have to find a saner place to work. Management starts to take miracles as the norm by planning them (if they even do) and it leads to burnout.
pyb 10y ago
So true. A 'good' programmer who commits terrible code is a bad programmer. In other words, one trait of a senior developer is knowing to pick your battles. If you can't do good work, you have to get out.
- joeax 10y ago
  I think is is true at the earlier stages of one's career. One you get older and have to start feeding a family, the idealism wears off and you start finding yourself compromising your morals and coding shit to make a deadline. But the company you work for pays you so well, coupled with the expert domain knowledge that makes you nearly irreplaceable, you become complacent. You are a fixed cog in the system. At this point "get out" is not in your best interests.
  - pyb 10y ago
    No one said it was easy...
JustSomeNobody 10y ago
Even good developers have to initially poke at a problem to get it in their head. Once there, then they can write beautiful code to solve it. Therefore, if time is constrained, even good developers will have to ship ugly (but working) code.

lettersdigits 10y ago

a good programmer should be able to identify bad companies to work for, which could solve many of the issues displayed in the article. it's much like choosing a good life partner - choosing a good life partner (instead of a crazy one) will save you from many troubles that you would encounter if you married the wrong person in the first place. ps: i need to tell this more to myself. i already made bad choices regarding where i work, which forced me to quit those jobs at the end.. (edit: spacing)

alkonaut 10y ago
I think a lot of this sentiment overlooks the fact that in most cities the number of software companies is very limited - perhaps allowing one switch in a career if there are huge problems or conflicts, but certainly not enough to allow switching due to e.g poor development practices. What's worse, in these places the poor devs tend to stick around while talented ones leave because they either accept moving or they can find remote work due to good connections or nice SO/GH profiles.
- lettersdigits 10y ago
  you are removing a lot of personal responsibility from the guy who is looking for the job. If you are born in a 'bad' place (regardless of the reason for it being 'bad' - a violent/poor neighborhood, a city without hope for jobs, a small country-side town with no tech industry at all, etc. etc.) - you should be responsible for improving your life/moving to a better city/etc. to analogize from soccer: Messi plays at Bercelona, but is from argentina. Ronaldo plays at Real Radrid, but is from portugal. if ronaldo stayed in portugal, which teams would he be able to play with that would even become close to matching real madrid ? same goes for messi and barcelona. he could have said something like 'i was born in argentina, and no one here plays soccer like barceolna/real madrid. therefore - i will not play soccer because i was born in the wrong place'
  - alkonaut 10y ago
    I think a lot of what you are saying makes sense, but also at some age and family status (kids in schools etc) moving doesn't make sense any more, or has more downsides than one is trying to avoid. Obviously one could have thought of this before marrying and putting kids in school in the town with one tech firm - but that doesn't make it any less a reality for a lot of people. Saying "kids we have to move because dads colleagues refuse to do proper peer reviews" just doesn't taste right :)

joeax 10y ago

Focusing on poor metrics such as “issues closed” or “commits per day” I once worked at a company that used an offshore company to work on certain modules of a large project. They would commit code that my team would have to then code review. We'd see things like large IF-ELSE blocks with minor differences among the conditions (sometimes just one char). I know everyone hates this. Turns out their internal metric was lines of code per day, so they'd bloat the shit out of everything.

Clubber 10y ago
There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs incentivize net without incintivizing quality, i.e. gut the company, get your bonus and get out.
- devoply 10y ago
  Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stupidest thing rationalists ever cooked up. It destroys internal motivation and discipline.
  - Clubber 10y ago
    >is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought out process. A better incentive, in my opinion is: if you release a complete codebase with 0 medium and above defects by X date, you get a free week off, or something of significant value. A free, company branded desk clock doesn't cut it. (that's happened to me before). If a company is trying to save money by hiring the cheapest offshore developers they can, they are still really just throwing away money and aggravating people. lol. That is a perfect example of a poor incentive: cut costs without any regard to the resulting cuts in quality. Anyone can make a turd cheaply, but that's rarely what businesses really want.

pfarnsworth 10y ago

This is a fucking arrogant article. I would love to see this blogger try to maintain a large codebase after several development cycles in the real world. To come into someone else's codebase that has umpteen number of iterations and tough business realities like trying to make money, and proclaiming that it's terrible code and how he would fix it, is delusional and self-aggrandizing. Most production code needs to be revamped every few years because the subsequent unforeseen functionalities that was forced by product managers and customers. That code is usually going against the grain of the original code but you can't blame the original designers because it was never spec'ed out. The best code is the code that is easiest to manipulate and modify, but even then it gets old and needs a rewrite. There's nothing wrong with that, except thinking you can comment on the shitty code and thinking your above it and how you would never let it happen.

lettersdigits 10y ago
> The best code is the code that is easiest to manipulate and modify this great (IMO) article comes to mind: http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to http://programmingisterrible.com/post/139222674273/write-cod... : "Write code that is easy to delete, not easy to extend"
- robnagler 10y ago
  Excellent article, thanks.
jlg23 10y ago
> To come into someone else's codebase that has umpteen number of iterations and tough business realities like trying to make money, and proclaiming that it's terrible code and how he would fix it, is delusional and self-aggrandizing. And yet that is exactly the reality one faces in such projects (because the only valid code metric is "WTFs/minute" [1]. Point is, I've never heard anybody complaining about arrogance until now - usually the devs are very well aware where and how their code sucks and they usually are overly apologetic even though I understand the constraints the code was written under (some of which you described). [1] http://www.osnews.com/images/comics/wtfm.jpg http://www.osnews.com/images/comics/wtfm.jpg

pmarreck 10y ago

The site is now 404'ing so I guess s/he isn't heeding their own warning?

williamdclt 10y ago
500'ing for me. A lot of websites ending up on HN frontpage aren't dimensioned for the traffic it implies, I won't blame them for it
innerspirit 10y ago
Whoops, I think it was a bad CloudFlare setting. Should be working now, hopefully.

dsego 10y ago

I work on a lot of projects like this. The non-techies running the project are usually clueless and programmers are out of touch with modern best practices. The funny thing is that it makes me look slow for not finishing tasks. People in charge want to see features banged out. The guys who write hundred-line if-defs or copy/paste code from one file to another, get to go home at 5pm and live their life. Someone else picks up the tab later. When they need some info from the db, they just add an ajax call and some php function to fetch that and use jQuery to change it on page. I don't even try to refactor this stuff, just breaks everything, so I go along. I won't even say anything about cleaning it up, because it will be assigned to me, while the other guys pile on spaghetti code like there is no tomorrow, good luck merging that.

amelius 10y ago
I sympathize with this, but perhaps it is really more economical to write software like this in your company's case (?)
- Clubber 10y ago
  It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability (read easily add/remove/change features). Companies spend a hell of a lot of money for growth. If they don't know how to manage software development, then the software will nullify all that cost spend on growing, because the system can't handle it. I am truly amazed at how bad many US businesses are at managing their software systems. It's as if they are considered an afterthought rather than the department on which every other department depends. It's simply old fashioned thinking. CEOs are typically older, and the current crop were trained before computers really proliferated business.
  - beagle3 10y ago
    > It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability Still, it depends on the specifics. Many, many projects get redone/canceled/completely respecified after first contact with market / customer. Many are also canceled for reasons that are independent of the progress speed. For all these projects, speed-to-market has value, and long-term-maintainability has absolutely zero. The horror arrives when, in a successful project, you realize that you are going to live with the hastily, horribly, developed project for some time to come. But these might be the exceptions - depending on how you count, some stats claim 80% of software projects get cancelled before completion (Have no idea how they define that) It's a balancing act.

jelder 10y ago

Mirror?

innerspirit 10y ago
https://ponyfoo.com/articles/terrible-code-sane-people https://ponyfoo.com/articles/terrible-code-sane-people

deleted 10y ago

[deleted]

peter_retief 10y ago

I had a quick look at your commentary, its great, the whole issue of rushing code and debugging forever, also nice allusion to anti patterns :) I have bookmarked and will read properly very soon, maybe

erikb 10y ago

Honestly, I think the best developers are not the ones that write beautiful code and put quality above everything else. The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. Because that's real life, and not the pony farm. Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quality and code getting money requires kowtowing and overpromising to someone who currently has money. Second comes qualifying for the money (yes, in real world you get money without having what you are selling, but that's a short-term success). That means getting to ask for money again tomorrow. That is where skill and code come into play. You promised something and now when you are lucky you can deliver 80% of that. Push hard to get there. Not everybody who tries will achieve that much. And only then comes quality, which means qualifying for money next year becomes cheaper. If you realize LIFE is that way, suddenly high quality isn't all that important anymore, is it? Quality is a luxury and you must have achieved A LOT to be in a position to just think about quality. And the ohter people (management, sales) are not total idiots. If you dream the high quality dream they are the people who pay your bills. I am an engineer like you, btw. I was just in the situation already, where I had to pay my bills myself and therefore know what amount of humiliation and sweat is required to get money just for ONE person, me.

projektir 10y ago
> Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quality and code getting money requires kowtowing and overpromising to someone who currently has money. That has little to do with what makes development and a lot more to do with capitalism, business, and markets. What this really means is that current business environments don't necessarily value development, but that doesn't change the definition of development. At this point, you're not discussing a good developer, but a person who can hybridize development and business sense. It's a different skillset, perhaps one that's somewhat contradictory to high quality development, even. There are situations in which there is no money at all, yet you absolutely need good development skills and they are distinguishable (open source). Any given person can be devoted to selling, whether they're coding or weaving baskets, but that doesn't suddenly mean that a core factor of weaving baskets is being able to sell them. It's not. That's a different skill set entirely. It may often not be found side by side. It's a shame that we are so obsessed with money and selling right now that pure skills seem to have little value to some people, despite the fact that many crucial things nonetheless run off of these core skills... This argument is equivalent to saying that only applied science has value.

JamesBarney 10y ago

I like the article but I found the implied solution a little humorous. Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and massochistic enough to stick it out at an obviously poorly run project. Good luck Side note, for 15 years of experience the project doesn't seem that bad by a long shot. I only have ~7 years of experience and have seen some far worse code. I was just recently on a project that has some methods that take 8 call backs(project was greenfielded in Jan 2016) before that I was on a project where the development team copy and paste the source for the last web page every time they needed a new one, but not delete the initialization code that fetched the data from.the database. So the 18th screen they worked on had 26,000 lines of code and took 5 minutes to load. And every button click triggered a reload. So, add a new widget and boom, wait 5 minutes for a screen refresh.

busterarm 10y ago
> Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and masochistic enough to stick it out at an obviously poorly run project. This is a pretty close description of the positions I find myself in as a dev and I don't think this combination of qualities makes me more hirable.
- psyc 10y ago
  It probably won't, because most of that isn't predictable (by the interviewer) at interview time. It could make you more valuable in your current job, though.
  - busterarm 10y ago
    invaluable, but they won't kick me more money. I asked.
    - 10y ago

NumberSix 10y ago

A number of points in the post/article are questionable. First, it assumes the developers had substantial control over the schedule for the project ("Giving excessive importance to estimates"). Certainly in my experience this is unusual. More frequently, the schedule is dictated by management, frequently by sales/marketing executives in commercial software development. It is very difficult to push back and a good way to lose your job. Sales: We have closed this great deal with BigCorp. Can you do X (complicated, challenging software project) by the end of the quarter? Developers: Err, um, X sounds like a project that will take six months. Sales: We really need to make our quarterly numbers. Our CEO Bob used to be a developer and he says any competent programmer can do it and we only hire the best. Competent doesn’t cut it here! You are a rockstar ninja, aren’t you? Can you prove you can’t do it by the end of the quarter? Developers: Well, no. The schedules are driven by some unexpected problem or problems that usually happen. But, well, if nothing unexpected happens, we can do it by the end of the quarter. Sales: Great! Bob is expecting results by the end of the quarter. So much for the beautiful, elegant software design methodologies taught in college and university CS programs and peddled by high priced consultants. Second (“Giving no importance to project knowledge”), high technology employers seem to have extremely high turnover rates of software developers and other employers. Payscale produced a study claiming that the average employee tenure and Amazon and Google is only one year. Many companies seem to target employees with more than seven years of paid work experience — Logan’s Run style — for layoffs and “constructive discharge,” (https://en.wikipedia.org/wiki/Constructive_dismissal https://en.wikipedia.org/wiki/Constructive_dismissal) where employees are made uncomfortable and quit “voluntarily.” Undoubtedly, this is costly as the author implies, but it seems to be common practice. Yes, metrics like “issues closed,” “commits per day,” or “lines of code” don’t work very well. Once employees realize they are being tracked and evaluated on some metric, they have a strong motivation to figure out how to manipulate the metric. Even if the employees don’t try to manipulate the metrics, the metrics all have serious weaknesses and map imperfectly to value added (biz speak). Third, are code reviews and unit testing proven processes especially for normal non-Microsoft companies? In the early days of Test Driven Development (TDD), Kent Beck and his colleagues made numerous claims about the success of Test Driven Development in the Chrysler Comprehensive Compensation System (C3) payroll project, an attempt to create a unified company wide payroll system for Chrysler. This project in fact had a range of problems and was eventually cancelled by Chrysler in 2000, without replacing the Chrysler payroll systems successfully. As the problems with C3 have become well documented and well known, TDD enthusiasts have shifted to citing studies at Microsoft and some other gigantic companies that claim practices like TDD and code reviews work well. Are these really true or do these case studies have hidden issues as C3 did? Further, Microsoft, Google, and other companies that have played a big role in promoting these practices are very unusual companies, phenomenally successful super-unicorns with sales in the range of 40-100 billion (with a B) dollars with near monopoly positions and anomalously high revenues and frequently profits per employee. Microsoft claims to have revenues of $732,224 per employee. Google claims an astonishing $1,154,896 per employee. (http://www.businessinsider.com/top-tech-companies-revenue-per-employee-2015-10/ http://www.businessinsider.com/top-tech-companies-revenue-pe...) This compares to $100-200,000 per employee for most successful companies. Fergus Henderson at Google recently published an article on Google’s software engineering practices (https://arxiv.org/abs/1702.01715 https://arxiv.org/abs/1702.01715) with the following statements: 2.11. Frequent rewrites Most software at Google gets rewritten every few years. This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. Note: “incredibly costly” Companies like Microsoft and Google have enormous resources including monopoly power and can follow practices that are extremely costly and inefficient, which may work for them. Even if these practices are quite harmful, they have the resources to succeed nonetheless — at least for the immediate future, the next five years. From a business point of view, it may even be in the interests of Microsoft, Google, and other giant near monopolies to promote software development practices that smaller competitors and potential competitors simply can’t afford and that will bankrupt them if adopted. Both code reviews and unit tests are clearly time consuming up front. Code reviews using tools like Google’s Gerrit or Phabricator (a spin-off from Facebook, another super-unicorn) are committee meetings on every line of code. Regarding: Imagine my dismay when I had to collaborate with a colleague on that legacy project and his screen displayed Notepad in its full glory. Using “search” to find methods might have been rad back in the nineties, but these days, refraining from using tools such as modern IDEs, version control and code inspection will set you back tremendously. They are now absolutely required for projects of any size. Using “search” to find methods was not rad back in the 1990’s. IDE’s and code browsers specifically have been in widespread use since the 1980’s. Turbo Pascal (https://en.wikipedia.org/wiki/Turbo_Pascal https://en.wikipedia.org/wiki/Turbo_Pascal) was introduced in 1983 and featured a fully functional IDE, soon to be followed by IDE’s in many other products. Version control dates back at least to SCCS (https://en.wikipedia.org/wiki/Source_Code_Control_System https://en.wikipedia.org/wiki/Source_Code_Control_System) which was released in 1972. RCS was released in 1981 and version control was common in the 1980s and since. Code reviews have been around for a long time. However, in the 1990’s and earlier they were restricted to relatively special projects such as the Space Shuttle avionics where very high levels or safety and reliability, far beyond most commercial software, were required. This speaks to the “incredibly costly” quote about Google above. Without more context, it is difficult to evaluate the use of Notepad. Simple code/text editors like Notepad and vim (formerly vi ) are very fast to start up and can be a better option for some quick projects than starting an IDE. Some IDE’s are particularly hard to use. Early versions of Apple’s Xcode circa 2010 were particularly difficult to use in practice; it has improved somewhat in the current releases. People vary significantly. Some developers seem to find stripped down tools like vim or Notepad or Notepad++ (on Windows) a better option than complicated IDE’s. I am more of an emacs or IDE person. The fact that someone else works differently than you do does not mean they are worse (or better) than you. The fact that something works well for someone else also does not mean it will work well for you — or vice versa. There are sound reasons for duplicating code, cutting and pasting, rather than creating a function or object called in several location in the code. If the developer anticipates that the code may subsequently diverge, then duplication is often best. Like grand master chess players, highly experienced developers, especially under tight time constraints (like a chess tournament), code by intuition, not by laboriously reasoning out every step. If it feels like the code is likely to diverge in the future, duplicate. If it does not diverge, no problem, it can be merged back later if needed. In the bad old days of structured design (1980’s) and object-oriented design (OOD — 1990s), software development projects suffered from Big Design Up Front (BDUF), grandiose attempts to design a perfect software system before writing a line of code. This often resulted in massive cost and schedule overruns and total failures. It often proves better to just throw (“hack”) something together quickly — a prototype, proof of concept, Minimum Viable Product (MVP). Just “get something working.” Inevitably these prototypes and early stage software projects are going to compare poorly to some theoretical perfectly designed system with 20-20 hindsight. That is what seduced people into BDUF twenty, thirty years ago. Modern Agile software development methodologies are foolishly trying to have it both ways, have an initial quick iteration BUT that first iteration should be perfectly designed up front — beautiful, elegant, with hundreds of tests, endless committee meetings on coding style and design (code reviews), all sorts of supposed best practices, no code duplication, etc. This is a seductive fantasy doomed to fail in most cases.

EliRivers 10y ago

"mixed spaces/tabs for indentation" If that's the second thing in the list of problems, the problems aren't nearly so bad or the author's got a savage case of mixing in the trivial with the important.

jinglebells 10y ago
I'd say it's like smelling smoke. If your team can't even agree on a standard indent and stick to it, and you haven't got a linter which picks it up, what else are they missing?

doggydogs94 10y ago

The key word is "deadline". Horrible code that works beats beautiful code that has not been thoroughly tested.

JustSomeNobody 10y ago
Along those same thoughts, you put many developers in a room and they end up converging on "the one true architecture" and nothing ever ships but you have this monstrosity with some very beautiful code in it. Put few developers in a room and you get decent code and a solution to the problem that actually ships.

dahart 10y ago

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking about ground up rewrites. All 3 had people complaining about every single example the author used. Two of them undertook the ground up rewrite estimating one year. Both admitted to having made a huge mistake 3-5 years later. My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. We all have code ideals we believe and talk about that don't work as well in the real world as we imagined. We all have deadlines that are shorter than we want -- it's a universal constant. We all imagine we can write code and fix big problems faster than we really can. And we all fail to fully understand what's working right in a messy large codebase and tend to focus on what's wrong. I don't know how to fix this, but it's very possible the author ran into thoughtful paradigms he just hadn't seen before and didn't fully understand. Some styles seem messy if you haven't seen them before. React is an intentional lack of separation of concerns between code and markup. Some projects are required to mix tabs and spaces depending on tools. For that matter, bash scripts alone require mixing tabs and spaces for some features. And so on, it's important to have context for why things are the way they are before jumping to the conclusion that it's bad.

SatvikBeri 10y ago
> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases. I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication.

SatvikBeri 10y ago

One thing I've been thinking about more and more is code that's easy to delete. For example, we recently built a data pipeline that did a bunch of processing and wrote data to a SQL database at the end. For various reasons, there was an unscalable, quick way to implement the write, and a scalable, slow way to do it. We wanted to get the product to testing ASAP, so we chose the quick way initially. In order to make sure that we could easily replace that code, we ended up creating a separate write function for each table, where the function did nothing else except the write. That involved a lot of duplication, but made it easy to move the tables over to a better method one by one later. It seems like having functions with one purpose, pure if possible, is a pretty good way to ensure "upgradeable" code–even if the internals of the function are messy, you just have to write a new one that copies the same functionality. Furthermore, I've found single responsibility functions to be easier to enforce in code reviews than single responsibility classes.

VLM 10y ago
I would agree with that goal and extend with a different anecdote that the articles "project knowledge" section should include documenting the weird requirements and unusual interfaces to other projects. Many times I've run into five year old program logic, pondered why in the world anyone (me) would had done something that weird, and realized the project or tool requiring that weirdness was cancelled three years ago long enough that I've forgotten about it. Its not as simple sometimes as just baking into the single function that talks to the API, sometimes it gets baked into weird corners of the application logic.
iaml 10y ago
What you are describing seems very familiar to the idea in this [0] talk that I saw mentioned in the other thread on HN. Basically, the speaker argues that any codebase has a tendency to become a big bloated mess. The proposed solution to that is writing highly modular code that you can easily rewrite from scratch in a week. [0] https://vimeo.com/108441214 https://vimeo.com/108441214
- SatvikBeri 10y ago
  This is great! Much more fleshed out than my post.

mannykannot 10y ago

"The authors created their own framework..." I cannot say this was an issue here, but I can say that some of the worst messes I have seen have followed from this decision. In all such cases in my experience, it was not a technically justifiable decision, and I strongly suspect it was driven by developer ego and overconfidence. The very worst included a roll-your-own language.

Pica_soO 10y ago
Eh, DSL scripting languages have a right to exist.
- mannykannot 10y ago
  If someone was suggesting otherwise, you might have a point worth raising. But now that you have introduced this non-sequitur, I will freely assert that our rights trump those of bad DSLs to exist. I suspect that if you had seen the specific case I am referring to, you would agree.
tonyedgecombe 10y ago
We've all done it though.

lunz 10y ago

Perhaps the team planned a rewrite long ago and stopped worrying about the quality of their code, which seemed obsolete in the moment it was written. Over the years, however, there was always something more important than the "soon-to-be" rewrite.

hinkley 10y ago

I work with a team that managed to write the code he describes in a little over three years. it's really just chaos and I only trust a few of them. So why do I keep talking myself out of looking for a new job? Hell if I know.

Animats 10y ago

Converting Python to node.js seems terrible in itself. Converting to Go might be useful, if you need more performance or scalability.

ManlyBread 10y ago
[citation needed]

macawfish 10y ago

I know how. Cause I just wanna get something done! Then later I come back and rewrite it with a dose of patience. Then my code is much better.

codingdave 10y ago

The other way terrible code gets written by good developers is focusing more on deliver working code that meets the business needs, more than elegant code that meets the needs of future maintainers. Ideal code meets both. I'm sure we all agree on that. But when working on deadlines, under pressure, with poor management, you sometimes write bad code. And if the code is 15 years old, that great engineer you are talking about today was, at the time, an inexperienced new coder. So you didn't inherit his greatest work. You inherited his embarrassment where he made mistakes. I suspect the original authors of the terrible code in question could give much deeper insights into exactly how and why it was done that way.

partycoder 10y ago

Imagine you have a sales team. Initially you tell them: sell $10000 in 1 week. Most of them will go through the traditional selling process. One of them will make a loan on behalf of the company for $10000, and hand you the money right away. If you are smart, you will say that you are not interested in having that money if it comes from a loan. If you are not smart, you will say: "wow, this guy is a 10x salesman, we will give him a bonus". Meanwhile the company gets into an unpayable debt beyond any possibility of paying. Then, when the company is about to die from debt, they declare bankrupcy and start over or sell themselves to be acquired. Now, imagine it's not salesmen, but software engineers, and it's not actual debt, but technical debt, and it's not bankruptcy but starting your project again.

bartread 10y ago

I sort of lost the will to read further at this point: "An important component of this project was the focus on deadlines, even to the detriment of code quality. If your developers have to focus on delivering rather than on writing good code, they will eventually have to compensate to make you happy. " AAAAAAAARGH!!! Seriously? What do you think you're there for? Good code can be a means but never an end. Of course you're there to deliver. And of course it's more important to do that than to write beautiful code. Give me strength.

alexeiz 10y ago

* Giving excessive importance to estimates Seen this one. It was used as a excuse not to do code reviews because they cause to miss estimates. "Look, the feature is done, but because of the code review requirement I cannot mark it 'done' in the project plan." Solution: abolish code reviews. * Assuming that good process fixes bad people This one is a big one. It's everywhere. Especially in big software development companies, such as Microsoft and Google. They tend to believe that once they institute a perfect process, everything works out perfectly. Perfect coding guidelines lead to perfect code, no matter who writes it. Perfect testing process - testing can be done by monkeys. Perfect project management process - now we can hire project managers with just basic Microsoft Excel skills. They don't understand that without actual talent the company enters a "spiral of death" which is impossible to escape. * Ignoring proven practices such as code reviews and unit testing This is done frequently by people who never tried such techniques as code reviews and unit testing. If you do it consistently through, say, one release cycle, you start to value those techniques and understand their importance. Unit testing, for example, helps me to avoid painful debugging complex issues in production. All features that I unit tested usually just work when integrated into the rest of the product. In fact, the last bug I had to fix happened in code that I neglected to unit test, because the unit test setup was too complex for that component (in itself an indirect sign of a problem). Unit tests also lead to components usable independently of each other, thus reducing the overall system coupling. * Hiring developers with no “people” skills This is a double edged sword. On one hand a developer who can't communicate well will eventually produce code that doesn't do what's intended. On the other hand there are people with too much "people" skills who can't code shit. They just bullshit their way through. I'd say there are too many of such bullshitters. A lack of communication skills in a developer is a problem fairly isolated to that developer. A lack of coding skills in a bullshitter is much bigger problem that affect many people around him.

pmarreck 10y ago

> When I found out I would be working on porting an old Python codebase to Node "Out of the frying pan and into the fire" is not a programming direction I would recommend. (I don't think I've met a single Node developer who isn't bitching about it.)