39 ms·

The Generational Divide in Software Developers

156 points by daverol 5y ago

sblom 5y ago
This essay is rooted in nostalgia and reads as a post facto justification for "I like the old way better". "I've never done waterfall" or "we specified everything (on paper! millennials don't read amirite) before we built it", which is it? There's a whole lot of generalizing from personal experience to "universal truths" that simply aren't universal. or even truths? For instance, there are certainly some teams that get value out of code reviews.
- leethomas 5y ago
  I agree that the article generalizes, basically to the point of condescension. Were you “there” though? I wasn’t so genuinely curious if his recollection reflects reality. EDIT: they responded to another parent comment I created and were definitely working at Microsoft during the period.
  - kennytilton 5y ago
    Started programming in 1981. His recollection is correct. We were agile. Today's "Agile" is a disaster. We are not being condescending, we are mourning what once was an uninterrupted delight.
- Miiko 5y ago
  > "I've never done waterfall" Yes, that's correct, I've never done waterfall either. By definition [1] "The waterfall model has, at least, five to seven phases that follow in strict linear order, where a phase can’t begin until the previous phase has been completed." (emphasis mine) - we never did that, and I never heard of anybody following that model. All these steps has to overlap - it is not possible to write good requirements without having at least draft design etc - and they surely did. [1] https://www.projectmanager.com/waterfall-methodology https://www.projectmanager.com/waterfall-methodology
- metalforever 5y ago
  Okay, let me explain this. The way it's actually done is in-between. You can't really seriously agile your way into a great distributed architecture without some sort of planning process. You create a very high level document explaining the main components of the program. You make a second one with details (in a waterfall way) explaining everything you are going to be concentrating on in depth for the next 1-2 months. The rest is kept very high level. Then you can just change course if the reception of the 1-2 month work isn't ideal or the company needs to change direction.
leethomas 5y ago
Could someone of the appropriate age group with experience please confirm for me if everything this guy is saying was true generally speaking? I’m honestly curious as I’m too young to know myself and I have no way of knowing whether the article was written with rose tinted glasses on. But wow if it’s accurate the point about meetings and concentration sounds amazing, would love to go back to that.
- sblom 5y ago
  My experience at Microsoft in the late 90s and early 00s jives with his descriptions, mostly. But the essay went out of its way to be cynical and reductive. He's not making things up, but I don't think his takeaways are worth, well, taking any further.
  - leethomas 5y ago
    So culturally which style of working do you prefer yourself? Or if it’s not binary, are there parts of how software was written yesterday that you’d like to bring into organizations today, whether mentioned in the article or not?
    - sblom 5y ago
      There's room for both extreme concentration and extreme communication, and most teams need some of each. I actually snorted at the essay's idea that communication and concentration can't mix. I'm not sure what he thinks email and detailed specs are if not communication. I think the key is that they're batch-mode communication. I can see value in several hours a day of concentration unbroken by communication, but insisting on a full week straight of unbroken concentration is impractical and possibly counterproductive.
      - France_is_bacon 5y ago
        It's not that there was NO communication. He said that he'd go to QA and fix anything that they found. It's just that it was more informal, and you did it when it was time to do it, but not just meetings every day that are required, even when there's nothing really to say, or what couldn't be done in a 15 second or one minute conversation. And you could do it on your own time, so you didn't have to stop right in the middle of some super productive time when you're on a roll. Because that's how it works - some coding time is more productive than other time. You're just into it and everything is just flowing, as he said.
davesmylie 5y ago
Back in my day, we'd write our webpages such that they would load on mobile with requiring the user to enable javascript... And we liked it that way!
discordance 5y ago
Testing is important, regardless of the era you develop software in. Focus is also important, even these days. This guy worked at Microsoft in 90's - 00's, and claims that it's the lack of concentration these days that leads to buggy code. I've used a lot of MS stuff in the last 30 years and there were many bugs and instabilities. One of the most brilliant things I use these days is our CI/CD pipelines, which has enabled many individuals to collaborate, and deploy (mostly) reliable code to production frequently, daily if not hourly. Tests are critical in enabling this. Perhaps the poster's views make more sense for waterfall-ish, once every 6 monthly or yearly releases.
- username90 5y ago
  In the early 90s you had a few megabytes of ram, running out of ram was a normal thing so your programs had to handle it everywhere. That makes the kind of testing we do on modern computers useless, our tests only works if we don't have ram issues or other parts of the system fails. The fact that programs back then still worked quite reliably is a miracle. And then you look at today when hardware is super reliable, people have forgotten that running out of ram can lead to bugs etc, yet we still have plenty of strange bugs in software that never should have had any bugs in the first place. If people today learned systems and wrote things with the same care they did back then you wouldn't have all of those bugs. But instead shipping bugs is fine etc, we took all the advancements and used it to push features faster rather than make things reliable.
- lambdasquirrel 5y ago
  Yeah, I agreed with the article except on testing / QA. I was skeptical of these at first too, but in retrospect, it was not okay to externalize the cost of testing onto other people. In those companies I've worked where we released in some waterfall-ish manner and/or QA was important, we have both.
ckolkey 5y ago
It strikes me as odd that in one breath he says "Learning was part of the job" and spends nearly the rest of the piece complaining about writing tests. Maybe he could learn how to do it better :)
- postalrat 5y ago
  Would you say the same thing about writing all the documentation? Or writing all the marketing?
irrational 5y ago
I work for a Fortune 500 company. Through a strange set of circumstances I ended up as a developer embedded in a business unit for 18 years. It was very much like the “then” described in the article. No ceremonial meetings, no sprints, given offices with doors, etc. Then the company decided to consolidate all tech people. For the past 2 years I’ve had an IT manager. I am absolutely astounded how much time is wasted in the modern IT world. Ceremonial meetings, recurring meetings, sprints, etc. I’d say I’m 10% as effective as before. I seriously have weeks were I spend a single hour writing code. And the IT managers are perfectly okay with this! It blows my mind how utterly inefficient they have managed to make coding and the results are definitely not any better. Oh, and the QA thing. Anyone that thinks test driven development can replace a dedicated QA person, clearly has no business working in the world of software development. But, I’ve found that I can’t actually say any of this out loud at work. The IT managers are so brainwashed that they can’t see the reality of what is going on. I’m convinced all of this is for the purpose of giving IT managers something to do to justify their existence.
- sam_lowry_ 5y ago
  I am seeing this shift between then and now as natural growth of bullshit jobs.
- vidanay 5y ago
  20 years at a division of a F500 company here. Luckily, we have not been sidelined into the ceremony and incantations of "modern" software development. Our most formalized process is a very strong PLM (Product Lifecycle Management) workflow.
- France_is_bacon 5y ago
  As I wrote elsewhere, it all depends on the size of the department, and the manager. If you work where there's 3-15 in the tech department, either a small unit of a large company, or just a small or medium-sized company, you have more autonomy and authority. But if you are one of 200 programmers, then no. That was true back then as I'm sure it is now. In the same respects, if you have a sh-t manager back then, big company or small, it is the same thing. Micromanaging, time-wasting, with a sh-tty boss. Or you could have a great manager back then or now, who keeps general tabs on things, and only starts getting to become a micromanager if the person under them starts f-cking up, which as it should be. But let's say you work at a large plumbing company with 200 plumbers, and you have a tech department of 7 people and an admin staff of 25. The CEO is a plumber and what does he know about tech, the COO is working on coordinating trucks and insurance and personnel and all kinds of other things, and the CFO has his hands busy just keeping up with accounting. Nobody is going to mess with you, as long as YOU don't mess up. They don't even know how to help you, and they are too busy with their own sh-t. Except in the biggest picture view, of course. Then, all you have to hope for is that the manager is good. Usually they are, because they are busy. But I've worked at Fortune 500 companies in local offices or regions where I was the only person doing what I was doing, and absolutely no one bothered me, because I was there by myself. Sure, I talked to a lot of people in the company to see what they needed to have done, but after that, my time was my own. I can't imagine it would be any different now, in the same circumstances.
js8 5y ago
When I started as SWE, I was (more or less by accident) educated in the old way. And I, like the OP, don't like the new way. I think the article is spot on in the factual, although of course it is biased in preference and author makes that clear. (And it pains me that people in the discussion are not really hearing the nuance, just like youngsters often don't listen to the older generation.) I have a brilliant coworker, who enjoys the new way, and we disagree a lot, and I think the article summarizes our disagreement very well. Ultimately, I think the divide comes down to your optimization horizon. In the old days, software was made to last longer, and there was more time to plan and design it properly, because the horizon was longer. Today, the horizon has been shortened, and more experimentation is done, and less forward thinking. And so the methods are different, and most of these differences (as described in the article) accounts to the shortening of the optimization horizon. I do prefer longer horizon, because I feel that if you have series of short horizons, you're not optimizing as well as you could, and spend too much time rebuilding stuff in an incoherent architecture. But the business seems to prefer the short horizon, for various reasons (one might be simply competition, the red queen effect of sorts). I think from an engineering perspective, this is a mistake (there is a reason why we don't build houses in "agile" way), but I came to recognize that neither side is actually "right". But I am going to appeal, if you are trying to build software that lasts, think about your time horizon, maybe you will find that you can actually use the past approach better, if your horizon is longer.
- MeinBlutIstBlau 5y ago
  I like the new way because it's very easy to get through the day without working and pretending you work. I like the old way because it makes coding expectations more realistic and enjoyable.
- commandlinefan 5y ago
  > don't like the new way I think that's the wrong way of looking at it (or phrasing it). I'm sure people that pick vegetables all day don't like the heat, or the dirt, or the bugs, or the fact that vegetables grow so low to the ground, but those things are immutable reality that can't be changed, so they have to adjust to them. Nothing about modern "Agile" software development is immutable so the better question is "does this produce better software?" It should be abundantly clear at this point that it does not - that although there were deficiencies in the software of the 20th century, those deficiencies pale in comparison to those of the modern day, in spite of the fact that our computers are orders of magnitude better. It doesn't matter whether we like the way things are done, what matters is that it's exponentially inferior.
hdjjhhvvhga 5y ago
As any rant it needs to be taken with a grain of salt. This one, however, is very true: > I and everyone I have ever talked to about testing has had the same experience; we write a new feature, test the hell out of it, can’t find anything wrong; ask a coworker to take a crack at it, and he finds a major bug in under a minute. The password is blind spots, and we all have them. And if we didn’t think of some case in development, we are not going to think of it in testing. That’s why we had separate QA departments. I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs, but it's only a a part of the equation. But it's not like all companies removed their QA departments either - many pieces of software are regularly tested by independent teams with good results. If someone thinks TTD will eliminate all bugs, well, they're not thinking clearly.
- js8 5y ago
  > I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs I am skeptical of TDD, so I have a genuine question. Let's say TDD is able to find the "most obvious" bugs, like a typo. My question is, why are these bugs worth creating a test for them, compared to either manual testing (running the program and looking at the output) or running a portion of the integrated test suite on the code to find them? If the bug is simple and crippling, then the program is likely to fail anyway. To me there is a tradeoff. With TDD, you write some unit test code, and it finds a trivial bug. But is every trivial bug found worth maintaining the unit test code going forward? I mean it's not like this bug is gonna appear again all of sudden in your code, unless you change it, but then in all likelihood you need to change your unit test as well. I guess I don't really see TDD as a good tool, because all the situations that you can run into are already covered by other, more specialized tools. If you want to catch edge cases, asserts are IMHO superior tool to tests. If you want to verify your program quickly, running it manually and looking at the output is superior. If you want to verify your program properly, running a comprehensive (and integrated) test suite is superior (the best if you can make it property-based). There are situations where unit tests are genuinely useful, like writing a library. But in those cases, unit tests seem to always either compare with some other implementation (for example, if I am testing a sin(x) function, my other implementation is the calculator), or at least compare with well-defined specification that comes outside the code. But I feel like majority of tests written for TDD are not really testing the code against anything (simply because another implementation or specification is not available), they just test the intent of the code itself as is written, which might be useful if you wanted to write "bar" but wrote "baz" by accident, but other than this type of bugs, what is their long-term contribution, that could justify the maintenance cost?
BoredomHeights 5y ago
A lot of things in the article I think most younger software engineers would agree with (I'm mid 30s for context, so around where he seemingly put the divide, definitely not an OG). Almost everyone I've ever met wants less meetings and more time to focus/code. I understand if this may be something that has changed over time but I definitely don't think it's something younger engineers want, even if they do have to deal with it. If anything I think they'd relate most since they've always had to get their work done with less time to actually focus. I also hate the idea of daily check ins/standups and don't like two week sprints, but we don't do either of those and I haven't at previous companies. Other things mentioned I just don't think are actually true about modern software development, although possibly it depends on your company. I've worked mostly in FAANG companies and we absolutely spend a ton of time on design. And I think this is where collaboration, team cohesion, etc. is so important. The design phase is where you need that communication, then you ideally separate and focus on your own work solo. Then maybe get some review etc. (though like he mentioned, I agree code reviews themselves are relatively pointless, I haven't done one since working at a smaller company). But during the design and somewhat ongoing it can be extremely helpful to know what partner teams and engineers are working on (though daily updates absolutely are not needed). My biggest takeaway from the article is that he really, really, hates writing unit tests. I see pros and cons for both approaches honestly. As a software developer I would love someone else (dedicated QA) to handle a lot of this for me. I don't know if that's necessarily actually better from a company perspective though (not saying it's not either). It definitely makes scaling tougher for very large companies. Who's QA on a 3 person team (or "group") for example, does every team need dedicated QA? When is it worth having? Obviously that's something that can potentially be solved, but it's not necessarily easier or worth it. My experience though is that at best it's extremely exaggerated to state that unit tests are the main focus these days. In total I maybe spend two weeks a year writing tests, if that. As for documentation and learning on the job my experience also doesn't stack up, and this is maybe the part I feel like the article comes closest to "old man yells at cloud". You are absolutely expected to constantly be learning and improving on the job and you better have read all relevant documentation. The first thing that happens on any team I join is I'm given pages and pages of documentation to go through. I spend most of my early time on teams literally studying it and taking notes. I think a lot of the "back in my day" quotes in regards to these topics are some of the most out of touch in this article. "We didn't have stack overflow so we had to..." So what? Stack Overflow exists now, people adjust. It can also be a learning tool in and of itself. Overall I think some of the major points may be true (though as mentioned I don't necessarily think younger engineers would actually disagree with those points). I've never worked at Microsoft specifically so can't say what it's like there, maybe a lot of this is more accurate. I don't think I read very much that I think actually shows a divide between software developers of each generation though, other than speculation that younger developers can't concentrate.
MrDresden 5y ago
I would be in the younger category, as I've only been in the industry for little over a decade. I do though fully agree with many of the points in the article, and desperately wished we could actually change the corporate culture around SW development. However I've come to the conclusion, after years of trying, that it simply can't be done. At least not in companies that have reached a certain size. The 'agile' managerial mantra, along with all of the other bad practices that usually accompany it at cargo cult workplaces (managers that constantly work on 'optimizing' procedures and creating 'effective' teams, too many too long meetings, excessive documentation, lack of space to think and ponder, lack of private silent spaces, etc), is simply too entranched in the manager layer and company culture at these places to ever change. The only times I've had the option of silent uninterupted deep work (i.e flow) has been when working at startups that were started and run by other SWD's who knew what worked and what doesn't. And regarding this point: "Instead of distributing projects between “teams” (sorry, that word makes me think of sports, we were “groups” back then)..." I believe this is done exactly to make it feel we are like a sports team competing with other teams for a price. It makes it much easier to sell layoffs to the rest of the team when they happen ("we had to let Steffany go, she just wasn't an 'effective' 'team' player") Edit: I will add that there are many good points in the agile manifesto that I belive would make sense if done correctly. The market place of 'agile' consultance has simply twisted it into a unrecognizable mess and so the corporate culture trying to implement it falls horribly short (and in the wrong direction) of doing so correctly
loopz 5y ago
Building software for the one developer vs building software for the company and customers (company first because they will support the customers). What went wrong with agility is that it turned into Agile, a concept sold by consultants to be co-opted by management. We should absolutely stop coining the phrase "team" though. Everything about it and the rituals are only for enforcing control and disrupting creative work. The "sports" metaphors are only avenues of manipulation and abuse. Sadly it works best on the youngest generation. The old way where a few devs could hold entire companies hostage is over forever though. Nothing wrong with pairing and teaching others. But it is work, work both the new way and the old way is very adverse to do.
dave333 5y ago
It's ironic that my first paid job at Racal in the UK working on computer aided design software in assembler running on shared fridge sized minicomputers with 64K RAM got many SW development truisms right. Desks all in one large room with collaborators (we didn't know this word yet) next to each other for easy questions/conversation when needed. Room was quiet at all times so no problem getting into the flow. Tea break mid morning and afternoon when the tea lady wheeled a cart round with a big tea URN (sweet and slightly milky no options) and various candy/sweets cookies/biscuits or chips/crisps. We would all get up from our desks and line up near the URN and chat/collaborate similarly to how people do at water coolers I understand. Lunch in the company cafeteria or out at a local pub if there was some event. More collaboration. After lunch we usually all (most of us) played the board game Diplomacy at one move per day. This is the perfect team building tool. What could be a better way to get to know each other than by building alliances to go to war with your comrades and/or stabbing them in the back? No external frameworks - most of the senior folks would create a few common functions or have some from previous projects that could be shared. It was all downhill from there.
- selfhoster11 5y ago
  That sounds like an entirely different experience from today.
  - dave333 5y ago
    Yes - my point is that that first job got most things right about how to organize sw development despite the primitive state of hardware and software. So called methodologies have made things worse mostly.
    - selfhoster11 5y ago
      It's not just that, it's the human touch (or should I say, analogue touch) of this kind of development. The tea cart, the (presumably) not as hectic pace, and definitely no Slack window tearing into your psyche with each new notification.
neilv 5y ago
There's a lot of truth in this article, and (in the marketplace of ideas) it confronts a lot of recent popular thinking that's been maybe a bit too echo chamber-y. It's too bad it was posted on HN over the weekend (and looks like it might've fallen off the front page pretty quickly), but maybe it will get a second chance in HN primetime.
- swyx 5y ago
  Its 10am PT on Monday and on the front page, and the time stamp on the post is "5 hours ago" so not the weekend - you must have seen it during the weekend, yet your comment says "1 hour ago". So does the HN second chance pool also reset comment timestamps? interesting.
  - neilv 5y ago
    I think divine intercession by `dang` gave it a second chance.
  - thrower123 5y ago
    It's really bizarre sometimes when articles in the second-chance pool have a few comments on them when they get rolled forward. It almost makes me wonder if comment timestamps are stored relative to the parent post...
oneplane 5y ago
Devil's advocate: the difference between then and now is also in the visibility and metrics. If you have some black-box 'software coder' in an office that might pump out an artifact six times per year, do you really have any clue what is going on, what you are paying them for or how it stacks up against others, other tasks, other jobs, other features or other investments? And what if you need a feature now, and in a few weeks you need a different feature? What if there is a customer demand that changes, do you just continue building the 'old' request that is now worthless on delivery?
nostrademons 5y ago
I'd say that the really huge generational divide is the supply-chainification of software development. I'm just barely old enough to remember the days when a software engineer was responsible for everything between the hardware and the UX. You wrote code that implemented algorithms and data structures; and made choices between what would be computed in CPU, stored in RAM, or paged to disk; and worked on the whole program from the network or disk layer up to the UI. Now all of these are different roles. You have backend engineers and data engineers and data scientists and front-end engineers (who only deal with modern Javascript and its dozens of frameworks - even 10 years ago a front-end engineer was expected to know how a webserver and HTTP worked) and mobile engineers and AWS experts and Docker/Kubernetes experts to orchestrate it all. If you're actually responsible for the whole program, that's an architect or tech lead role and you don't actually write a whole lot of code. The jobs of each of the people who do write code largely consists of gluing together existing industry-standard frameworks. Algorithms and data structures are stuff you solve on a whiteboard to get the job, and then you never use them once you have the job. It's the natural evolution of an industry, but it does make the job a lot less interesting. The observations the author makes are a natural outgrowth of this - when you have a lot of separate roles collaborating to build a program rather than a single person designing the whole thing, you need a lot more meetings and e-mails and testing.
- rachelbythebay 5y ago
  I suspect a lot of these extra steps are not contributing positively to the product. If two solid people could get the same result and there are two dozen people on something, where is all of that extra effort going? We don’t talk too much about this.
  - thinkharderdev 5y ago
    If two people could get the same result then that would be strictly better, but I think the issue is that two people couldn't (or at least the two people you actually have instead of two hypothetical people who maybe were more capable). But output doesn't scale linearly with number of people involved due to various coordination/communication issues. So I think the root of the intuition we have that there is more "wasted" effort is just that people are building larger, more complex systems that need larger teams to build and the larger teams spend more effort (on a per-person basis) on coordination.
wldcordeiro 5y ago
The author of this post sure seems like a fun fellow. > If your profile includes pronoun pairs I will likely block you. If "they/them," I will definitely block you. https://twitter.com/ComposerDark https://twitter.com/ComposerDark
- throwslackforce 5y ago
  I don't see any connection to this twitter user from the article at all.
  - delecti 5y ago
    The author's twitter is linked from their profile page on hackernoon.
  - wldcordeiro 5y ago
    Look at the left hand sidebar of the article with the author info. There's a Facebook and Twitter icon.
    - throwslackforce 5y ago
      Thanks for clarifying. I don't think I've ever actually clicked one of those "social networking" icons so didn't realize that's where it was going. (I had grepped the text for the name instead).
  - shadowoflight 5y ago
    There's a twitter icon underneath the author's name that links to that twitter profile...
- wppick 5y ago
  Ad hominem. We don't need to do a background check on every author of an article, we can just focus on and discuss the contents
  - rbanffy 5y ago
thinkharderdev 5y ago
Obviously this post is hyperbolic to make a point and I think I agree with some of it. But one thing that I think is a straw man is saying that "Developers are their own testers" which I think is profoundly missing the point of modern software testing. It's not that you should just "test your own code" and toss it in production, it's that testing is part of the software development process and "developers" should be full participants in everything from designing/developing code to testing it. And that means, yes when you develop a new feature you also need to deliver automated tests for that feature and not just throw it over the wall to "QA" to test it.
- the_arun 5y ago
  I agree with you because it makes me accountable for what I am building and be empathetic with my customers as well. I also agree with the point about "Blind Spot" from the author. It is just another perspective. Software is used by multiple users and "it works for me" is not encouraged unless we are building for one user. So, we need to get feedback from others and improve to address more kinds of users.
- scotty79 5y ago
  Developers make a absolutely horrible testers. It requires completely different skillset. It's pure arrogance that developers can do anything, including testing. And automated tests only test things that developer thought about. If anything developer of given piece of code should be expressly forbidden from delivering automated test for his code and other developer should be tasked with this with guiding goal of making the test fail on the initial implementation from the first developer.
  - xupybd 5y ago
    Automated tests are brilliant in maintenance mode. Find a bug, write a test. Lock in the behavior until the requirements change.
    - postalrat 5y ago
      Sounds good. Find a bug, write a test. Never find a bug, never write a test.
eplanit 5y ago
I can't upvote this article enough times -- it's concise yet rich with astute observations. Just one example: "Thirty Years Ago...Insulating developers from interruptions was management’s Prime Directive." From my own experience, when I started at IBM in the mid 1980s, we had private offices just for this very reason. Me and my colleagues also recognized, though, that we were on the tail-end of those good ol' days. By the early 1990s "bullpens" were becoming the rage, and the rest is history. Another, "QA was other people": it was other people, and not the can't-make-it, under-performers, either. Testing was a discipline in and of itself, with very experienced testers. They were often older programmers in their last 5-10 years which knew what kinds of corners and edges to think of. That, too, was a just a fond memory by the early '90s.
- jonstewart 5y ago
  I’m 43 and I’m a dev manager. I try as hard as possible to insulate my developers from interruptions and pointless meetings. We have a dev team meeting every two weeks, and each dev maybe has 1-2 other meetings in those two weeks to discuss software with end-users; very much focused on the software. That’s it. But we also pair-program — when it makes sense — and we practice TDD. Perhaps the author has not observed good TDD. I find TDD enormously helpful; TDD helps me get into flow, and maintain it. I think there’s as much wrong with this article as there is right, and can’t really recommend it.
  - zzbzq 5y ago
    I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.
    - philwelch 5y ago
      What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.
ddek 5y ago
I have a few questions for people who largely agree with this article. Firstly, where do you stand on developers having input into the design process? From my experience, developer input in specification has led to better fitting solutions. Personally, I wouldn't like to be in a situation where I am instructed what to do, that sounds extremely tedious. If you agree that developers should have some contribution to the design process, then two points in this post are in conflict. Either the developer must be interrupted to participate in synchronous design decisions, or participate asynchronously on a much-maligned platform like Jira (better alternatives available). Is there another way?
- nofunsir 5y ago
  Design and documentation before implementation. Elevate “developers” to “Engineers” and treat the situation like building a bridge or a tunnel or an aircraft. Of course there will be some small changes along the way, but that doesn’t mean we should hold twice daily ceremonial meetings.
- deleted 5y ago
  [deleted]
- mikewarot 5y ago
  You can't be having requirements change while you're writing code... those happen in phases, those phases can be years, months or even weeks, but should never be less than that. Coding on quicksand will never work out. I was the programming/tech half of a small company back in the MS-DOS days. The first cycle was 3 months (delivery of program/hardware as specified). When it turned out to meet specifications, but was impractical in real use, we agreed to make changes. The prototype took about a month, and the customer liked it. We then switched to a really interesting form of agile. Every day I drove out to the Will County Generating station. The customer (Russ) would bring in a random generating plant employee, and tell him "Here's a computer, I want you to do X,Y and Z... I know this isn't your job, and you won't be judged if there are problems... This is Mike... anything that goes wrong is HIS fault" Russ was an amazing teacher, in the end. The first thing I learned is that "Press F1 for Help" should always be visible on the screen. We quickly settled into a pattern. We'd build a list of bugs/design changes, and I'd fix all the problems in our list, and then we'd test again... after a year it was judged suitable for wide distribution. I loved that job, I supported that program for about 5 years, driving all over the place, meeting interesting people and solving their problems.
pcmoney 5y ago
I think we would all want our own offices and some peace and quiet. Also the Agile industrial complex is a bunch of charlatans. Real agile is a good set of guidelines. Aside from that this article seems off the mark and self contradictory. 1. How would a change be up in an hour if it required QA? 2. How is code review important but pair programming bad? 3. How is designing systems to be testable easily a bad idea? (I understand TDD is more than just this but it also implies this) 4. How does he reconcile his thesis with the explosion of Billion and Trillion dollar companies who embrace the practices he opposes. Clearly it can work. 5. Many of his practices are great for a Sr dev. But how do you level up Jrs? 6. The knock on Googling and SO seems off. Sorry for using some of the best tech ever made for dev productivity? Sorry we don’t solder our own chips? Sorry Googles top engineers built that mostly through pair programming? (Jeff and Sanjay). 7. Must be nice to just rage quit at the slightest annoyance. I am sure he is real nice to work with and discuss architecture with too. Also explains his disdain for the social aspect.
- jonstewart 5y ago
  I don’t think anyone who’s ever programmed with Ward Cunningham would call him a charlatan.
  - pcmoney 5y ago
    I mean all the people trying to sell you methodologies and scrum masters and all that huey. The manifesto is just guidelines and tradeoff preferences. Its nothing special, its nothing new, its just concise and unfortunately marketable.
  - corpMaverick 5y ago
    I don't think the parent comment is talking about Ward or any of the original signers of the Agile Manifest. I think it is talking about all the consultants that sell services that do not understand the original principles.
    - mcguire 5y ago
      Are there original signers of the Agile Manifest who aren't consultants?
ram_rar 5y ago
>Older developers miss being able to focus; younger ones think focus is antisocial I wonder how many devs can code for more than a hr without being connected to the internet. I had the pleasure to talk to some industry veterans who have been coding for more than 4 decades. It amazes me to see how they could code without constantly "needing" to be connected online and actually build stuff just by reading through reference docs and man pages. Atleast in my line or work (web dev), lately software dev has become more of team sport where one constantly glues things together and searches online in stackoverflow, github etc to look for answers or raise bugs with downstream projects. Dev itself seems to have become more Operations ish.
- jnovek 5y ago
  We trend towards using many small open-source libraries which are essentially undocumented these days. The average case seems to be a README with a few examples rather than a clear API specification. Digging through Stack Overflow is essentially looking for someone who has already reverse engineered the exposed API in a library so you don’t have to. If projects were documented — like, actually documented, not just a cursory README — we would all be able to program without the internet. Honestly, it’s much easier than the way things are now.
zwieback 5y ago
I wrote SW back then and cannot confirm what he's saying, must be his personal experience. Some good points if you don't take him literally. Also, what the article doesn't take into account is that the hardware, SW tooling (and its cost) and, most importantly, SW distribution methods have changed radically. Lack of uninterrupted focus is the only really valid point, in my opinion.
- GeorgeTirebiter 5y ago
  I wrote SW back then and confirm everything he's saying, except never had fully enclosed office, but did have carpet-on-the-floor and high-wall cubicle. And, even then, if I really had to get into flow, I left the office for a couple of days.
  - zwieback 5y ago
    Just out of curiosity - could you work from home pre-fast internet/laptops/remote desktop? That was a struggle for me, especially when debugging things that required several PCs.
    - u801e 5y ago
      I want working professionally yet, but as a student studying computer science at an undergraduate level, I did many projects at home while connected over a SSH session. Windows remote desktop was mostly usable at those speeds though with some lag (but that could be d somewhat overcome using keyboard shortcuts instead of the mouse). I imagine working from home could be done in that setting.
whiitehead 5y ago
I recognize that this comment does not add value to the discussion around the (pretty good) article but please watch your pronouns. Especially when writing fairly accessible articles like this one.
metalforever 5y ago
This article has explained coherently and concisely everything I have been feeling.
deleted 5y ago
[deleted]
justicezyx 5y ago
I cannot endorse this article, full of personal experience that were never true in Amazon or Google. Particularly it's the testing done by other people and the unit testing. Testing people are certainly needed in many cases, but the article gave no reason why it has to be done by other people. Just because devs spent a lot of time working with tester, and they enjoy that time, does not make that way of testing the better choice. I worked with tester in Google, absolutely the most unproductive organization inside Google. All normal places have conducted their own testing before releasing to customers, internally most (had no experience working on consumer products). Edit: > Sounds like you had a bad tester. Opposite of my experience. A good tester is a gift from the Heavens. This sounds like just a statement without backup.
- GeorgeTirebiter 5y ago
  He did give a reason why testing has to be done by other people -- which was: if you, the coder, didn't catch the bug, how could you, the test-writer, catch it? Sounds like you had a bad tester. Opposite of my experience. A good tester is a gift from the Heavens.
- GeorgeTirebiter 5y ago
  I 1. showed you the OP gave a reason for wanting to use testers and 2. Gave you my experience with having had testers. What else would you like?
wiskinator 5y ago
Poor baby gen X coder. He can't adapt to the modern world. He still thinks it's OK to use "He" pronouns to refer to a generic developer. He thinks having to provide tests for his code is hard work. "QA was other people". What an egocentric trash view.
- postalrat 5y ago
  He still thinks it's OK to use "He" pronouns You made your own assumption when you said "He still ..."
allenu 5y ago
As someone who's been working in the industry about 20 years now, I agree with some of the points. I don't agree with the attitude toward testing. I worked at Microsoft for about 12 years and when I joined I was an SDET (sort of a dev who does testing). I honestly found it strange that there was a separate role to test code that was written. It just seemed so wasteful. There were strict "QA testers" as well, but they worked with the finished product as opposed to writing code that tested other code. When I finally switched to the dev role at the company, I would routinely see other devs writing code and throwing it over the fence to be tested. Testers would find an issue and then throw it back. Many of these bugs were such obvious things that could go wrong to me that it was clear the developer didn't take 5 minutes to try scenarios other than the happy path. I do think you can go too far with TDD and unit tests and that often they are more trouble than they're worth to set up and do prevent you from moving more quickly. Often, you don't know your problem space well enough to start planning your tests. However, it's a very old school attitude to think that you can just rely on QA to do testing for you. It may have worked in the past, but only products took longer to release and there was a smaller audience for what you did.
- GeorgeTirebiter 5y ago
  I revered my testers in those days. When they found a problem, I had to ask myself: "How did I miss this?". I'd identify how that happened, and made a note as to how to eliminate that class of error in the future. It is a mistake, I claim, to not have professional FW/SW testers anymore. I fail to see how having a parallel set of professional testers adds delay to product release -- except insofar that the testers find bugs that end users will subsequently never see - and that's the point!
  - scotty79 5y ago
    Me too. That was pretty much the only condition when I was looking for a job. Who does the testing? If the answer was "developer", or "everyone" I knew that they don't have a person who's responsibility is testing and that was very bad sign because I knew second pair of eyes responsible for looking at your output is worth their weight in gold. Being a great tester requires very different set of skills than being great developer.
corpMaverick 5y ago
As a practicing software engineer for more than 30 years. My pet peeves are in the opposite direction. We lost some of the XP wisdom. - Teams do CI/CD but most teams don't do Continuous Integration (sync and merge daily or more). And they hardly understand why CI is important since that is how they have work for ever. - "Do The Simplest Thing That Could Possibly Work" has been forgotten. People add a lot of complexity that is not really adding a lot of value (See YAGNI) - Agile were supposed to re-capture the power and give it to the developers. That didn't happen. There is a lot of emphasis on the process but little on the principles.
gilbetron 5y ago
This is an awful article that does not articulate the vast majority of past software development. I'm largely of the same era as the author, becoming a paid software developer (as a teenager) in 1986. The vast majority of software development was bloated and slow and largely horrible. The waterfall method ruled the world, and projects struggled to complete even though they weren't anywhere near the complexity of today's projects. Responding to some of the points from the article: * Insulating developers from interruptions was management’s Prime Directive. Not even remotely, that concept didn't exist until the 2000s. The managers job was to micromanage those under them and people had to create ridiculous estimates and then put in crunch time to try to meet them. Management processes were based on managing manual labor. It was, in all ways, a horrible era. * Projects were planned and designed. We had documents we were expected to read. Sure, there were all kinds of docs that were incorrect, poorly thought out, and just plain wrong. * Code is illegible. The "golden days" were not golden. Code is far more legible now. "it was hard to write, it should be hard to read" was the predominant mantra of the 90s. Code these days is generally reasonably legible and clean. The only aspects about the article that do ring true are some of the comments about testing - we did do testing and QA is great at least for complex domains. This article is about 90% old man yells at cloud, and this coming from an old man ;)
- commandlinefan 5y ago
  > I'm largely of the same era as the author Well, were you also from Microsoft? He seems to be talking about the way Microsoft did things "back in the day" - and it's hard to argue that they weren't very successful at it back then.
  - thinkharderdev 5y ago
    Very successful at producing and selling software for sure. I wouldn't really hold up mid-to-lat 90s MS products as the pinnacle of reliable, well-designed software though.
    - postalrat 5y ago
      You can't compare crud web apps with a large operating system that was on the cutting edge for the day.
plandis 5y ago
I don't buy the authors testing argument for a couple of reasons: 1. Verification is automated - From my perspective, tests predominantly serve to document AND verify the behavior of code. You don't have to follow TDD to buy into the idea that tests serve to verify behavior of the code that was written. Some applies to formal verification of software. 2. Documentation stays in sync with tests - I'd imagine that any snippet of code is read 2-10x more than it ever changes and tests help with that reading process. Writing tests means you're optimizing for the thing that happens most often AND you are somewhat guaranteed that your testing "documentation" stays up-to-date because as software evolves the tests will need to evolve as well there is an immediate penalty for not updating the tests; there is no corresponding immediate penalty for forgetting to update a specification document. The older a piece of software is the harder it will become to understand: the original developers stop working on it, the documentation becomes stale, context and initial reasoning for certain decisions is lost. In such an environment it's, in my experience, generally easier to make changes to old code bases with lots of testing because generally tests will tell you if there is something you don't understand with nearly instantaneous feedback: write some code, run the tests and it either works or it doesn't. Similarly, I don't get the authors argument that code is more illegible than it has been in the past. More modern languages make this as easy as possible to get correct. Take something like Flask [1] written in Python and generally considered to be well-written and compare that to the C code in SQLite [2] which is generally considered to be well-written C and tell me which is easier to understand without any prior knowledge. [1] https://github.com/pallets/flask https://github.com/pallets/flask [2] https://github.com/sqlite/sqlite https://github.com/sqlite/sqlite
analog31 5y ago
Granted, I work on the hardware side of things, at an architect level, and my only programming work is supporting my own short term needs. On hardware projects, "we develop it, you test it" is a huge problem, because testing invariably becomes a bottleneck, and is deferred until dangerously late in the development process. Tested subsystems are substantially more valuable than untested ones. In my own IC work, related to my specific area of domain knowledge, I do not submit untested designs. Everything I design comes with a test process, which usually involves code that I write myself. My designs rarely come back to me. For this reason, I support TDD in principle, though I haven't learned enough about it to be great at it. "Don't interrupt the programmers" is a problem because they end up becoming isolated from the rest of the team, and have to work twice as hard to catch up when the hardware design gets thrown over the wall for them to deal with. The people who can handle interruptions become by default the ones who participate in the critical technical decisions.
josephferano 5y ago
I was very surprised when I read the part about pair programming. Am I the only one who finds pair programming to be highly productive? I find that when someone is sitting next to me or watching me screen-cast and I'm explaining out-loud my thought process, my ability to focus and zone in goes through the roof. A human rubber ducky, if you want. I will grant the possibility that I have bad habits when it comes to work and I get easily distracted when I'm programming by myself. Having someone there effectively mitigates this and the lifestyle choices that negatively impact my ability to focus for long periods of times. So perhaps there's an untapped flow state that is even better than pair programming. While I figure this out for myself, I still can't deny the fact that the last few times I've truly been in the zone have been with someone looking at/hearing me code.
- patrick451 5y ago
  Not at all. My productivity drops below zero in these situations.
asciimov 5y ago
> I found it to be ghastly, sitting closer to a coworker I detested than I lay next to my own spouse in bed. I could smell him. The only thing worse than working in an open office environment is having to sit next to someone who stopped showering and regularly smokes. Smokers/Alcoholics/drug users/the unwashed are the worst, followed closely by people that wear heavy musky scents.
jdlshore 5y ago
This is a polemic against Extreme Programming that could have been written 15 years ago (and been just as wrong-headed then). And was. Many times.
- EVa5I7bHFq9mnYK 5y ago
  I think they took the idea of Extreme Programming from correctional institutions. When you are tied to another prisoner by a chain, it's much harder to escape (or to go on facebook, in a software institution).
cotelletta 5y ago
The real generational divide is people who feel this post in their bones and people who will nitpick at it because it's not in fact an unbiased survey. The point about focus is very true. The socialization of development via online tools means people think sticking their nose in other people's code is a virtue instead of a bother. If you're not going to contribute, why are you interrupting me?

156 points by daverol 5y ago

This essay is rooted in nostalgia and reads as a post facto justification for "I like the old way better". "I've never done waterfall" or "we specified everything (on paper! millennials don't read amirite) before we built it", which is it? There's a whole lot of generalizing from personal experience to "universal truths" that simply aren't universal. or even truths? For instance, there are certainly some teams that get value out of code reviews.

leethomas 5y ago
I agree that the article generalizes, basically to the point of condescension. Were you “there” though? I wasn’t so genuinely curious if his recollection reflects reality. EDIT: they responded to another parent comment I created and were definitely working at Microsoft during the period.
- kennytilton 5y ago
  Started programming in 1981. His recollection is correct. We were agile. Today's "Agile" is a disaster. We are not being condescending, we are mourning what once was an uninterrupted delight.
Miiko 5y ago
> "I've never done waterfall" Yes, that's correct, I've never done waterfall either. By definition [1] "The waterfall model has, at least, five to seven phases that follow in strict linear order, where a phase can’t begin until the previous phase has been completed." (emphasis mine) - we never did that, and I never heard of anybody following that model. All these steps has to overlap - it is not possible to write good requirements without having at least draft design etc - and they surely did. [1] https://www.projectmanager.com/waterfall-methodology https://www.projectmanager.com/waterfall-methodology
metalforever 5y ago
Okay, let me explain this. The way it's actually done is in-between. You can't really seriously agile your way into a great distributed architecture without some sort of planning process. You create a very high level document explaining the main components of the program. You make a second one with details (in a waterfall way) explaining everything you are going to be concentrating on in depth for the next 1-2 months. The rest is kept very high level. Then you can just change course if the reception of the 1-2 month work isn't ideal or the company needs to change direction.

leethomas 5y ago

Could someone of the appropriate age group with experience please confirm for me if everything this guy is saying was true generally speaking? I’m honestly curious as I’m too young to know myself and I have no way of knowing whether the article was written with rose tinted glasses on. But wow if it’s accurate the point about meetings and concentration sounds amazing, would love to go back to that.

sblom 5y ago
My experience at Microsoft in the late 90s and early 00s jives with his descriptions, mostly. But the essay went out of its way to be cynical and reductive. He's not making things up, but I don't think his takeaways are worth, well, taking any further.
- leethomas 5y ago
  So culturally which style of working do you prefer yourself? Or if it’s not binary, are there parts of how software was written yesterday that you’d like to bring into organizations today, whether mentioned in the article or not?
  - sblom 5y ago
    There's room for both extreme concentration and extreme communication, and most teams need some of each. I actually snorted at the essay's idea that communication and concentration can't mix. I'm not sure what he thinks email and detailed specs are if not communication. I think the key is that they're batch-mode communication. I can see value in several hours a day of concentration unbroken by communication, but insisting on a full week straight of unbroken concentration is impractical and possibly counterproductive.
    - France_is_bacon 5y ago
      It's not that there was NO communication. He said that he'd go to QA and fix anything that they found. It's just that it was more informal, and you did it when it was time to do it, but not just meetings every day that are required, even when there's nothing really to say, or what couldn't be done in a 15 second or one minute conversation. And you could do it on your own time, so you didn't have to stop right in the middle of some super productive time when you're on a roll. Because that's how it works - some coding time is more productive than other time. You're just into it and everything is just flowing, as he said.

davesmylie 5y ago

Back in my day, we'd write our webpages such that they would load on mobile with requiring the user to enable javascript... And we liked it that way!

discordance 5y ago

Testing is important, regardless of the era you develop software in. Focus is also important, even these days. This guy worked at Microsoft in 90's - 00's, and claims that it's the lack of concentration these days that leads to buggy code. I've used a lot of MS stuff in the last 30 years and there were many bugs and instabilities. One of the most brilliant things I use these days is our CI/CD pipelines, which has enabled many individuals to collaborate, and deploy (mostly) reliable code to production frequently, daily if not hourly. Tests are critical in enabling this. Perhaps the poster's views make more sense for waterfall-ish, once every 6 monthly or yearly releases.

username90 5y ago
In the early 90s you had a few megabytes of ram, running out of ram was a normal thing so your programs had to handle it everywhere. That makes the kind of testing we do on modern computers useless, our tests only works if we don't have ram issues or other parts of the system fails. The fact that programs back then still worked quite reliably is a miracle. And then you look at today when hardware is super reliable, people have forgotten that running out of ram can lead to bugs etc, yet we still have plenty of strange bugs in software that never should have had any bugs in the first place. If people today learned systems and wrote things with the same care they did back then you wouldn't have all of those bugs. But instead shipping bugs is fine etc, we took all the advancements and used it to push features faster rather than make things reliable.
lambdasquirrel 5y ago
Yeah, I agreed with the article except on testing / QA. I was skeptical of these at first too, but in retrospect, it was not okay to externalize the cost of testing onto other people. In those companies I've worked where we released in some waterfall-ish manner and/or QA was important, we have both.

ckolkey 5y ago

It strikes me as odd that in one breath he says "Learning was part of the job" and spends nearly the rest of the piece complaining about writing tests. Maybe he could learn how to do it better :)

postalrat 5y ago
Would you say the same thing about writing all the documentation? Or writing all the marketing?

irrational 5y ago

I work for a Fortune 500 company. Through a strange set of circumstances I ended up as a developer embedded in a business unit for 18 years. It was very much like the “then” described in the article. No ceremonial meetings, no sprints, given offices with doors, etc. Then the company decided to consolidate all tech people. For the past 2 years I’ve had an IT manager. I am absolutely astounded how much time is wasted in the modern IT world. Ceremonial meetings, recurring meetings, sprints, etc. I’d say I’m 10% as effective as before. I seriously have weeks were I spend a single hour writing code. And the IT managers are perfectly okay with this! It blows my mind how utterly inefficient they have managed to make coding and the results are definitely not any better. Oh, and the QA thing. Anyone that thinks test driven development can replace a dedicated QA person, clearly has no business working in the world of software development. But, I’ve found that I can’t actually say any of this out loud at work. The IT managers are so brainwashed that they can’t see the reality of what is going on. I’m convinced all of this is for the purpose of giving IT managers something to do to justify their existence.

sam_lowry_ 5y ago
I am seeing this shift between then and now as natural growth of bullshit jobs.
vidanay 5y ago
20 years at a division of a F500 company here. Luckily, we have not been sidelined into the ceremony and incantations of "modern" software development. Our most formalized process is a very strong PLM (Product Lifecycle Management) workflow.
France_is_bacon 5y ago
As I wrote elsewhere, it all depends on the size of the department, and the manager. If you work where there's 3-15 in the tech department, either a small unit of a large company, or just a small or medium-sized company, you have more autonomy and authority. But if you are one of 200 programmers, then no. That was true back then as I'm sure it is now. In the same respects, if you have a sh-t manager back then, big company or small, it is the same thing. Micromanaging, time-wasting, with a sh-tty boss. Or you could have a great manager back then or now, who keeps general tabs on things, and only starts getting to become a micromanager if the person under them starts f-cking up, which as it should be. But let's say you work at a large plumbing company with 200 plumbers, and you have a tech department of 7 people and an admin staff of 25. The CEO is a plumber and what does he know about tech, the COO is working on coordinating trucks and insurance and personnel and all kinds of other things, and the CFO has his hands busy just keeping up with accounting. Nobody is going to mess with you, as long as YOU don't mess up. They don't even know how to help you, and they are too busy with their own sh-t. Except in the biggest picture view, of course. Then, all you have to hope for is that the manager is good. Usually they are, because they are busy. But I've worked at Fortune 500 companies in local offices or regions where I was the only person doing what I was doing, and absolutely no one bothered me, because I was there by myself. Sure, I talked to a lot of people in the company to see what they needed to have done, but after that, my time was my own. I can't imagine it would be any different now, in the same circumstances.

js8 5y ago

When I started as SWE, I was (more or less by accident) educated in the old way. And I, like the OP, don't like the new way. I think the article is spot on in the factual, although of course it is biased in preference and author makes that clear. (And it pains me that people in the discussion are not really hearing the nuance, just like youngsters often don't listen to the older generation.) I have a brilliant coworker, who enjoys the new way, and we disagree a lot, and I think the article summarizes our disagreement very well. Ultimately, I think the divide comes down to your optimization horizon. In the old days, software was made to last longer, and there was more time to plan and design it properly, because the horizon was longer. Today, the horizon has been shortened, and more experimentation is done, and less forward thinking. And so the methods are different, and most of these differences (as described in the article) accounts to the shortening of the optimization horizon. I do prefer longer horizon, because I feel that if you have series of short horizons, you're not optimizing as well as you could, and spend too much time rebuilding stuff in an incoherent architecture. But the business seems to prefer the short horizon, for various reasons (one might be simply competition, the red queen effect of sorts). I think from an engineering perspective, this is a mistake (there is a reason why we don't build houses in "agile" way), but I came to recognize that neither side is actually "right". But I am going to appeal, if you are trying to build software that lasts, think about your time horizon, maybe you will find that you can actually use the past approach better, if your horizon is longer.

MeinBlutIstBlau 5y ago
I like the new way because it's very easy to get through the day without working and pretending you work. I like the old way because it makes coding expectations more realistic and enjoyable.
commandlinefan 5y ago
> don't like the new way I think that's the wrong way of looking at it (or phrasing it). I'm sure people that pick vegetables all day don't like the heat, or the dirt, or the bugs, or the fact that vegetables grow so low to the ground, but those things are immutable reality that can't be changed, so they have to adjust to them. Nothing about modern "Agile" software development is immutable so the better question is "does this produce better software?" It should be abundantly clear at this point that it does not - that although there were deficiencies in the software of the 20th century, those deficiencies pale in comparison to those of the modern day, in spite of the fact that our computers are orders of magnitude better. It doesn't matter whether we like the way things are done, what matters is that it's exponentially inferior.

hdjjhhvvhga 5y ago

As any rant it needs to be taken with a grain of salt. This one, however, is very true: > I and everyone I have ever talked to about testing has had the same experience; we write a new feature, test the hell out of it, can’t find anything wrong; ask a coworker to take a crack at it, and he finds a major bug in under a minute. The password is blind spots, and we all have them. And if we didn’t think of some case in development, we are not going to think of it in testing. That’s why we had separate QA departments. I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs, but it's only a a part of the equation. But it's not like all companies removed their QA departments either - many pieces of software are regularly tested by independent teams with good results. If someone thinks TTD will eliminate all bugs, well, they're not thinking clearly.

js8 5y ago
> I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs I am skeptical of TDD, so I have a genuine question. Let's say TDD is able to find the "most obvious" bugs, like a typo. My question is, why are these bugs worth creating a test for them, compared to either manual testing (running the program and looking at the output) or running a portion of the integrated test suite on the code to find them? If the bug is simple and crippling, then the program is likely to fail anyway. To me there is a tradeoff. With TDD, you write some unit test code, and it finds a trivial bug. But is every trivial bug found worth maintaining the unit test code going forward? I mean it's not like this bug is gonna appear again all of sudden in your code, unless you change it, but then in all likelihood you need to change your unit test as well. I guess I don't really see TDD as a good tool, because all the situations that you can run into are already covered by other, more specialized tools. If you want to catch edge cases, asserts are IMHO superior tool to tests. If you want to verify your program quickly, running it manually and looking at the output is superior. If you want to verify your program properly, running a comprehensive (and integrated) test suite is superior (the best if you can make it property-based). There are situations where unit tests are genuinely useful, like writing a library. But in those cases, unit tests seem to always either compare with some other implementation (for example, if I am testing a sin(x) function, my other implementation is the calculator), or at least compare with well-defined specification that comes outside the code. But I feel like majority of tests written for TDD are not really testing the code against anything (simply because another implementation or specification is not available), they just test the intent of the code itself as is written, which might be useful if you wanted to write "bar" but wrote "baz" by accident, but other than this type of bugs, what is their long-term contribution, that could justify the maintenance cost?

BoredomHeights 5y ago

A lot of things in the article I think most younger software engineers would agree with (I'm mid 30s for context, so around where he seemingly put the divide, definitely not an OG). Almost everyone I've ever met wants less meetings and more time to focus/code. I understand if this may be something that has changed over time but I definitely don't think it's something younger engineers want, even if they do have to deal with it. If anything I think they'd relate most since they've always had to get their work done with less time to actually focus. I also hate the idea of daily check ins/standups and don't like two week sprints, but we don't do either of those and I haven't at previous companies. Other things mentioned I just don't think are actually true about modern software development, although possibly it depends on your company. I've worked mostly in FAANG companies and we absolutely spend a ton of time on design. And I think this is where collaboration, team cohesion, etc. is so important. The design phase is where you need that communication, then you ideally separate and focus on your own work solo. Then maybe get some review etc. (though like he mentioned, I agree code reviews themselves are relatively pointless, I haven't done one since working at a smaller company). But during the design and somewhat ongoing it can be extremely helpful to know what partner teams and engineers are working on (though daily updates absolutely are not needed). My biggest takeaway from the article is that he really, really, hates writing unit tests. I see pros and cons for both approaches honestly. As a software developer I would love someone else (dedicated QA) to handle a lot of this for me. I don't know if that's necessarily actually better from a company perspective though (not saying it's not either). It definitely makes scaling tougher for very large companies. Who's QA on a 3 person team (or "group") for example, does every team need dedicated QA? When is it worth having? Obviously that's something that can potentially be solved, but it's not necessarily easier or worth it. My experience though is that at best it's extremely exaggerated to state that unit tests are the main focus these days. In total I maybe spend two weeks a year writing tests, if that. As for documentation and learning on the job my experience also doesn't stack up, and this is maybe the part I feel like the article comes closest to "old man yells at cloud". You are absolutely expected to constantly be learning and improving on the job and you better have read all relevant documentation. The first thing that happens on any team I join is I'm given pages and pages of documentation to go through. I spend most of my early time on teams literally studying it and taking notes. I think a lot of the "back in my day" quotes in regards to these topics are some of the most out of touch in this article. "We didn't have stack overflow so we had to..." So what? Stack Overflow exists now, people adjust. It can also be a learning tool in and of itself. Overall I think some of the major points may be true (though as mentioned I don't necessarily think younger engineers would actually disagree with those points). I've never worked at Microsoft specifically so can't say what it's like there, maybe a lot of this is more accurate. I don't think I read very much that I think actually shows a divide between software developers of each generation though, other than speculation that younger developers can't concentrate.

MrDresden 5y ago

I would be in the younger category, as I've only been in the industry for little over a decade. I do though fully agree with many of the points in the article, and desperately wished we could actually change the corporate culture around SW development. However I've come to the conclusion, after years of trying, that it simply can't be done. At least not in companies that have reached a certain size. The 'agile' managerial mantra, along with all of the other bad practices that usually accompany it at cargo cult workplaces (managers that constantly work on 'optimizing' procedures and creating 'effective' teams, too many too long meetings, excessive documentation, lack of space to think and ponder, lack of private silent spaces, etc), is simply too entranched in the manager layer and company culture at these places to ever change. The only times I've had the option of silent uninterupted deep work (i.e flow) has been when working at startups that were started and run by other SWD's who knew what worked and what doesn't. And regarding this point: "Instead of distributing projects between “teams” (sorry, that word makes me think of sports, we were “groups” back then)..." I believe this is done exactly to make it feel we are like a sports team competing with other teams for a price. It makes it much easier to sell layoffs to the rest of the team when they happen ("we had to let Steffany go, she just wasn't an 'effective' 'team' player") Edit: I will add that there are many good points in the agile manifesto that I belive would make sense if done correctly. The market place of 'agile' consultance has simply twisted it into a unrecognizable mess and so the corporate culture trying to implement it falls horribly short (and in the wrong direction) of doing so correctly

loopz 5y ago

Building software for the one developer vs building software for the company and customers (company first because they will support the customers). What went wrong with agility is that it turned into Agile, a concept sold by consultants to be co-opted by management. We should absolutely stop coining the phrase "team" though. Everything about it and the rituals are only for enforcing control and disrupting creative work. The "sports" metaphors are only avenues of manipulation and abuse. Sadly it works best on the youngest generation. The old way where a few devs could hold entire companies hostage is over forever though. Nothing wrong with pairing and teaching others. But it is work, work both the new way and the old way is very adverse to do.

dave333 5y ago

It's ironic that my first paid job at Racal in the UK working on computer aided design software in assembler running on shared fridge sized minicomputers with 64K RAM got many SW development truisms right. Desks all in one large room with collaborators (we didn't know this word yet) next to each other for easy questions/conversation when needed. Room was quiet at all times so no problem getting into the flow. Tea break mid morning and afternoon when the tea lady wheeled a cart round with a big tea URN (sweet and slightly milky no options) and various candy/sweets cookies/biscuits or chips/crisps. We would all get up from our desks and line up near the URN and chat/collaborate similarly to how people do at water coolers I understand. Lunch in the company cafeteria or out at a local pub if there was some event. More collaboration. After lunch we usually all (most of us) played the board game Diplomacy at one move per day. This is the perfect team building tool. What could be a better way to get to know each other than by building alliances to go to war with your comrades and/or stabbing them in the back? No external frameworks - most of the senior folks would create a few common functions or have some from previous projects that could be shared. It was all downhill from there.

selfhoster11 5y ago
That sounds like an entirely different experience from today.
- dave333 5y ago
  Yes - my point is that that first job got most things right about how to organize sw development despite the primitive state of hardware and software. So called methodologies have made things worse mostly.
  - selfhoster11 5y ago
    It's not just that, it's the human touch (or should I say, analogue touch) of this kind of development. The tea cart, the (presumably) not as hectic pace, and definitely no Slack window tearing into your psyche with each new notification.

neilv 5y ago

There's a lot of truth in this article, and (in the marketplace of ideas) it confronts a lot of recent popular thinking that's been maybe a bit too echo chamber-y. It's too bad it was posted on HN over the weekend (and looks like it might've fallen off the front page pretty quickly), but maybe it will get a second chance in HN primetime.

swyx 5y ago
Its 10am PT on Monday and on the front page, and the time stamp on the post is "5 hours ago" so not the weekend - you must have seen it during the weekend, yet your comment says "1 hour ago". So does the HN second chance pool also reset comment timestamps? interesting.
- neilv 5y ago
  I think divine intercession by `dang` gave it a second chance.
- thrower123 5y ago
  It's really bizarre sometimes when articles in the second-chance pool have a few comments on them when they get rolled forward. It almost makes me wonder if comment timestamps are stored relative to the parent post...

oneplane 5y ago

Devil's advocate: the difference between then and now is also in the visibility and metrics. If you have some black-box 'software coder' in an office that might pump out an artifact six times per year, do you really have any clue what is going on, what you are paying them for or how it stacks up against others, other tasks, other jobs, other features or other investments? And what if you need a feature now, and in a few weeks you need a different feature? What if there is a customer demand that changes, do you just continue building the 'old' request that is now worthless on delivery?

nostrademons 5y ago

I'd say that the really huge generational divide is the supply-chainification of software development. I'm just barely old enough to remember the days when a software engineer was responsible for everything between the hardware and the UX. You wrote code that implemented algorithms and data structures; and made choices between what would be computed in CPU, stored in RAM, or paged to disk; and worked on the whole program from the network or disk layer up to the UI. Now all of these are different roles. You have backend engineers and data engineers and data scientists and front-end engineers (who only deal with modern Javascript and its dozens of frameworks - even 10 years ago a front-end engineer was expected to know how a webserver and HTTP worked) and mobile engineers and AWS experts and Docker/Kubernetes experts to orchestrate it all. If you're actually responsible for the whole program, that's an architect or tech lead role and you don't actually write a whole lot of code. The jobs of each of the people who do write code largely consists of gluing together existing industry-standard frameworks. Algorithms and data structures are stuff you solve on a whiteboard to get the job, and then you never use them once you have the job. It's the natural evolution of an industry, but it does make the job a lot less interesting. The observations the author makes are a natural outgrowth of this - when you have a lot of separate roles collaborating to build a program rather than a single person designing the whole thing, you need a lot more meetings and e-mails and testing.

rachelbythebay 5y ago
I suspect a lot of these extra steps are not contributing positively to the product. If two solid people could get the same result and there are two dozen people on something, where is all of that extra effort going? We don’t talk too much about this.
- thinkharderdev 5y ago
  If two people could get the same result then that would be strictly better, but I think the issue is that two people couldn't (or at least the two people you actually have instead of two hypothetical people who maybe were more capable). But output doesn't scale linearly with number of people involved due to various coordination/communication issues. So I think the root of the intuition we have that there is more "wasted" effort is just that people are building larger, more complex systems that need larger teams to build and the larger teams spend more effort (on a per-person basis) on coordination.

wldcordeiro 5y ago

The author of this post sure seems like a fun fellow. > If your profile includes pronoun pairs I will likely block you. If "they/them," I will definitely block you. https://twitter.com/ComposerDark https://twitter.com/ComposerDark

throwslackforce 5y ago
I don't see any connection to this twitter user from the article at all.
- delecti 5y ago
  The author's twitter is linked from their profile page on hackernoon.
- wldcordeiro 5y ago
  Look at the left hand sidebar of the article with the author info. There's a Facebook and Twitter icon.
  - throwslackforce 5y ago
    Thanks for clarifying. I don't think I've ever actually clicked one of those "social networking" icons so didn't realize that's where it was going. (I had grepped the text for the name instead).
- shadowoflight 5y ago
  There's a twitter icon underneath the author's name that links to that twitter profile...
wppick 5y ago
Ad hominem. We don't need to do a background check on every author of an article, we can just focus on and discuss the contents
- rbanffy 5y ago

thinkharderdev 5y ago

Obviously this post is hyperbolic to make a point and I think I agree with some of it. But one thing that I think is a straw man is saying that "Developers are their own testers" which I think is profoundly missing the point of modern software testing. It's not that you should just "test your own code" and toss it in production, it's that testing is part of the software development process and "developers" should be full participants in everything from designing/developing code to testing it. And that means, yes when you develop a new feature you also need to deliver automated tests for that feature and not just throw it over the wall to "QA" to test it.

the_arun 5y ago
I agree with you because it makes me accountable for what I am building and be empathetic with my customers as well. I also agree with the point about "Blind Spot" from the author. It is just another perspective. Software is used by multiple users and "it works for me" is not encouraged unless we are building for one user. So, we need to get feedback from others and improve to address more kinds of users.
scotty79 5y ago
Developers make a absolutely horrible testers. It requires completely different skillset. It's pure arrogance that developers can do anything, including testing. And automated tests only test things that developer thought about. If anything developer of given piece of code should be expressly forbidden from delivering automated test for his code and other developer should be tasked with this with guiding goal of making the test fail on the initial implementation from the first developer.
- xupybd 5y ago
  Automated tests are brilliant in maintenance mode. Find a bug, write a test. Lock in the behavior until the requirements change.
  - postalrat 5y ago
    Sounds good. Find a bug, write a test. Never find a bug, never write a test.

eplanit 5y ago

I can't upvote this article enough times -- it's concise yet rich with astute observations. Just one example: "Thirty Years Ago...Insulating developers from interruptions was management’s Prime Directive." From my own experience, when I started at IBM in the mid 1980s, we had private offices just for this very reason. Me and my colleagues also recognized, though, that we were on the tail-end of those good ol' days. By the early 1990s "bullpens" were becoming the rage, and the rest is history. Another, "QA was other people": it was other people, and not the can't-make-it, under-performers, either. Testing was a discipline in and of itself, with very experienced testers. They were often older programmers in their last 5-10 years which knew what kinds of corners and edges to think of. That, too, was a just a fond memory by the early '90s.

jonstewart 5y ago
I’m 43 and I’m a dev manager. I try as hard as possible to insulate my developers from interruptions and pointless meetings. We have a dev team meeting every two weeks, and each dev maybe has 1-2 other meetings in those two weeks to discuss software with end-users; very much focused on the software. That’s it. But we also pair-program — when it makes sense — and we practice TDD. Perhaps the author has not observed good TDD. I find TDD enormously helpful; TDD helps me get into flow, and maintain it. I think there’s as much wrong with this article as there is right, and can’t really recommend it.
- zzbzq 5y ago
  I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.
  - philwelch 5y ago
    What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.

ddek 5y ago

I have a few questions for people who largely agree with this article. Firstly, where do you stand on developers having input into the design process? From my experience, developer input in specification has led to better fitting solutions. Personally, I wouldn't like to be in a situation where I am instructed what to do, that sounds extremely tedious. If you agree that developers should have some contribution to the design process, then two points in this post are in conflict. Either the developer must be interrupted to participate in synchronous design decisions, or participate asynchronously on a much-maligned platform like Jira (better alternatives available). Is there another way?

nofunsir 5y ago
Design and documentation before implementation. Elevate “developers” to “Engineers” and treat the situation like building a bridge or a tunnel or an aircraft. Of course there will be some small changes along the way, but that doesn’t mean we should hold twice daily ceremonial meetings.
deleted 5y ago
[deleted]
mikewarot 5y ago
You can't be having requirements change while you're writing code... those happen in phases, those phases can be years, months or even weeks, but should never be less than that. Coding on quicksand will never work out. I was the programming/tech half of a small company back in the MS-DOS days. The first cycle was 3 months (delivery of program/hardware as specified). When it turned out to meet specifications, but was impractical in real use, we agreed to make changes. The prototype took about a month, and the customer liked it. We then switched to a really interesting form of agile. Every day I drove out to the Will County Generating station. The customer (Russ) would bring in a random generating plant employee, and tell him "Here's a computer, I want you to do X,Y and Z... I know this isn't your job, and you won't be judged if there are problems... This is Mike... anything that goes wrong is HIS fault" Russ was an amazing teacher, in the end. The first thing I learned is that "Press F1 for Help" should always be visible on the screen. We quickly settled into a pattern. We'd build a list of bugs/design changes, and I'd fix all the problems in our list, and then we'd test again... after a year it was judged suitable for wide distribution. I loved that job, I supported that program for about 5 years, driving all over the place, meeting interesting people and solving their problems.

pcmoney 5y ago

I think we would all want our own offices and some peace and quiet. Also the Agile industrial complex is a bunch of charlatans. Real agile is a good set of guidelines. Aside from that this article seems off the mark and self contradictory. 1. How would a change be up in an hour if it required QA? 2. How is code review important but pair programming bad? 3. How is designing systems to be testable easily a bad idea? (I understand TDD is more than just this but it also implies this) 4. How does he reconcile his thesis with the explosion of Billion and Trillion dollar companies who embrace the practices he opposes. Clearly it can work. 5. Many of his practices are great for a Sr dev. But how do you level up Jrs? 6. The knock on Googling and SO seems off. Sorry for using some of the best tech ever made for dev productivity? Sorry we don’t solder our own chips? Sorry Googles top engineers built that mostly through pair programming? (Jeff and Sanjay). 7. Must be nice to just rage quit at the slightest annoyance. I am sure he is real nice to work with and discuss architecture with too. Also explains his disdain for the social aspect.

jonstewart 5y ago
I don’t think anyone who’s ever programmed with Ward Cunningham would call him a charlatan.
- pcmoney 5y ago
  I mean all the people trying to sell you methodologies and scrum masters and all that huey. The manifesto is just guidelines and tradeoff preferences. Its nothing special, its nothing new, its just concise and unfortunately marketable.
- corpMaverick 5y ago
  I don't think the parent comment is talking about Ward or any of the original signers of the Agile Manifest. I think it is talking about all the consultants that sell services that do not understand the original principles.
  - mcguire 5y ago
    Are there original signers of the Agile Manifest who aren't consultants?

ram_rar 5y ago

>Older developers miss being able to focus; younger ones think focus is antisocial I wonder how many devs can code for more than a hr without being connected to the internet. I had the pleasure to talk to some industry veterans who have been coding for more than 4 decades. It amazes me to see how they could code without constantly "needing" to be connected online and actually build stuff just by reading through reference docs and man pages. Atleast in my line or work (web dev), lately software dev has become more of team sport where one constantly glues things together and searches online in stackoverflow, github etc to look for answers or raise bugs with downstream projects. Dev itself seems to have become more Operations ish.

jnovek 5y ago
We trend towards using many small open-source libraries which are essentially undocumented these days. The average case seems to be a README with a few examples rather than a clear API specification. Digging through Stack Overflow is essentially looking for someone who has already reverse engineered the exposed API in a library so you don’t have to. If projects were documented — like, actually documented, not just a cursory README — we would all be able to program without the internet. Honestly, it’s much easier than the way things are now.

zwieback 5y ago

I wrote SW back then and cannot confirm what he's saying, must be his personal experience. Some good points if you don't take him literally. Also, what the article doesn't take into account is that the hardware, SW tooling (and its cost) and, most importantly, SW distribution methods have changed radically. Lack of uninterrupted focus is the only really valid point, in my opinion.

GeorgeTirebiter 5y ago
I wrote SW back then and confirm everything he's saying, except never had fully enclosed office, but did have carpet-on-the-floor and high-wall cubicle. And, even then, if I really had to get into flow, I left the office for a couple of days.
- zwieback 5y ago
  Just out of curiosity - could you work from home pre-fast internet/laptops/remote desktop? That was a struggle for me, especially when debugging things that required several PCs.
  - u801e 5y ago
    I want working professionally yet, but as a student studying computer science at an undergraduate level, I did many projects at home while connected over a SSH session. Windows remote desktop was mostly usable at those speeds though with some lag (but that could be d somewhat overcome using keyboard shortcuts instead of the mouse). I imagine working from home could be done in that setting.

whiitehead 5y ago

I recognize that this comment does not add value to the discussion around the (pretty good) article but please watch your pronouns. Especially when writing fairly accessible articles like this one.

metalforever 5y ago

This article has explained coherently and concisely everything I have been feeling.

deleted 5y ago

[deleted]

justicezyx 5y ago

I cannot endorse this article, full of personal experience that were never true in Amazon or Google. Particularly it's the testing done by other people and the unit testing. Testing people are certainly needed in many cases, but the article gave no reason why it has to be done by other people. Just because devs spent a lot of time working with tester, and they enjoy that time, does not make that way of testing the better choice. I worked with tester in Google, absolutely the most unproductive organization inside Google. All normal places have conducted their own testing before releasing to customers, internally most (had no experience working on consumer products). Edit: > Sounds like you had a bad tester. Opposite of my experience. A good tester is a gift from the Heavens. This sounds like just a statement without backup.

GeorgeTirebiter 5y ago
He did give a reason why testing has to be done by other people -- which was: if you, the coder, didn't catch the bug, how could you, the test-writer, catch it? Sounds like you had a bad tester. Opposite of my experience. A good tester is a gift from the Heavens.
GeorgeTirebiter 5y ago
I 1. showed you the OP gave a reason for wanting to use testers and 2. Gave you my experience with having had testers. What else would you like?

wiskinator 5y ago

Poor baby gen X coder. He can't adapt to the modern world. He still thinks it's OK to use "He" pronouns to refer to a generic developer. He thinks having to provide tests for his code is hard work. "QA was other people". What an egocentric trash view.

postalrat 5y ago
He still thinks it's OK to use "He" pronouns You made your own assumption when you said "He still ..."

allenu 5y ago

As someone who's been working in the industry about 20 years now, I agree with some of the points. I don't agree with the attitude toward testing. I worked at Microsoft for about 12 years and when I joined I was an SDET (sort of a dev who does testing). I honestly found it strange that there was a separate role to test code that was written. It just seemed so wasteful. There were strict "QA testers" as well, but they worked with the finished product as opposed to writing code that tested other code. When I finally switched to the dev role at the company, I would routinely see other devs writing code and throwing it over the fence to be tested. Testers would find an issue and then throw it back. Many of these bugs were such obvious things that could go wrong to me that it was clear the developer didn't take 5 minutes to try scenarios other than the happy path. I do think you can go too far with TDD and unit tests and that often they are more trouble than they're worth to set up and do prevent you from moving more quickly. Often, you don't know your problem space well enough to start planning your tests. However, it's a very old school attitude to think that you can just rely on QA to do testing for you. It may have worked in the past, but only products took longer to release and there was a smaller audience for what you did.

GeorgeTirebiter 5y ago
I revered my testers in those days. When they found a problem, I had to ask myself: "How did I miss this?". I'd identify how that happened, and made a note as to how to eliminate that class of error in the future. It is a mistake, I claim, to not have professional FW/SW testers anymore. I fail to see how having a parallel set of professional testers adds delay to product release -- except insofar that the testers find bugs that end users will subsequently never see - and that's the point!
- scotty79 5y ago
  Me too. That was pretty much the only condition when I was looking for a job. Who does the testing? If the answer was "developer", or "everyone" I knew that they don't have a person who's responsibility is testing and that was very bad sign because I knew second pair of eyes responsible for looking at your output is worth their weight in gold. Being a great tester requires very different set of skills than being great developer.

corpMaverick 5y ago

As a practicing software engineer for more than 30 years. My pet peeves are in the opposite direction. We lost some of the XP wisdom. - Teams do CI/CD but most teams don't do Continuous Integration (sync and merge daily or more). And they hardly understand why CI is important since that is how they have work for ever. - "Do The Simplest Thing That Could Possibly Work" has been forgotten. People add a lot of complexity that is not really adding a lot of value (See YAGNI) - Agile were supposed to re-capture the power and give it to the developers. That didn't happen. There is a lot of emphasis on the process but little on the principles.

gilbetron 5y ago

This is an awful article that does not articulate the vast majority of past software development. I'm largely of the same era as the author, becoming a paid software developer (as a teenager) in 1986. The vast majority of software development was bloated and slow and largely horrible. The waterfall method ruled the world, and projects struggled to complete even though they weren't anywhere near the complexity of today's projects. Responding to some of the points from the article: * Insulating developers from interruptions was management’s Prime Directive. Not even remotely, that concept didn't exist until the 2000s. The managers job was to micromanage those under them and people had to create ridiculous estimates and then put in crunch time to try to meet them. Management processes were based on managing manual labor. It was, in all ways, a horrible era. * Projects were planned and designed. We had documents we were expected to read. Sure, there were all kinds of docs that were incorrect, poorly thought out, and just plain wrong. * Code is illegible. The "golden days" were not golden. Code is far more legible now. "it was hard to write, it should be hard to read" was the predominant mantra of the 90s. Code these days is generally reasonably legible and clean. The only aspects about the article that do ring true are some of the comments about testing - we did do testing and QA is great at least for complex domains. This article is about 90% old man yells at cloud, and this coming from an old man ;)

commandlinefan 5y ago
> I'm largely of the same era as the author Well, were you also from Microsoft? He seems to be talking about the way Microsoft did things "back in the day" - and it's hard to argue that they weren't very successful at it back then.
- thinkharderdev 5y ago
  Very successful at producing and selling software for sure. I wouldn't really hold up mid-to-lat 90s MS products as the pinnacle of reliable, well-designed software though.
  - postalrat 5y ago
    You can't compare crud web apps with a large operating system that was on the cutting edge for the day.

plandis 5y ago

I don't buy the authors testing argument for a couple of reasons: 1. Verification is automated - From my perspective, tests predominantly serve to document AND verify the behavior of code. You don't have to follow TDD to buy into the idea that tests serve to verify behavior of the code that was written. Some applies to formal verification of software. 2. Documentation stays in sync with tests - I'd imagine that any snippet of code is read 2-10x more than it ever changes and tests help with that reading process. Writing tests means you're optimizing for the thing that happens most often AND you are somewhat guaranteed that your testing "documentation" stays up-to-date because as software evolves the tests will need to evolve as well there is an immediate penalty for not updating the tests; there is no corresponding immediate penalty for forgetting to update a specification document. The older a piece of software is the harder it will become to understand: the original developers stop working on it, the documentation becomes stale, context and initial reasoning for certain decisions is lost. In such an environment it's, in my experience, generally easier to make changes to old code bases with lots of testing because generally tests will tell you if there is something you don't understand with nearly instantaneous feedback: write some code, run the tests and it either works or it doesn't. Similarly, I don't get the authors argument that code is more illegible than it has been in the past. More modern languages make this as easy as possible to get correct. Take something like Flask [1] written in Python and generally considered to be well-written and compare that to the C code in SQLite [2] which is generally considered to be well-written C and tell me which is easier to understand without any prior knowledge. [1] https://github.com/pallets/flask https://github.com/pallets/flask [2] https://github.com/sqlite/sqlite https://github.com/sqlite/sqlite

analog31 5y ago

Granted, I work on the hardware side of things, at an architect level, and my only programming work is supporting my own short term needs. On hardware projects, "we develop it, you test it" is a huge problem, because testing invariably becomes a bottleneck, and is deferred until dangerously late in the development process. Tested subsystems are substantially more valuable than untested ones. In my own IC work, related to my specific area of domain knowledge, I do not submit untested designs. Everything I design comes with a test process, which usually involves code that I write myself. My designs rarely come back to me. For this reason, I support TDD in principle, though I haven't learned enough about it to be great at it. "Don't interrupt the programmers" is a problem because they end up becoming isolated from the rest of the team, and have to work twice as hard to catch up when the hardware design gets thrown over the wall for them to deal with. The people who can handle interruptions become by default the ones who participate in the critical technical decisions.

josephferano 5y ago

I was very surprised when I read the part about pair programming. Am I the only one who finds pair programming to be highly productive? I find that when someone is sitting next to me or watching me screen-cast and I'm explaining out-loud my thought process, my ability to focus and zone in goes through the roof. A human rubber ducky, if you want. I will grant the possibility that I have bad habits when it comes to work and I get easily distracted when I'm programming by myself. Having someone there effectively mitigates this and the lifestyle choices that negatively impact my ability to focus for long periods of times. So perhaps there's an untapped flow state that is even better than pair programming. While I figure this out for myself, I still can't deny the fact that the last few times I've truly been in the zone have been with someone looking at/hearing me code.

patrick451 5y ago
Not at all. My productivity drops below zero in these situations.

asciimov 5y ago

> I found it to be ghastly, sitting closer to a coworker I detested than I lay next to my own spouse in bed. I could smell him. The only thing worse than working in an open office environment is having to sit next to someone who stopped showering and regularly smokes. Smokers/Alcoholics/drug users/the unwashed are the worst, followed closely by people that wear heavy musky scents.

jdlshore 5y ago

This is a polemic against Extreme Programming that could have been written 15 years ago (and been just as wrong-headed then). And was. Many times.

EVa5I7bHFq9mnYK 5y ago
I think they took the idea of Extreme Programming from correctional institutions. When you are tied to another prisoner by a chain, it's much harder to escape (or to go on facebook, in a software institution).

cotelletta 5y ago

The real generational divide is people who feel this post in their bones and people who will nitpick at it because it's not in fact an unbiased survey. The point about focus is very true. The socialization of development via online tools means people think sticking their nose in other people's code is a virtue instead of a bother. If you're not going to contribute, why are you interrupting me?