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.
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.
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.
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.
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.
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?
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.
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.
Same period of employment for me too and I agree that it mostly matches my experience. Even though I find the article an exaggerated polemic, there are a few things that really resonate with me:
1. Open offices are stupid. For proof just see how many people love working from home where they have far fewer unwanted distractions. Yes there are other reasons to like remote work too, but I bet lack of distracting surroundings is up there.
2. Not having dedicated QA is mega stupid for something like Windows. You can clearly see that in Windows 10.
Other than that, yes I am a bit more accepting of some of the newer stuff, but I get where he's coming from. y'all need to get off my lawn.
If open offices were kept to the same atmosphere as libraries, I don't think there would be such an issue.
But it's truly bizarre that they're not, and companies think that is OK to put people in an environment that is the completely opposite of the environment it should be.
I'm from the same age group and, while I did not work in Microsoft back then, but everything he says matches my experience very closely (maybe just exaggerated a bit).
This is all also described in the book "Peopleware: Productive Projects and Teams". Especially the importance of individual flowtime. I tried to explain this once to an agile coach and suggested he read that book. We then continued to stuff our faces with candy while he started a "flow" game mostly focusing on imaginary situations demonstrating that collaborating as much as possible increased the flow of the team.
There's truth in it, but he omits the context for why these changes happened.
In 1990, real software companies could get away with shipping something major less than annually. Companies paced development to events like the annual Comdex. No company was expected to ship production software weekly, let alone daily. Competitive threats arose more slowly because there was less capital. The US software industry could be reasonably sure a Chinese firm wasn't going to suddenly arrive and become a material strategic concern in a few quarters. Seriously, read books describing 1990s era software dev and see how slowly things are paced before the Internet really hit. Look at the time scales involved. Even the rise of mighty Microsoft, considered the poster child of rapid high-tech growth circa 1992, pales in comparison to the Internet giants.
The world sped up. I hate the meeting culture we have now, but it's important to understand that it is a response to the pace of change rapidly increasing over the last 24 hours.
The other thing that really happened is the consumerization of software. In 1990, a much smaller slice of people used any computer in a given day. Frequently, those people could be expected to have undergone specific training for your product. Today, the number approaches 100% of adults globally. This means a higher level of fit, finish, and robustness are required now versus in 1990. Expectations are far higher.
Third, and I can't believe this needs to be said, but Microsoft was known for especially buggy software during the glory days highlighted in the article. Their OS releases were frequently late. They had to abort/restart the Vista project. Aside from the aesthetic factors of crashy software, it is somewhat obviously bad to have a multi-billion dollar company be unable to predict when (if?) its flagship products will ship, and in what form. Obviously, something had to change.
There's a lot to learn from the old days, but if one doesn't understand why things changed, one is likely to take the wrong lessons from history.
Nope. It isn't. I predate the author by a decade+ (first job in 1996), and he's bloviating.
Ask me about the time we had an informal meeting to decide on the premeeting strategy where we'd define the strategy for the actual meeting which would then result in a presentation to management so a decision could be made :)
It's always been a question of the culture you're in, and what they're trying to do. It still is. More collaborators => more meetings. Less ability to tolerate bugs => more formal development processes.
There's only a limited set of things where you can bang away in your dev cave for a few months and emerge with something people actually want. (It's absolutely more fun than the more formal/meeting-heavy approaches, but you're limited in scope and quality)
(With the caveat that open offices are and always have been an extremely stupid idea, and those were indeed less common)
We had "team (tech) leads" in the old days that took the place of marketing more or less — setting the general course for the software as a whole, the architecture as a whole.
But each engineer was given their own sandbox, their own piece of the framework/app to own. "Go implement an image cache."
Image cache engineer got to style their code however they pleased. They could tear it up and rewrite it when there was excessive technical debt. They knew it inside and out since they wrote it.
Often if it was code they inherited they would end up rewriting it eventually regardless — maybe piecemeal.
I don't remember every having code reviews. Sanity check? Sure, when there was some tricky bit of hacking required.
Yes, QA. Unit tests seem to make management happy these days. "I want to see 85% coverage!" as though that magically means we have less bugs.
I'm a few years younger than the author, based on when he started working, but I can relate to some of the attitudes of "the old days".
I worked at Microsoft and do remember when everyone had an office and the goal of managers was to keep you from having too many meetings. Nowadays, I also have probably 1-2 hours of recurring daily meetings. Absolutely everything needs to be tracked (daily standup, sprints, 1:1 with manager, skip-level meetings, team meetings, all hands, peer feedback), so you end up with meetings just to make sure everyone is on track. It's ridiculous.
I think it's all related to the fact that the pace of software development was just so much slower back then. I remember you could really bullshit a lot more 10-20 years ago. You could hang out with a coworker for an hour or play games with other coworkers and it was acceptable use of time. Nowadays, with daily standup, I feel guilty for wasting too much time because I'd have to give an update on where I am with work. Before, you might sync once a week, at most, so you had some breathing room. The industry was just more "fun" to be in.
Product releases were on yearly, or multi-year, schedules as well. Now everything is updated every week. I remember even ten years ago, we were releasing our software every 2 or so years, then they worked towards once a year, and then 6 month updates, and then monthly, and so on.
The author isn't wrong, but there's enough straw men in there that I'd recommend that you refrain from smoking while reading it. What was written was most likely true for the group the author worked in at Microsoft at the time. It most certainly is not a report on the software industry in general at that time. Some of it's true, some of it might have been true at some companies. But do note it's generalizations that don't give much to argue about; it's mostly old man shaking fist at clouds. Or cranky old anti-social asshole rants about kids today, depending on the read.
But this gem stands out:
"I would fix it, he’d verify, and we’d keep no records."
Yeah, you don't get to work on my team if you're going to sweep bugs under the rug.
It’s valid for his interpretation of his experiences.
Companies varied tremendously. I don’t share many of his opinions and experiences, and I’ve been coding his entire career.
I LOVE pair programming, for example, on the rare event that I can convince someone to do it. And “waterfall” did happen, but was mostly Fortune 500 and government contracts, and those of us not in that situation laughed at it. And I see benefits of test driven development, even if I write most of my tests after the fact.
The number of meetings, in my experience, was more a function of the size of the company and the team, than the era. I suspect some of the change he blames on millennials is just Microsoft getting more bureaucratic and bloated over the years.
One thing that I haven’t seen anyone commenting on is the huge shift in how software is delivered. If you take a year or two to plan for a physical release of a product, there is a lot more pressure to get things perfect the first time. If you can patch something today and go live, it’s not the same as have to send physical updates to a million customers. QA was definitely important, and, I would say, more important than today. Developers as testers is great, but by no means enough. I think testing has been shifted to users somewhat.
I do think that there was more of an understanding that uninterrupted time was very important. IBM did a lot of studies on what produced productive programmers and uninterrupted time was a huge factor. But software development has changed hugely over the years. I’ve been building a project that is similar to something I built only 15 years ago, and it’s amazing to me how much easier it is. I’m spending way more time gluing components together, with the help of stack overflow, and less time on hard problems. This may have changed what the optimal strategy is. I certainly try hard to be a good programmer in today’s environment, and not waste time complaining that things were better when we carved software into stone tablets.
So, I’m not going to say he’s wrong, but a lot of that was not my experience.
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.
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.
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.
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 :)
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.
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.
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.
You usually end up making and changing product plans. Meeting with others about changing the product plan. Code reviews.. standups.. I guess you have never ended up in meetings about meetings.
I've been there. People schedule meetings for a living. It took 9 months to add a field once.
Meetings. I am absolutely astonished at the number of meetings IT managers come up with. I'm 100% convinced that the purpose of meetings is for managers to be able to claim that they did something this week to their higher ups (who, of course, are doing the same thing).
I get it, that manager of yours has lots of meetings to go to or hold himself. Being in the same spot (tho "IT Manager" is not my title and I hope it never will be lol) I do understand how it gets to be this way. I have weeks where I only get to code 0 hours. Others I code for maybe a day total across the whole week or maybe 2. It comes and goes. When we on boarded 3 new guys on the team in the same weeks for example I got to not code at all for a few weeks as I'd rather unblock each of them, answer their questions etc. That's OK by me. I was able to do that because I do code myself still, I know our systems etc. and the regular 1:1s we gotta do (which are important as well) are mixed in with this as well and become actual "meetings" in WFH situations instead of "accidentally bumping into them at the coffee machine".
Now as for IC developers only coding a single hour in a week, there's something very wrong indeed if you ask me.
I'm thinking "The Office" here. If you don't mind my asking what kinds of meetings did they invent for ICs to attend for 39 hours a week?
My experience is that you spend lots of time producing and reviewing documents. Most of these documents, in my experience, aren't really used or consulted much. Sometimes the feature gets completely shelved, often changed so much that the document is out of date, and if the document disagrees with the decision makers then the document loses so it's better to just track what they say rather than what's in the document.
I think this is your problem, not modernity. In my 7 years working I've always stayed at smaller companies and I've never really had the problems you describe.
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.
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.
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.
> It should be abundantly clear at this point that it does not
Honestly, I am not so sure. Yes, I feel the same as you, but I might be biased, there are so many people who swear by the new approach. I don't think anybody has a definitive proof one way or the other.
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.
> 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?
The output of TDD is not the tests themselves, but the process of designing beforehand what is expected behaviour using up-front tests. The tests then acts as a guide to later development of code. Both should be adjusted during the discovery journey. The tests should then reflect the value that the code provides, and must be usable as-is in later refactors to have much worth themselves. "Acceptance criterias" should be self-evident from the ongoing development processes, and is not a final signoff.
TDD tests would ideally be used for hunting business value, and focus on overall desired product behaviour and qualities.
Are you saying you want to replace the specification with tests? That's really dubious to me.
I don't think it really helps software development, if instead of "here's the description of what we need to do" the SW developer gets "here's a few examples of what we need to do" (albeit if the examples can be automatically verified).
If that's NOT your intent, what's the role of specification in the TDD, and how it's interacting with the implementation and the tests?
It's just the idea behind Test Driven Development, that tests drive development. It won't be very effective as a handover, though could be used as acceptance criterias if that is needed.
The adherents really want tests to be the specification, as a way to be measurable / testable. Specs may be converted to tests.
But most of it is theory. It all depends, as usual, on the dev(s) and circumstances.
My one and only truly TDD project went brilliantly, but there were specific circumstances. In this project, I created the back-end and API while an outsourced team built the UI. What made it work well was that I wrote the tests AND the spec at the same time, and kept both up to date. Completed tests equalled progress on the back-end, made it easy to identify any regressions in my own code, and clear differentiated between logic and general HTTP plumbing errors.
> Are you saying you want to replace the specification with tests? That's really dubious to me.
That's pretty much it. The value is that tests can be automatically executed and verified. A specification document can't.
Writing a spec is still a step in the process - a bootstrapping step. The spec is a "write one to throw away" placeholder until you get far enough that the spec can be replaced with executable tests.
I don't think tests can ever replace specification, it's like trying to replace a mathematical proof with a computer experiment. Unless it's something like property-based tests, but even there..
My take on specification is that you encode it to be executable as your program, during development. Ideally, the program should encode the specs in the most straightforward way possible. To "specialize" the spec into tests first and then "generalize" it again from tests into a working program seems like unnecessary hassle, and frankly prone to information loss.
It's interesting, because as I state in another comment, I have a big disagreement with a guy who loves TDD. I guess I am a theorist (I derive my feeling of correctness from simplicity of the code) and he is an empiricist (he derives his feeling of correctness from many small tests), and it somehow defines our approach.
Ultimate TDD is machine learning. You give the machine all the test cases, and it figures out the code. Except it doesn't work as well on out of test samples. Human oversight is still required.
TDD is double-entry bookkeeping. Done well, you've spec'd the behavior twice, once as constraints, and once as logic. It's of limited utility in the moment, but it's invaluable going forward, as you make changes. (The in-the-moment use is about surfacing API design forces, and I'm not sure TDD is the best way to achieve good design)
I like the double-entry bookkeeping analogy, but isn't it true for all tests? In fact, as the article explains, in the old days it was a specialized QA department (different from development) which wrote tests often just based on specs, and the barrier (also called black-box testing) was there precisely to have independent verification. It seems to me that this argument favors the old methods and not TDD in particular.
The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in your model of the world.
The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing)
I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact)
You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)
In my opinion TDD really only exploded in modern SW industry due to the shift to dynamic languages like Javascript and Python where you can’t even rely on the compiler to help you with types and typos.
Unit tests still help of course with static typed languages but you really don’t need to be afraid that refactoring can kill your entire code base as you have formal proof that types and names agree as part of your IDE and build process by default.
Testing serves the same function as type system in C++ - it imposes restrictions on the code and automates checking for those restrictions. It became absolutely necessary with the advent of type-less languages such as JavaScript or PHP.
> I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs
The obvious bugs should already be accounted for if you have decent param checking in most functions. Is the string empty? Is the array nil? Did the init succeed?
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.
I worked in programming back then, and you have the best response of all the others.
I have not worked in the field for a long time, but everything seems the same back then as it does now, as you represent it happening.
Back the the day, of course we spent a boatload more time in the design phase, lots of meetings to see what needs to be done. That's just common sense. How can you program if you don't know what to program? But then, as you get into the project, you create an excel spreadsheet with all the questions that you have, and then get them answered. But I would HATE to have to go to a scheduled meeting every week to discuss it. I prefer to just go over and ask the people, when it was convenient for me and them.
However, I had always worked in smaller companies, where it was easy to just walk over and talk to the person, no matter what level they were, from receptionist to CEO. But I recognize that in a huge company like Google, things have to be different. But personally, I would never elect to work in companies like that. It's not my skill set. I'd commit suicide in a company like that. I'd rather work in programming in a sewer company or a retail store company with 20 stores, where they had a computer department of 5 or 10 people. That's just me. I hate being a cog in a machine. I like variety and talking to all different levels and different departments, when I chose to do so. Nobody in a small or medium sized business is going to have mandatory meetings 20 hours a week. That's just not reality. Just no way in hell, back then or now. As I said, I have not worked in the industry for a long time, but I think you can generalize this, that working for a small or medium sized company is going to be as he said. But even back in the day, if you worked in IBM or some huge company with 50 or 100 programmers, even then, it was like the author said he hated - much more strict and regulated, even back then. I never worked in them, but I was in the industry and talked to those that did work in them, and read industry journals. But even at Microsoft, there was a f-ck of a lot more rigidity. Maybe not if you were a superstar programmer, but if you were low on the food chain, you were going to be strictly regulated. Maybe Microsoft not as much as IBM, but still. Not like working in a 3-15 person department at a small company, where you pretty much have full autonomy, and your time is your own.
So, things really are not too different, actually.
I see that you worked about FAANG, but even now, would you think working at a small company with 3-15 tech people, would be more like the author said? Just by common sense? I'm sure you agree with me.
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
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
IMHO. The effort is going to added complexity. Not doing the simplest thing that could possibly work. I suspect managers and directors allow this because they are just trying to grow the own teams as much as possible thus growing their careers.
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).
I hadn't seen that earlier, and (knowing myself, and being honest) it would've alienated me so much that I wouldn't have wanted to have a discussion around this article by that person.
But, given that we're already here, and if I'm aspiring to be the change I want to see in the world (as we say), I suppose it's most inclusive and cooperative to have a civil discussion about the topic of the article -- even I'm disappointed or offended by some separate statements of the author.
(And if we can do that, maybe in another context we can discuss what's bothering different people around the other topics, and collectively improve around those.)
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.
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.
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.
They don't have this skill. Even the ones think they do. And when it comes to their own code it's even worse. One talented QA is worth 10-100 developers when it comes to finding bugs in their software.
Both developer and non-developer testing is mandatory. The testing space is infinite, you can't test for all possible scenarios even theoretically. So you should know where to look for bugs.
A cornerstone of the Kanban manufacturing process is that QA is done all along the manufacturing process, not something that is just tacked onto the end.
It doesn’t mean no QA is done at the end. It’s just less overhead to also do it along the way.
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.
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.
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.
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.
Depends. Maybe I throw everything away, write a new unit test for the true root cause, and start over from there. I’m comfortable taking very long journeys to reach very small code changes if that’s the best solution.
What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.
Yeah, speaking as an increasingly older developer, "resistance to interruption" is probably one of the cardinal skills you can learn as a developer. The ironic thing about it is the actual skill you're developing when you do this is extremely valuable even when doing "solo, uninterrupted work", because, ironically, one of the greatest sources of distractions is your own mind's brainstorming.
In doing "solo, meditative work", the hardest skill you have to develop is keeping your mind trained on the direct thing you're trying to accomplish, and not letting other parts of the problem intrude on your though process. If you've got any drop of ADD/ADHD (which by the "any drop" definition basically includes everyone), your mind will constantly get pulled away from the "task at hand" and start thinking about other parts of the problem. You'll be working on subsystem A (i.e. the task at hand), and you'll start thinking about how it interacts with subsystem B, and start thinking "oh gosh, I didn't realize this will also impose some constraints on subsystem C".
One of the key reasons this is a mind trap is because these side-things are genuinely useful; you'll run into caveats as your mind starts exploring "the interaction of subsystem A and B", and start to realize B's actually going to impose some hard constraints on A. The naive thing to do is to assume "well, there's no point in designing A because of what I just discovered - I better figure out all those constraints first". What happens then is a sort of writer's block - no matter what you end up thinking of, you constantly get distracted with caveats and gotchas, and rarely manage to have a session where you can fully "think through" subsystem A and draft a complete design. If this tendency isn't policed, you'll have a tendency in all of your "deep flow" sessions to have your mind start the session by thinking about the real thing you're trying to build, but then aimlessly wander off onto the paths of all the ways your thing interacts with other stuff. Don't get me wrong - it's a useful thing to be able to do, but it needs to be deployed "at will" rather than being a gravity well your mind gets pulled into by compulsion.
Ideally, even though you know some of it will violate some constraints, it's a hugely useful skill to be able to keep your mind on target and fully think through "subsystem A", any constraint-violations-be-damned. Sure, it won't work, but at least you'll have a mental sketch of the whole thing which can then be amended. Usually you'll find that the sketch is still mostly right, and more importantly, you'll now be able to conceptualize "the whole thing" instead of always getting stuck on the first third.
---
The skills to maintain - and reestablish this "mental target lock" seem IME to be identical with the ones you need to stay in a flow state even with people around you constantly distracting you. Even if no "other people" are distracting you, and you're in a private office, you'll still be distracting yourself, so — I've found that a bulk of the improvement has to come from you, yourself, developing mental discipline on this, rather than from you having a favorable environment. Otherwise you'll have a private office to just daydream about development, rather than constructively thinking through things.
A favorable environment can be great to have, but the ability to rapidly recover from distractions is something that makes a developer extremely effective even if they've got a favorable, external-distraction-free environment, rather than being a skill that becomes worthless if the external distractions are removed.
It’s quite possible; Microsoft perpetrated a brain-dead interpretation of TDD around the time the author is describing (2008) and there are still people there who believe that’s what TDD is.
(Their definition: write all the tests, then write all the code. Moronic.)
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?
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.
I hate to say it, but that sounds a lot like agile!
I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-heavy platform where they could manage their fleet of locomotives and wagons, with a lot of computer assistance.
The product owner was a gem. Once he warmed up to the process, we'd get him in a room and he'd talk and talk and talk about everything he found difficult. I mainly worked on the project alone, and bit by bit we addressed his issues. The issues grew more and more specific, until about 3 months post-release, where he came in and had nothing left to add. There wasn't even a wish list left. It was done.
This was where I came to agree with the agile 'small batch size' approach. Mistakes come cheap and fast. Most mistakes are usually communication issues, rather than technical. That's not to say that requirements were changing while writing code - it's just that we had good feedback loops, and a short phase had us fixing the real problems faster.
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.
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.
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.
I have, and so have a lot of people. (Look up “Ward Number”). He worked at Tektronix back in the day. He created the WikiWikiWeb in about 90 lines of tight Perl. He is currently building the Federated Wiki. He’s currently working at New Relic, last I heard.
He also created Fit, which I had the pleasure of working with him on. It was a very different coding style than mine, very tight and flexible. I learned a lot.
Yup, super efficient if that's priority issue to resolve.
In this type of 1 on 1 session with a customer, who was acting as a QA I managed to resolve more than 10 issues on the fly within an hour. We had multiple sessions like that and they were very productive.
Some issues couldn't be fixed "while you wait" of course and had to be postponed and checked and fine tuned on next session.
Those must have been very trivial bugs with very cursory manual QA. No complex side effects or interdependencies. Could have done it in 30 then with TDD.
Not really. Writing test for them. being trivial and all, would take many times more time than fixing them.
Those bugs had limited impact so the QA could manually test all the reasonable places of impact after my fix, while I was fixing the next one. It was really great feeling of interaction and collaboration. I felt like a proper wizard and I knew that after this sessions all the things we fixed are good.
This is completely incomparable to TDD, where you just sit in your own muck and shovel it back and forth with very little interaction with outside reality ending up with ton of code that does nothing because it just makes tests that will never fail or they fail all at once because they will fail only if something very major breaks.
To be clear, I have done it both ways with a QA team and pure XP style TDD. Both projects were successful, the money is in the bank. Both projects had good steady velocity for years and AFAIK are still printing $10-100M/year. Maybe I just had bad testers but I know with the good developers I don’t need any testers.
>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.
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.
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.
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.
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.
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.
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.
169 comments
[ 3.3 ms ] story [ 249 ms ] thread"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.
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.
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
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.
He's not making things up, but I don't think his takeaways are worth, well, taking any further.
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.
Of course, that may be what drew me to coding then. Perhaps the new culture attracts a new type of coder that likes process much more.
1. Open offices are stupid. For proof just see how many people love working from home where they have far fewer unwanted distractions. Yes there are other reasons to like remote work too, but I bet lack of distracting surroundings is up there.
2. Not having dedicated QA is mega stupid for something like Windows. You can clearly see that in Windows 10.
Other than that, yes I am a bit more accepting of some of the newer stuff, but I get where he's coming from. y'all need to get off my lawn.
But it's truly bizarre that they're not, and companies think that is OK to put people in an environment that is the completely opposite of the environment it should be.
In 1990, real software companies could get away with shipping something major less than annually. Companies paced development to events like the annual Comdex. No company was expected to ship production software weekly, let alone daily. Competitive threats arose more slowly because there was less capital. The US software industry could be reasonably sure a Chinese firm wasn't going to suddenly arrive and become a material strategic concern in a few quarters. Seriously, read books describing 1990s era software dev and see how slowly things are paced before the Internet really hit. Look at the time scales involved. Even the rise of mighty Microsoft, considered the poster child of rapid high-tech growth circa 1992, pales in comparison to the Internet giants.
The world sped up. I hate the meeting culture we have now, but it's important to understand that it is a response to the pace of change rapidly increasing over the last 24 hours.
The other thing that really happened is the consumerization of software. In 1990, a much smaller slice of people used any computer in a given day. Frequently, those people could be expected to have undergone specific training for your product. Today, the number approaches 100% of adults globally. This means a higher level of fit, finish, and robustness are required now versus in 1990. Expectations are far higher.
Third, and I can't believe this needs to be said, but Microsoft was known for especially buggy software during the glory days highlighted in the article. Their OS releases were frequently late. They had to abort/restart the Vista project. Aside from the aesthetic factors of crashy software, it is somewhat obviously bad to have a multi-billion dollar company be unable to predict when (if?) its flagship products will ship, and in what form. Obviously, something had to change.
There's a lot to learn from the old days, but if one doesn't understand why things changed, one is likely to take the wrong lessons from history.
Yes. Our customers were, for the most part, nerds like us in the 90's. We knew what features they wanted because we wanted them.
Ask me about the time we had an informal meeting to decide on the premeeting strategy where we'd define the strategy for the actual meeting which would then result in a presentation to management so a decision could be made :)
It's always been a question of the culture you're in, and what they're trying to do. It still is. More collaborators => more meetings. Less ability to tolerate bugs => more formal development processes.
There's only a limited set of things where you can bang away in your dev cave for a few months and emerge with something people actually want. (It's absolutely more fun than the more formal/meeting-heavy approaches, but you're limited in scope and quality)
(With the caveat that open offices are and always have been an extremely stupid idea, and those were indeed less common)
We had "team (tech) leads" in the old days that took the place of marketing more or less — setting the general course for the software as a whole, the architecture as a whole.
But each engineer was given their own sandbox, their own piece of the framework/app to own. "Go implement an image cache."
Image cache engineer got to style their code however they pleased. They could tear it up and rewrite it when there was excessive technical debt. They knew it inside and out since they wrote it.
Often if it was code they inherited they would end up rewriting it eventually regardless — maybe piecemeal.
I don't remember every having code reviews. Sanity check? Sure, when there was some tricky bit of hacking required.
Yes, QA. Unit tests seem to make management happy these days. "I want to see 85% coverage!" as though that magically means we have less bugs.
I worked at Microsoft and do remember when everyone had an office and the goal of managers was to keep you from having too many meetings. Nowadays, I also have probably 1-2 hours of recurring daily meetings. Absolutely everything needs to be tracked (daily standup, sprints, 1:1 with manager, skip-level meetings, team meetings, all hands, peer feedback), so you end up with meetings just to make sure everyone is on track. It's ridiculous.
I think it's all related to the fact that the pace of software development was just so much slower back then. I remember you could really bullshit a lot more 10-20 years ago. You could hang out with a coworker for an hour or play games with other coworkers and it was acceptable use of time. Nowadays, with daily standup, I feel guilty for wasting too much time because I'd have to give an update on where I am with work. Before, you might sync once a week, at most, so you had some breathing room. The industry was just more "fun" to be in.
Product releases were on yearly, or multi-year, schedules as well. Now everything is updated every week. I remember even ten years ago, we were releasing our software every 2 or so years, then they worked towards once a year, and then 6 month updates, and then monthly, and so on.
But this gem stands out:
"I would fix it, he’d verify, and we’d keep no records."
Yeah, you don't get to work on my team if you're going to sweep bugs under the rug.
Companies varied tremendously. I don’t share many of his opinions and experiences, and I’ve been coding his entire career.
I LOVE pair programming, for example, on the rare event that I can convince someone to do it. And “waterfall” did happen, but was mostly Fortune 500 and government contracts, and those of us not in that situation laughed at it. And I see benefits of test driven development, even if I write most of my tests after the fact.
The number of meetings, in my experience, was more a function of the size of the company and the team, than the era. I suspect some of the change he blames on millennials is just Microsoft getting more bureaucratic and bloated over the years.
One thing that I haven’t seen anyone commenting on is the huge shift in how software is delivered. If you take a year or two to plan for a physical release of a product, there is a lot more pressure to get things perfect the first time. If you can patch something today and go live, it’s not the same as have to send physical updates to a million customers. QA was definitely important, and, I would say, more important than today. Developers as testers is great, but by no means enough. I think testing has been shifted to users somewhat.
I do think that there was more of an understanding that uninterrupted time was very important. IBM did a lot of studies on what produced productive programmers and uninterrupted time was a huge factor. But software development has changed hugely over the years. I’ve been building a project that is similar to something I built only 15 years ago, and it’s amazing to me how much easier it is. I’m spending way more time gluing components together, with the help of stack overflow, and less time on hard problems. This may have changed what the optimal strategy is. I certainly try hard to be a good programmer in today’s environment, and not waste time complaining that things were better when we carved software into stone tablets.
So, I’m not going to say he’s wrong, but a lot of that was not my experience.
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.
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.
In those companies I've worked where we released in some waterfall-ish manner and/or QA was important, we have both.
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.
Which is ironic, because the "modern" incarnation of those things evolved directly out of an explicit reaction against them.
So what do you accomplish in the rest of that weeks? What does your org expect you to do? (Genuine question, I'm just curious).
I've been there. People schedule meetings for a living. It took 9 months to add a field once.
Enter bureaucracy, tickets, meetings, docs and more docs. More meetings. Their status report is more meetings.
Now as for IC developers only coding a single hour in a week, there's something very wrong indeed if you ask me.
I'm thinking "The Office" here. If you don't mind my asking what kinds of meetings did they invent for ICs to attend for 39 hours a week?
I think this is your problem, not modernity. In my 7 years working I've always stayed at smaller companies and I've never really had the problems you describe.
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.
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.
Honestly, I am not so sure. Yes, I feel the same as you, but I might be biased, there are so many people who swear by the new approach. I don't think anybody has a definitive proof one way or the other.
> 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.
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?
TDD tests would ideally be used for hunting business value, and focus on overall desired product behaviour and qualities.
I don't think it really helps software development, if instead of "here's the description of what we need to do" the SW developer gets "here's a few examples of what we need to do" (albeit if the examples can be automatically verified).
If that's NOT your intent, what's the role of specification in the TDD, and how it's interacting with the implementation and the tests?
The adherents really want tests to be the specification, as a way to be measurable / testable. Specs may be converted to tests.
But most of it is theory. It all depends, as usual, on the dev(s) and circumstances.
That's pretty much it. The value is that tests can be automatically executed and verified. A specification document can't.
Writing a spec is still a step in the process - a bootstrapping step. The spec is a "write one to throw away" placeholder until you get far enough that the spec can be replaced with executable tests.
My take on specification is that you encode it to be executable as your program, during development. Ideally, the program should encode the specs in the most straightforward way possible. To "specialize" the spec into tests first and then "generalize" it again from tests into a working program seems like unnecessary hassle, and frankly prone to information loss.
It's interesting, because as I state in another comment, I have a big disagreement with a guy who loves TDD. I guess I am a theorist (I derive my feeling of correctness from simplicity of the code) and he is an empiricist (he derives his feeling of correctness from many small tests), and it somehow defines our approach.
The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing)
I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact)
You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)
Unit tests still help of course with static typed languages but you really don’t need to be afraid that refactoring can kill your entire code base as you have formal proof that types and names agree as part of your IDE and build process by default.
The obvious bugs should already be accounted for if you have decent param checking in most functions. Is the string empty? Is the array nil? Did the init succeed?
Inline unit tests anyone? :-)
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.
I have not worked in the field for a long time, but everything seems the same back then as it does now, as you represent it happening.
Back the the day, of course we spent a boatload more time in the design phase, lots of meetings to see what needs to be done. That's just common sense. How can you program if you don't know what to program? But then, as you get into the project, you create an excel spreadsheet with all the questions that you have, and then get them answered. But I would HATE to have to go to a scheduled meeting every week to discuss it. I prefer to just go over and ask the people, when it was convenient for me and them.
However, I had always worked in smaller companies, where it was easy to just walk over and talk to the person, no matter what level they were, from receptionist to CEO. But I recognize that in a huge company like Google, things have to be different. But personally, I would never elect to work in companies like that. It's not my skill set. I'd commit suicide in a company like that. I'd rather work in programming in a sewer company or a retail store company with 20 stores, where they had a computer department of 5 or 10 people. That's just me. I hate being a cog in a machine. I like variety and talking to all different levels and different departments, when I chose to do so. Nobody in a small or medium sized business is going to have mandatory meetings 20 hours a week. That's just not reality. Just no way in hell, back then or now. As I said, I have not worked in the industry for a long time, but I think you can generalize this, that working for a small or medium sized company is going to be as he said. But even back in the day, if you worked in IBM or some huge company with 50 or 100 programmers, even then, it was like the author said he hated - much more strict and regulated, even back then. I never worked in them, but I was in the industry and talked to those that did work in them, and read industry journals. But even at Microsoft, there was a f-ck of a lot more rigidity. Maybe not if you were a superstar programmer, but if you were low on the food chain, you were going to be strictly regulated. Maybe Microsoft not as much as IBM, but still. Not like working in a 3-15 person department at a small company, where you pretty much have full autonomy, and your time is your own.
So, things really are not too different, actually.
I see that you worked about FAANG, but even now, would you think working at a small company with 3-15 tech people, would be more like the author said? Just by common sense? I'm sure you agree with me.
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
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.
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.
It almost makes me wonder if comment timestamps are stored relative to the parent post...
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.
We don’t talk too much about this.
> If your profile includes pronoun pairs I will likely block you. If "they/them," I will definitely block you.
https://twitter.com/ComposerDark
Yes, he's the asshole here.
But, given that we're already here, and if I'm aspiring to be the change I want to see in the world (as we say), I suppose it's most inclusive and cooperative to have a civil discussion about the topic of the article -- even I'm disappointed or offended by some separate statements of the author.
(And if we can do that, maybe in another context we can discuss what's bothering different people around the other topics, and collectively improve around those.)
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.
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.
Forbidding is nonsense. A. test is also form of documentation. Nothing stops you to add more tests on top of those by different person.
It doesn’t mean no QA is done at the end. It’s just less overhead to also do it along the way.
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.
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.
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.
In doing "solo, meditative work", the hardest skill you have to develop is keeping your mind trained on the direct thing you're trying to accomplish, and not letting other parts of the problem intrude on your though process. If you've got any drop of ADD/ADHD (which by the "any drop" definition basically includes everyone), your mind will constantly get pulled away from the "task at hand" and start thinking about other parts of the problem. You'll be working on subsystem A (i.e. the task at hand), and you'll start thinking about how it interacts with subsystem B, and start thinking "oh gosh, I didn't realize this will also impose some constraints on subsystem C".
One of the key reasons this is a mind trap is because these side-things are genuinely useful; you'll run into caveats as your mind starts exploring "the interaction of subsystem A and B", and start to realize B's actually going to impose some hard constraints on A. The naive thing to do is to assume "well, there's no point in designing A because of what I just discovered - I better figure out all those constraints first". What happens then is a sort of writer's block - no matter what you end up thinking of, you constantly get distracted with caveats and gotchas, and rarely manage to have a session where you can fully "think through" subsystem A and draft a complete design. If this tendency isn't policed, you'll have a tendency in all of your "deep flow" sessions to have your mind start the session by thinking about the real thing you're trying to build, but then aimlessly wander off onto the paths of all the ways your thing interacts with other stuff. Don't get me wrong - it's a useful thing to be able to do, but it needs to be deployed "at will" rather than being a gravity well your mind gets pulled into by compulsion.
Ideally, even though you know some of it will violate some constraints, it's a hugely useful skill to be able to keep your mind on target and fully think through "subsystem A", any constraint-violations-be-damned. Sure, it won't work, but at least you'll have a mental sketch of the whole thing which can then be amended. Usually you'll find that the sketch is still mostly right, and more importantly, you'll now be able to conceptualize "the whole thing" instead of always getting stuck on the first third.
---
The skills to maintain - and reestablish this "mental target lock" seem IME to be identical with the ones you need to stay in a flow state even with people around you constantly distracting you. Even if no "other people" are distracting you, and you're in a private office, you'll still be distracting yourself, so — I've found that a bulk of the improvement has to come from you, yourself, developing mental discipline on this, rather than from you having a favorable environment. Otherwise you'll have a private office to just daydream about development, rather than constructively thinking through things.
A favorable environment can be great to have, but the ability to rapidly recover from distractions is something that makes a developer extremely effective even if they've got a favorable, external-distraction-free environment, rather than being a skill that becomes worthless if the external distractions are removed.
It’s quite possible; Microsoft perpetrated a brain-dead interpretation of TDD around the time the author is describing (2008) and there are still people there who believe that’s what TDD is.
(Their definition: write all the tests, then write all the code. Moronic.)
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?
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.
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.
I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-heavy platform where they could manage their fleet of locomotives and wagons, with a lot of computer assistance.
The product owner was a gem. Once he warmed up to the process, we'd get him in a room and he'd talk and talk and talk about everything he found difficult. I mainly worked on the project alone, and bit by bit we addressed his issues. The issues grew more and more specific, until about 3 months post-release, where he came in and had nothing left to add. There wasn't even a wish list left. It was done.
This was where I came to agree with the agile 'small batch size' approach. Mistakes come cheap and fast. Most mistakes are usually communication issues, rather than technical. That's not to say that requirements were changing while writing code - it's just that we had good feedback loops, and a short phase had us fixing the real problems faster.
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.
He also created Fit, which I had the pleasure of working with him on. It was a very different coding style than mine, very tight and flexible. I learned a lot.
Super easy. Just close cooperation with tester who's job is to test the change. You can with within an hour even with multiple back and forth.
In this type of 1 on 1 session with a customer, who was acting as a QA I managed to resolve more than 10 issues on the fly within an hour. We had multiple sessions like that and they were very productive.
Some issues couldn't be fixed "while you wait" of course and had to be postponed and checked and fine tuned on next session.
Those bugs had limited impact so the QA could manually test all the reasonable places of impact after my fix, while I was fixing the next one. It was really great feeling of interaction and collaboration. I felt like a proper wizard and I knew that after this sessions all the things we fixed are good.
This is completely incomparable to TDD, where you just sit in your own muck and shovel it back and forth with very little interaction with outside reality ending up with ton of code that does nothing because it just makes tests that will never fail or they fail all at once because they will fail only if something very major breaks.
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.
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.
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.
I imagine working from home could be done in that setting.