13 ms·

What Happened to Software Development?

84 points by gballan 7y ago

tgv 7y ago
Bit rambling, but it boils down to a critique of fad-driven management: we have do TDD, Agile, whatever, but --from the developer's point of view-- more as an end than a means.
jasonvorhe 7y ago
I can't believe what I'm reading. > By 2009 things were in disarray; the love of quality had completely given way to a mechanical process of checking boxes and several times I landed in hot water for being too thorough. He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. Then he continues that he was close to leaving the company because they started to apply Test Driven Development. Of course he's also not a fan of agile and he has a strong dislike for user stories while user scenarios is perfectly fine a term for him. Of course he's also not fond of team work, especially if you use a term for that he doesn't like. I can imagine him going into the office and telling young software engineers who approach him to get off his lawn. People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves and their judging attitude towards new approaches and terms is so last century.
- zozbot234 7y ago
  > ...People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves .... Large-scale software projects were definitely around in the 1980s and 1990s including at M$, so it can't be that. The thing about "teamwork", recurring meetings/standups and other drains on 'flow' and individual productivity, is that they are a cost of your chosen development model. They're things you're supposed to minimize wherever feasible by improving your toolset (e.g. good repository management, CI, static analysis tools to cut down on pointless "unit" testing, computer-mediated communication as opposed to doing everything in person, etc.), not expand until they take up all available resources.
- peteforde 7y ago
  Just to be clear: in a not-so-distant future, some little shit is going to be describing why people like you aren't going to be missed, so be kind. He actually makes some excellent points around challenging fad-driven-management, open office spaces, dorm culture instead of prioritizing flow, and what I see as a legitimate perspective on TDD's unfortunate tendency to reinforce blindspots. It's just a shame that he also sounds a bit like Hunter Thompson, shooting at cars passing too close to his compound. For the record, one thing he's absolutely correct about is this idea that being able to handle all aspects and dimensions of a complex project is somehow arrogant and/or anti-social and/or dinosaur-esque. I mean, I don't know anything about you but people who can competently build impressive shit solo command my respect. Your disbelief that such a thing can be extraordinarily valuable is just projecting a lack of confidence or imagination. To be clear: not everyone will (or should) go there... but it's your prejudiced rejection of the possibility as gauche that pets me backwards. You are not the first or only generation to have everything all figured out.
  - poisonborz 7y ago
    Solo warriors are not that unique, just look at most of the successful one-man free software projects. Thing is, you can't expect them to turn up in your team. These "fad" processes help to cultivate their oversight in a reproducible, proveable manner. Also, processes are a toolbox, and managers can be good or bad. This does not deduct from the value of the processes.
  - traderjane 7y ago
    Csikszentmihalyi is not respected by professionals of his field (there is no enthusiasm to followup on Flow). Of course Flow was also cargo cult executive catnip back in the day -- I suppose Mr. Fox's day.
- donatj 7y ago
  > He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. What are you talking about? Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period. I dislike the agile terminology because it’s so condescending. Your users have “stories”, it implies they’re fictional and not to be taken seriously. It’s dehumanizing.
  - kthejoker2 7y ago
    Really? Stories can't be nonfiction? I don't see that implication at all. Ever hear the story of Albert Einstein on the train? Galileo's trial? The sinking of the Titanic? Anyway, other reasons to like it being called a story * Stories require two people, a teller and a listener. * Stories have an ending. * Stories are relatable to people who otherwise might not know they care about your product * The user is the hero of the story (i.e. the developer is the opposite of condescending by putting others first)
  - mcbits 7y ago
    > Windows 95, 98, 2000 and XP were all best in class I know some OS/2 fans who wouldn't go along with that, but I will. They were best in a class that was inundated with crippling bugs and vulnerabilities. Can we credit checklists and pair programming for the fact that it's now possible to connect to the Internet without joining a botnet within 5 minutes? Or save a file without worrying whether it will make it to disk before the next BSOD? Probably not directly, but procedures and conventions definitely needed to change.
  - koonsolo 7y ago
    > Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period. Haha, great joke. Oh wait you are serious? The amazing blue screens made me switch to Linux in that period. And if you knew about the state of Linux back then, that says something about this "best in class"
    - donatj 7y ago
      I ran RedHat and then Slackware for a time back then. For desktop purposes they were barely usable.
- hootbootscoot 7y ago
  again, the shameless trotting out of tropes like "arrogant" etc, which is precisely what the author rather cogently and concisely accused the industry of. You are merely proving the authors point, IMHO. (I added the H, happy? I'm a team player, you soulcrusher.)
- coldtea 7y ago
  >He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. Err, some of the best products of MS was from that era -- 80s and early-mid 90s. The rest is downhill.
- buboard 7y ago
  > Microsoft in a time where they didn't deliver any quality product at all. windows 2007 is my favourite windows version probably ever.
- deleted 7y ago
  [deleted]
- 7532yahoogmail 7y ago
  Agree - I've used the Balmer decade as my own slam time to time ...
- crustycoder 7y ago
  > People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves and their judging attitude towards new approaches and terms is so last century. The arrogance of believing that your "new" approaches are actually groundbreaking is the issue. He's saying that rigid prescriptive approaches that value the latest fad over the end result end up with poorer quality software that takes even longer to deliver. I've been cutting code even longer than he has, since 1983, and when you've been doing it that long, you see the same "Groundbreaking New Idea" reappearing around every 5-10 years - old stuff, new name and a fresh bunch of acolytes who believe they've found The One True Path. The issue is not the ideas, it's the fanaticism that so often accompanies them. Writing tests early? Yeah, we've done that for ages, particularly for gnarly bits of code. Pair Programming? Yeah, us engineers have always huddled together around code. CI? Yeah, I worked on an enterprise-level OS that ran its development infrastructure on the previous night's build, so if you "broke the gate" you had a couple of hundred engineers on your case. After a decade as a tech lead I'm now back at the codeface in an entirely different technology area, using "Agile", "Kanban", yadayadayada. Many of my coworkers are young enough to be my kids but we get on just fine - they treat The Old Fart gently and I'm (usually) polite enough not to giggle too much at the terminology - the article's comment about "Technical Debt" gave me a good chuckle. What we have in common is engineering pragmatism - if there's something new we'll take a look. If it works for us, we'll keep it, if not we won't. If we have deadlines to meet, yeah, we may have to make some compromises. If Software Engineering is ever to deserve the "Engineering" term it has to learn to behave like other engineering disciplines and begin to embrace evolution based on hard-won experience rather than the current widespread out-of-hand rejection of the past.
- FredRys 7y ago
  He is spot on. Not that everything is worse today. There are things that are a lot better these days. But this all goes in cycles. Human progress is not a continually improving thing. In many areas we sometimes go backwards for a while before it reverses again. One major driver for this is closemindedness. Rejecting the past without even considering its validity. In a little over twenty years from now just look around for that twenty year old programmer, not even born yet, who will be leading a new generation of programmers who will be mocking you as that "Get off my lawn guy" with the old fashioned obsolete old school ways. They will be pushing what they think are brand new ideas but are actually a variation of the 1980's and 1990's. But in the long run this constant turnover of fads does result in a solid body of knowledge of what works and what does not work. For instance a continuous recorded history of Chinese Cooking over the last 5000 years is an invaluable resource for exploration and inspiration for new ideas.
- koonsolo 7y ago
  > People like him aren't going to be missed. Meanwhile, there are other 40+ programmers like myself who still enjoy themselves with the latest tech, fads, open offices, lots of communication and fellow young programmers. Programming nowadays has improved so much it's crazy. - Have a problem? 99% chance your answer is on StackOverflow. (anyone remember the days before internet? I do! Searching (alone) hours on some cryptic error message) - Programming robots is so easy and cheap nowadays. - Everyone walks around with a super powerful computer, integrated GPU, camera, GPS, gyroscope and internet ready wherever you go. - So much powerful stuff available for free. - Current IDE's have so much handy functionality. - Make your software available to the world in an instant. Want to run your own server software? So easy and cheap! So yeah, grumpy old programmers still exist. But I also know plenty of old programmers who love all the new stuff.
lovetocode 7y ago
There is only only one appropriate response to this: “Ok Boomer” The only part I can agree with is that developers need periods of uninterrupted time everything else just comes off as an old man telling kids to get off his lawn. It took much longer to iterate on software in the 80s and 90s than it does now. And that is supposed to be a good thing? Agile has made the software development process much easier by reducing the feedback loop and taking a lot of the guesswork out of development. Daily stand ups may seem dumb to you but that’s because you refuse to get any value out of it. You can’t really say it’s over communication because it is supposed to be limited to 15 minutes. You should also know what your partners are working on because sometimes you both might be working on components that impact one another.
- megous 7y ago
  What I took from the article is that he disliked the "morning standup" because it forced him through a rush hour traffic, compared to previous situation.
  - ashildr 7y ago
    I made good experiences with moving the standup to a later hour for similar reasons. Sticking to an early standup if that means that team members are stuck in traffic - or not awake - is exactly _not_ agile.
    - thrower123 7y ago
      Better to just do the "standup" asynchronously in a groupchat if it is going to be a useless status check, as they usually are.
    - SuoDuanDao 7y ago
      Sounds like the early morning standups are for the manager's convenience more than the coder's, which might be the underlying trend driving OP's complaints.
deleted 7y ago
[deleted]
moonbug 7y ago
old man rants at Cloud.
kilburn 7y ago
What's up with the pair programming hate? I think it is great in the correct situations and would love to do more of it! 1. Get paired with another dev of similar level to work on new stuff. Bouncing ideas makes the surfacing solutions better. 2. Get paired with a dev that has been working on some system for a while. This is a much quicker way to learn the what's and why's of a project.
- thrower123 7y ago
  Because it is awful for people who don't enjoy social interaction, and get quickly worn out by it. Which encompasses a much larger share of programmers than the general public. Everything in modern faddish programming seems to be aimed squarely at stressing out and destroying the effectiveness of introverts.
  - cameronfraser 7y ago
    Pair programming isn't intended to be an all the time thing. A great example of pair programming is a new person gets hired and you pair program with them on a ticket so they can ask questions along the way. Having recently joined a remote startup I found this to be pretty essential to getting anything done. It's a great way of elevating programming level as well. You see different ways of doing things, different tools they use, etc. Introverts are also not being targeted in any way. People who have been at this a while are just very aware that you can get far more accomplished with a team that works well together than an individual developer can. You can be an introvert and still an effective team member. Nobody is fully introverted or fully extroverted.
- michaelbuckbee 7y ago
  Like everything the author listed it's about execution and applying the right tools to the right job. Some places _only_ do pair programming, some places go so wild with their unit tests that it becomes incredibly unwieldy, and lots of times different approaches get cargo culted from organizations where it made sense (we're a 10,000 member team writing a new OS) to a one where it doesn't (we're 2 people making a CRUD app side-project that got a little traction).
x3ro 7y ago
I do understand the criticism of open plan offices and the resulting interruptions, I do myself prefer a closed office. And I definitely haven't been around as long as this person. That being said, it feels like this person is just upset that they're not "at the top" anymore. Quote: It was great back then; we were treated like princes [...]
nmyk 7y ago
> I decided to pack up and go, and left the USA on 11/15/2010, intending to retire at 56, play my guitars, read my physics library, live my life in very strange language and relax. This is someone who prefers solitude. It's not surprising that he doesn't like collaborative work. He seems to be projecting his own preference onto the software industry though, which is misguided. Lots of great software has been built with all kinds of different workflows.
- zozbot234 7y ago
  >> ... play my guitars ... Nah, he's just a literal rockstar programmer. You've got to give him that.
  - hootbootscoot 7y ago
    way to cheer for babylon, my future grumpy old fart in waiting...
- 7532yahoogmail 7y ago
  Agree.
ddek 7y ago
You know every week there’s an article here about some self-proclaimed ‘genius’, who’s undocumented, untested, unchallenged work is so critical the team that they can’t possibly fire him. Then they do, and quickly realise they’re better off? It’s not that this feels like it was written by one of those guys - this categorically was written by one of those guys. It’s a damn good thing he’s out our ecosystem, and if he has to preach his incompetence at least he’s not infecting a relevant part of the world.
- dang 7y ago
  Personal attacks are not ok. We ban accounts that post them. Maybe you don't owe the person better, but you definitely owe this community better if you're posting here. Would you mind read the site guidelines and taking the intended spirit to heart? We'd appreciate it. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ashildr 7y ago
Old man rants at agile. (though I’d agree that many implementations of agile methods are cargo cult and give it a bad name.)
chrismmay 7y ago
I hope younger devs keep in mind that one day you will be the "old" one.
joshwarwick15 7y ago
B O R I N G
marcus_holmes 7y ago
I've worked in both environments (I too was coding in the 90's). It was definitely easier in the 90's - less complexity, more freedom to do your own stuff. Project management was less hands-on, and more concerned with reporting up than managing down. But I like it now. I like that the teamwork matters, and the morning standups are great (good to know what your colleagues are working on, and be able to work out if you need to collaborate with them on stuff you're both touching). I like pair programming on the tricky bits (and being able to admit that some bits are tricky and ask for help without being sneered at). Programmers used to be treated as weird, eccentric geniuses that you had to handle with care and needed special work environments to thrive in. Now we're just people, and get treated like normal people. I understand how that won't suit some, because they enjoyed being treated differently ("like princes" I guess... but more like princesses because we were effectively locked in a tower). And as we get older, our tolerance for change decreases. It takes effort to avoid becoming a grumpy old fart, complaining at everything that has changed. But the effort is worth it.
- giancarlostoro 7y ago
  > And as we get older, our tolerance for change decreases. It takes effort to avoid becoming a grumpy old fart, complaining at everything that has changed. But the effort is worth it. Just the other day a Senior was telling me about one job he went back to where they were bought out. The new people wanted to introduce process into how they work and since most of the devs complained that whole team was let go. The sad part was he didnt care what he had to do to work. He just wanted to work. So the majority opinion he didnt agree with got him screwed over. If you are going to assume a whole team is rotten please dont. Interview them independently.
- hootbootscoot 7y ago
  .... and there you go proving the authors point about derision and subtle sneers aimed at what is arguably the most effective means of getting focused highly productive developers: treating them like HUMANS, instead of faceless cogs, and allowing for focused programming time without distractions. "old farts" rock, my friend. I get that some folks enjoy molding young minds to sick patterns, free of pushback, but ultimately I will contend that it's it's counterproductive to ones true goals. (unless ones true goals are merely to crush human egos and souls...)
purplezooey 7y ago
"The PMs were worse, putting on a perky, chirpy and cheerful show of sounding “engaged,” when in reality I knew they spent most of their day playing games..." Ayup....
- deleted 7y ago
  [deleted]
wayoutthere 7y ago
I think a lot of this is just a product of the amount of complexity software is expected to manage. No single person can keep it all in their head with all the constantly changing parts. This has followed the shift of oftware development from a capital investment to more of an operational one. The job profile of operational work doesn't fit neatly within the solo developer / deep flow paradigm. Sure, that might be necessary for some dev jobs, but most dev jobs are more figuring out what needs to be built than actually building it. And for better or worse (usually worse for those of us on the spectrum), every job seems headed in this direction.
- zozbot234 7y ago
  > the amount of complexity software is expected to manage. How much of that is incidental complexity, though? What happened to refactoring and paying down technical debt - weren't these supposed to be tenets of Agile?
  - wayoutthere 7y ago
    The best way to think of Agile is "bare minimum project management for the sake of product management". You can get wrapped up in the rituals and "best practices" but at the end of the day, it's usually about delivering software in a way that makes it easy to buy and sell. It's easier to sell software when you can pull a feature on a roadmap up to land a big account than it is to refactor and cut a custom release for them. It's easier to buy software when you know it's constantly improving. Software also does more and integrates with more than it ever has. This is driven by customer requirements, which are pretty much non-negotiable.
    - zozbot234 7y ago
      > It's easier to sell software when you can pull a feature on a roadmap up to land a big account It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Which you'll need to pay down in some way, if you want your software to be "constantly improving". If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.
mellosouls 7y ago
Unfortunately some decent points are somewhat obscured by the condescending and nostalgic tone that hits you in the first line: Many too young to have ever seen the halcyon days of software development... Every generation has blinkered old guys talking in that way, who can safely be ignored. There has never been a more exciting time to code, especially away from the corporate treadmill. I particularly lost patience when he started talking about the Beatles (and I love the Beatles). Mate, if you came of musical age in the early nineties it's spelt Nirvana. Or Wu Tang. Whatever, he sounds like he was always looking back.
- coldtea 7y ago
  >Every generation has blinkered old guys talking in that way, who can safely be ignored. Can they? Here we are in 2019 and we're reinventing (usually in worse shape) everything people already had in the 70s, 80s, 90s, even the 60s (Go is closer to Algol than to a 2019 language, our IDEs are worse than LISP machines or Smalltalk environments). We all use UNIX (a 70s technology), OS X/iOS (a variation on a 80s microkernel + BSD), and Windows (a 30+ year old OS design, from a prominent 70s/80s OS designer). We reinvented techniques used 40+ years ago in mainframes as containers. Our UI tech of choice is the DOM... >Mate, if you came of musical age in the early nineties it's spelt Nirvana. So? I did, and they still have 1/10th the complexity and breadth and reach of the Beatles. They're not better musically or lyrically or culturally or production wise or music playing wise (so not in any way). They're just closer to the age familiar to the 90s teens. So you're accusing him of clinging to what he knows from his youth, when you're infact clinging to an inferior standard (Nirvana vs Beatles) just because you know it from your youth. So even this makes the author's argument for him...
  - mellosouls 7y ago
    The Beatles: Firstly, you don't know what I know from my youth. Please argue the point, not your presumption of my personality. He talks about them as the heros of "our generation". They weren't. The musical heros of that generation (in the sense of being the leaders of that time) included the ones I've mentioned. The tone is nostalgic and rockist, as dull and unimaginative as his tone when talking about coding. Every generation reinvents stuff, and adds new inventions of its own. People shouldn't just dismiss new creators as inferior out of some chronological quirk, just because those people were born at a later time, or because low-hanging fruit are gone. It's exactly the same condescending and arrogant tone that consigns all young creative people to being "unlucky" to have been born when they are. Ironically, the Beatles - and the tech wizards of the past never listened to that moaning nonsense either from their own older rose-tinted, time-locked colleagues, they just got on and changed the world.
nickthemagicman 7y ago
I'm totally ok with Standups as long as they're not every day. I like working remote but I also like working in the office a couple days a week to connect with my team members. It's possible that these ideas taken to the extreme are bad but taken in moderation can be great. Open offices...are still the most horrible idea ever.
ykevinator 7y ago
He is 100% right about flow. 8 hours of super quality concentrated high value work with breaks is what everyone wants but no one gets.
robotron 7y ago
"Refactoring" and "technical debt" are just faddish meaningless words? Alright,buddy. From one old programmer to an even older one, you really are just being a grumpy old man.
- coldtea 7y ago
  I guess those idiots in the 70s who built UNIX, who didn't use the terms "refactoring" and "technical debt" were also clueless.
- koonsolo 7y ago
  Fully agree with you (from a 40 yo). I really love the term "technical debt", because it says exactly what it is, and can be communicated properly to management. As long as you have debt, you will keep paying for it until you pay it off. Very clear and precise, love it! Refactoring a bit less, but it is also a very clear term so other people know what you are doing.
loopz 7y ago
People working on laptops like in that picture is unergonomic and unsustainable. Say hello to back- and neckpains. Who pays for that? The text was just a tedious hard-to-follow rant. Flow isn't that special: It's a state of mind when you're engaged in relatively easy logical work, while unsynchronized with other people's work.
- zozbot234 7y ago
  You can synchronize with others' work without breaking flow. In a software dev context, computer-mediated communication and review, proper issue tracking, etc. make this a lot more feasible.
  - loopz 7y ago
    This can be true, though so can collaboration in person also be. Often, time pressures, office politics, culture, etc. get in the way, though can be filtered to some extent through text media, but not without losing some meaning, insights and opportunities. Frankly, modern corporations only appreciate productivity, innovation, creativity and spontaneous combustion, when executed at the dictate of Directors. So whenever you found a sweet spot, know that Change (Winter) is coming.
- buboard 7y ago
  i assume it's a library and not people working. that would be terrible
  - thrower123 7y ago
    No, that's the state of the art these days. You don't even have an assigned desk, you have to battle for prime real estate. Every day.
    - loopz 7y ago
      Only the fittest survive, and no disability checks for the poor.
heidar 7y ago
The good thing about industry standard terms is that it makes it easier for people to work together. As opposed to everyone coming up with their own terms for things. To me that’s one of the big pros about agile.
- thrower123 7y ago
  I'm not sure if it is better to have everyone use different terms for the same things, or for everyone to use the same terms for different things. With Agile, I feel like we are mostly in the second case...
Marazan 7y ago
'Flow' is the faddiest word in Software Development right now. My entire company has managers talking about flow and rearranging time so that Engineers can flow etc. It completely ignores that masses of people do not work effectively that way. In the field of learning people have long realised that sitting down people for a 3 hour session learning doesn't work, it actively inhibits learning. Why is it not the same for applying knowledge.
- donatj 7y ago
  I work in the educational space, and I think, as education is discovering, different strokes for different folks. Different people learn best in different ways. Different people work best in different ways. The problem is one-size-fits-all prescribed solutions, telling people how to be productive. Depending on where a person is in a project, their mood, phase of the moon, etc, they may be more productive collaborative or heads down. It varies by person and time. I think there is room to respect how individuals work best.
buboard 7y ago
Ok boomer! that said I feel the same, having worked solo for 10 years. 99% of the stuff i read about in this forum is about processes, management, code review, packaging, testing, automating deployment. Who is doing the actual building? It used to be that , with software, "processes" are automated leaving you with only the highest-of-the high level entities, the code, which is brief like poetry. Code seems less powerful nowadays, not a tool to create, but hidden under layers and layers of process. I 'm kind of thankful i don't have to work for others ever again, but i m also missing out on SV-level salaries. How much time do people spend writing program rather than checking in and out of various systems?
- hootbootscoot 7y ago
  this. and ultimately, who PAYS for all these deliberate hurdles and the deliberate curtailing of human productivity to serve a tangential dubious (at best) goal?
  - marktangotango 7y ago
    Seems like a proof by existence about the predominance of BS jobs?
- tarsinge 7y ago
  I think these two kinds of environments always cohabited. In the 90's/00's you had enterprise software development (think old school J2EE) which was all about processes (and boilerplate code), with the smallest feature taking months to implement (and usually resulting in an over-engineered outsourced low quality mess). On the other side you had small shops environments like ID Software and startups with a completely different philosophy. My take on the issue is that we have lost the distinction, and now everything is enterprise software development. No matter your size and the scope of your project you must adopt THE enterprise way of developing. The reason is that using the same processes and tech that a FAANG/Unicorn has basically become a requirement in term of signaling, both for companies and developers. Edit: What we miss is that at that size they are (rightfully) solving processes problems. But for startups it's irrelevant (or premature optimization at best). Previously it was simpler: companies with 1000+ developers were not cool.
hootbootscoot 7y ago
...look at all the babylon fans cheering the monster on. how dare a measly lowly human have an opinion after personally suffering at the hands of brainless machinery... the thing is, it takes exactly zero courage or risk to cheer for the status quo. the other thing is, later we often realize that the system was wrong, and the iconoclast was right. where does the true arrogance actually lie?
vsareto 7y ago
Usually the funniest thing about these posts is some kind of implication and surprise that things would have stayed the same across generations
jimws 7y ago
Open space offices is another similar fad that I cannot stand. Who wants to be at the constant risk of being interrupted and be distracted by side-channel chatter! The situation has become so bad that I cannot find many companies I can work for that has not succumbed to this fad. The only workplace that works for me now are the ones where I can work remotely.
- RandomInteger4 7y ago
  Open source offices are a result of companies not willing to train. Everyone wants to hire someone with experience in their tools, and also only hire young people, so what are young people going to do? They're going to teach themselves free tools. EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.
  - ashildr 7y ago
    It seems autocarrot did not only change one word in the beginning your text but fittet the rest of your text to find a new meaning.
    - RandomInteger4 7y ago
      My eyes don't work this early apparently. I completely misread the comment I responded to.
purple_ducks 7y ago
Agreed 100%.
deleted 7y ago
[deleted]
7532yahoogmail 7y ago
I've also been in software for many years. If I wanted to take aim at stupid corporate America (when/where it exists) in software it's pretty easy to be more damning than slashing agile's tire and running away. Btw we should acknowledge that while hw gets cheaper and better, sw has real problems doing the same. A better way to start don rickling software would be to start with the Standish choas report from the 90s.
Nerdfest 7y ago
In my (probably worthless) opinion, the two big problems affecting software industry are: - Organizations, especially large ones, now trust their process over their people. In the "old" days, when a production problem was identified and the prime developer knew what the problem was, it would be fixed, as directly and immediately as possible if there was high confidence. With less than high confidence, maybe a quick test in a test environment is done. In many places, this is now a multi-day, or even multi-week process now. - Developers are not all doing it because they love it anymore. It's a high-ish paying job with lots of hiring being done. Many of the people writing code these days are awful programmers that in the long run cause a lot of damage. Many take away more than they add. In the earlier days, people coded because they wanted to. The second problem is actually a big part of the cause of the first. Perhaps I'm just bitter, but given the abundance of technologies, frameworks, libraries, services, etc, small teams of good coders can put together amazing pieces of work in a very short time. This almost never happens. It seems like complexity of large software projects has exceeded the ability of the current level of general expertise to maintain. It sure seems like we're close to that point. I should add that I don't have the same opinions on most modern techniques. Agile can work very well. Code reviews and unit tests are a must. These are all tools that boost the quality and in the end, save time as well.
deleted 7y ago
[deleted]
RickJWagner 7y ago
I love the look of the house. About the life story, I never cease to be amazed at the level of personal freedom offered by a career in programming. I have friends who move to far away places, take long sabbaticals, etc. What a great thing.
luord 7y ago
While I agree on a couple of things: Primarily how scrum and company are complete bastardization of everything the manifesto stood for and that the tall poppy syndrome against more dedicated developers by pretending they're not "team players" or are "prima donna"s is absolutely ridiculous; that's where my agreement ends. Agile malpractices doesn't mean that writing software with more agility is bad, and I found odd that he derides pair programming but at the same time derides TDD because of the misconception that it means that a second pair of eyes is no longer needed. And, of course, the pretense that the biggest reason MS was successful after it was no longer inside a garage was due mainly to anything other than scummy corporate and monopolistic practices is... Suspect, to say the least. MS, from all appearances, became awful once it was more than ten people, but that's got nothing to do with agile practices.
vaporland 7y ago
yesyesyesyesyes agree 1,000,000%
prothinker 7y ago
it will be very helpful for everyone! thanks for sharing informative https://vyaparapp.in/gst-accounting-pc https://vyaparapp.in/gst-accounting-pc
prothinker 7y ago
Use this software and pay your taxes by using this software by visiting https://vyaparapp.in/online-gst-Invoice-software-free https://vyaparapp.in/online-gst-Invoice-software-free

84 points by gballan 7y ago

tgv 7y ago

Bit rambling, but it boils down to a critique of fad-driven management: we have do TDD, Agile, whatever, but --from the developer's point of view-- more as an end than a means.

jasonvorhe 7y ago

I can't believe what I'm reading. > By 2009 things were in disarray; the love of quality had completely given way to a mechanical process of checking boxes and several times I landed in hot water for being too thorough. He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. Then he continues that he was close to leaving the company because they started to apply Test Driven Development. Of course he's also not a fan of agile and he has a strong dislike for user stories while user scenarios is perfectly fine a term for him. Of course he's also not fond of team work, especially if you use a term for that he doesn't like. I can imagine him going into the office and telling young software engineers who approach him to get off his lawn. People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves and their judging attitude towards new approaches and terms is so last century.

zozbot234 7y ago
> ...People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves .... Large-scale software projects were definitely around in the 1980s and 1990s including at M$, so it can't be that. The thing about "teamwork", recurring meetings/standups and other drains on 'flow' and individual productivity, is that they are a cost of your chosen development model. They're things you're supposed to minimize wherever feasible by improving your toolset (e.g. good repository management, CI, static analysis tools to cut down on pointless "unit" testing, computer-mediated communication as opposed to doing everything in person, etc.), not expand until they take up all available resources.
peteforde 7y ago
Just to be clear: in a not-so-distant future, some little shit is going to be describing why people like you aren't going to be missed, so be kind. He actually makes some excellent points around challenging fad-driven-management, open office spaces, dorm culture instead of prioritizing flow, and what I see as a legitimate perspective on TDD's unfortunate tendency to reinforce blindspots. It's just a shame that he also sounds a bit like Hunter Thompson, shooting at cars passing too close to his compound. For the record, one thing he's absolutely correct about is this idea that being able to handle all aspects and dimensions of a complex project is somehow arrogant and/or anti-social and/or dinosaur-esque. I mean, I don't know anything about you but people who can competently build impressive shit solo command my respect. Your disbelief that such a thing can be extraordinarily valuable is just projecting a lack of confidence or imagination. To be clear: not everyone will (or should) go there... but it's your prejudiced rejection of the possibility as gauche that pets me backwards. You are not the first or only generation to have everything all figured out.
- poisonborz 7y ago
  Solo warriors are not that unique, just look at most of the successful one-man free software projects. Thing is, you can't expect them to turn up in your team. These "fad" processes help to cultivate their oversight in a reproducible, proveable manner. Also, processes are a toolbox, and managers can be good or bad. This does not deduct from the value of the processes.
- traderjane 7y ago
  Csikszentmihalyi is not respected by professionals of his field (there is no enthusiasm to followup on Flow). Of course Flow was also cargo cult executive catnip back in the day -- I suppose Mr. Fox's day.
donatj 7y ago
> He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. What are you talking about? Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period. I dislike the agile terminology because it’s so condescending. Your users have “stories”, it implies they’re fictional and not to be taken seriously. It’s dehumanizing.
- kthejoker2 7y ago
  Really? Stories can't be nonfiction? I don't see that implication at all. Ever hear the story of Albert Einstein on the train? Galileo's trial? The sinking of the Titanic? Anyway, other reasons to like it being called a story * Stories require two people, a teller and a listener. * Stories have an ending. * Stories are relatable to people who otherwise might not know they care about your product * The user is the hero of the story (i.e. the developer is the opposite of condescending by putting others first)
- mcbits 7y ago
  > Windows 95, 98, 2000 and XP were all best in class I know some OS/2 fans who wouldn't go along with that, but I will. They were best in a class that was inundated with crippling bugs and vulnerabilities. Can we credit checklists and pair programming for the fact that it's now possible to connect to the Internet without joining a botnet within 5 minutes? Or save a file without worrying whether it will make it to disk before the next BSOD? Probably not directly, but procedures and conventions definitely needed to change.
- koonsolo 7y ago
  > Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period. Haha, great joke. Oh wait you are serious? The amazing blue screens made me switch to Linux in that period. And if you knew about the state of Linux back then, that says something about this "best in class"
  - donatj 7y ago
    I ran RedHat and then Slackware for a time back then. For desktop purposes they were barely usable.
hootbootscoot 7y ago
again, the shameless trotting out of tropes like "arrogant" etc, which is precisely what the author rather cogently and concisely accused the industry of. You are merely proving the authors point, IMHO. (I added the H, happy? I'm a team player, you soulcrusher.)
coldtea 7y ago
>He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s. Err, some of the best products of MS was from that era -- 80s and early-mid 90s. The rest is downhill.
buboard 7y ago
> Microsoft in a time where they didn't deliver any quality product at all. windows 2007 is my favourite windows version probably ever.
deleted 7y ago
[deleted]
7532yahoogmail 7y ago
Agree - I've used the Balmer decade as my own slam time to time ...
crustycoder 7y ago
> People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves and their judging attitude towards new approaches and terms is so last century. The arrogance of believing that your "new" approaches are actually groundbreaking is the issue. He's saying that rigid prescriptive approaches that value the latest fad over the end result end up with poorer quality software that takes even longer to deliver. I've been cutting code even longer than he has, since 1983, and when you've been doing it that long, you see the same "Groundbreaking New Idea" reappearing around every 5-10 years - old stuff, new name and a fresh bunch of acolytes who believe they've found The One True Path. The issue is not the ideas, it's the fanaticism that so often accompanies them. Writing tests early? Yeah, we've done that for ages, particularly for gnarly bits of code. Pair Programming? Yeah, us engineers have always huddled together around code. CI? Yeah, I worked on an enterprise-level OS that ran its development infrastructure on the previous night's build, so if you "broke the gate" you had a couple of hundred engineers on your case. After a decade as a tech lead I'm now back at the codeface in an entirely different technology area, using "Agile", "Kanban", yadayadayada. Many of my coworkers are young enough to be my kids but we get on just fine - they treat The Old Fart gently and I'm (usually) polite enough not to giggle too much at the terminology - the article's comment about "Technical Debt" gave me a good chuckle. What we have in common is engineering pragmatism - if there's something new we'll take a look. If it works for us, we'll keep it, if not we won't. If we have deadlines to meet, yeah, we may have to make some compromises. If Software Engineering is ever to deserve the "Engineering" term it has to learn to behave like other engineering disciplines and begin to embrace evolution based on hard-won experience rather than the current widespread out-of-hand rejection of the past.
FredRys 7y ago
He is spot on. Not that everything is worse today. There are things that are a lot better these days. But this all goes in cycles. Human progress is not a continually improving thing. In many areas we sometimes go backwards for a while before it reverses again. One major driver for this is closemindedness. Rejecting the past without even considering its validity. In a little over twenty years from now just look around for that twenty year old programmer, not even born yet, who will be leading a new generation of programmers who will be mocking you as that "Get off my lawn guy" with the old fashioned obsolete old school ways. They will be pushing what they think are brand new ideas but are actually a variation of the 1980's and 1990's. But in the long run this constant turnover of fads does result in a solid body of knowledge of what works and what does not work. For instance a continuous recorded history of Chinese Cooking over the last 5000 years is an invaluable resource for exploration and inspiration for new ideas.
koonsolo 7y ago
> People like him aren't going to be missed. Meanwhile, there are other 40+ programmers like myself who still enjoy themselves with the latest tech, fads, open offices, lots of communication and fellow young programmers. Programming nowadays has improved so much it's crazy. - Have a problem? 99% chance your answer is on StackOverflow. (anyone remember the days before internet? I do! Searching (alone) hours on some cryptic error message) - Programming robots is so easy and cheap nowadays. - Everyone walks around with a super powerful computer, integrated GPU, camera, GPS, gyroscope and internet ready wherever you go. - So much powerful stuff available for free. - Current IDE's have so much handy functionality. - Make your software available to the world in an instant. Want to run your own server software? So easy and cheap! So yeah, grumpy old programmers still exist. But I also know plenty of old programmers who love all the new stuff.

lovetocode 7y ago

There is only only one appropriate response to this: “Ok Boomer” The only part I can agree with is that developers need periods of uninterrupted time everything else just comes off as an old man telling kids to get off his lawn. It took much longer to iterate on software in the 80s and 90s than it does now. And that is supposed to be a good thing? Agile has made the software development process much easier by reducing the feedback loop and taking a lot of the guesswork out of development. Daily stand ups may seem dumb to you but that’s because you refuse to get any value out of it. You can’t really say it’s over communication because it is supposed to be limited to 15 minutes. You should also know what your partners are working on because sometimes you both might be working on components that impact one another.

megous 7y ago
What I took from the article is that he disliked the "morning standup" because it forced him through a rush hour traffic, compared to previous situation.
- ashildr 7y ago
  I made good experiences with moving the standup to a later hour for similar reasons. Sticking to an early standup if that means that team members are stuck in traffic - or not awake - is exactly _not_ agile.
  - thrower123 7y ago
    Better to just do the "standup" asynchronously in a groupchat if it is going to be a useless status check, as they usually are.
  - SuoDuanDao 7y ago
    Sounds like the early morning standups are for the manager's convenience more than the coder's, which might be the underlying trend driving OP's complaints.

deleted 7y ago

[deleted]

moonbug 7y ago

old man rants at Cloud.

kilburn 7y ago

What's up with the pair programming hate? I think it is great in the correct situations and would love to do more of it! 1. Get paired with another dev of similar level to work on new stuff. Bouncing ideas makes the surfacing solutions better. 2. Get paired with a dev that has been working on some system for a while. This is a much quicker way to learn the what's and why's of a project.

thrower123 7y ago
Because it is awful for people who don't enjoy social interaction, and get quickly worn out by it. Which encompasses a much larger share of programmers than the general public. Everything in modern faddish programming seems to be aimed squarely at stressing out and destroying the effectiveness of introverts.
- cameronfraser 7y ago
  Pair programming isn't intended to be an all the time thing. A great example of pair programming is a new person gets hired and you pair program with them on a ticket so they can ask questions along the way. Having recently joined a remote startup I found this to be pretty essential to getting anything done. It's a great way of elevating programming level as well. You see different ways of doing things, different tools they use, etc. Introverts are also not being targeted in any way. People who have been at this a while are just very aware that you can get far more accomplished with a team that works well together than an individual developer can. You can be an introvert and still an effective team member. Nobody is fully introverted or fully extroverted.
michaelbuckbee 7y ago
Like everything the author listed it's about execution and applying the right tools to the right job. Some places _only_ do pair programming, some places go so wild with their unit tests that it becomes incredibly unwieldy, and lots of times different approaches get cargo culted from organizations where it made sense (we're a 10,000 member team writing a new OS) to a one where it doesn't (we're 2 people making a CRUD app side-project that got a little traction).

x3ro 7y ago

I do understand the criticism of open plan offices and the resulting interruptions, I do myself prefer a closed office. And I definitely haven't been around as long as this person. That being said, it feels like this person is just upset that they're not "at the top" anymore. Quote: It was great back then; we were treated like princes [...]

nmyk 7y ago

> I decided to pack up and go, and left the USA on 11/15/2010, intending to retire at 56, play my guitars, read my physics library, live my life in very strange language and relax. This is someone who prefers solitude. It's not surprising that he doesn't like collaborative work. He seems to be projecting his own preference onto the software industry though, which is misguided. Lots of great software has been built with all kinds of different workflows.

zozbot234 7y ago
>> ... play my guitars ... Nah, he's just a literal rockstar programmer. You've got to give him that.
- hootbootscoot 7y ago
  way to cheer for babylon, my future grumpy old fart in waiting...
7532yahoogmail 7y ago
Agree.

ddek 7y ago

You know every week there’s an article here about some self-proclaimed ‘genius’, who’s undocumented, untested, unchallenged work is so critical the team that they can’t possibly fire him. Then they do, and quickly realise they’re better off? It’s not that this feels like it was written by one of those guys - this categorically was written by one of those guys. It’s a damn good thing he’s out our ecosystem, and if he has to preach his incompetence at least he’s not infecting a relevant part of the world.

dang 7y ago
Personal attacks are not ok. We ban accounts that post them. Maybe you don't owe the person better, but you definitely owe this community better if you're posting here. Would you mind read the site guidelines and taking the intended spirit to heart? We'd appreciate it. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ashildr 7y ago

Old man rants at agile. (though I’d agree that many implementations of agile methods are cargo cult and give it a bad name.)

chrismmay 7y ago

I hope younger devs keep in mind that one day you will be the "old" one.

joshwarwick15 7y ago

B O R I N G

marcus_holmes 7y ago

I've worked in both environments (I too was coding in the 90's). It was definitely easier in the 90's - less complexity, more freedom to do your own stuff. Project management was less hands-on, and more concerned with reporting up than managing down. But I like it now. I like that the teamwork matters, and the morning standups are great (good to know what your colleagues are working on, and be able to work out if you need to collaborate with them on stuff you're both touching). I like pair programming on the tricky bits (and being able to admit that some bits are tricky and ask for help without being sneered at). Programmers used to be treated as weird, eccentric geniuses that you had to handle with care and needed special work environments to thrive in. Now we're just people, and get treated like normal people. I understand how that won't suit some, because they enjoyed being treated differently ("like princes" I guess... but more like princesses because we were effectively locked in a tower). And as we get older, our tolerance for change decreases. It takes effort to avoid becoming a grumpy old fart, complaining at everything that has changed. But the effort is worth it.

giancarlostoro 7y ago
> And as we get older, our tolerance for change decreases. It takes effort to avoid becoming a grumpy old fart, complaining at everything that has changed. But the effort is worth it. Just the other day a Senior was telling me about one job he went back to where they were bought out. The new people wanted to introduce process into how they work and since most of the devs complained that whole team was let go. The sad part was he didnt care what he had to do to work. He just wanted to work. So the majority opinion he didnt agree with got him screwed over. If you are going to assume a whole team is rotten please dont. Interview them independently.
hootbootscoot 7y ago
.... and there you go proving the authors point about derision and subtle sneers aimed at what is arguably the most effective means of getting focused highly productive developers: treating them like HUMANS, instead of faceless cogs, and allowing for focused programming time without distractions. "old farts" rock, my friend. I get that some folks enjoy molding young minds to sick patterns, free of pushback, but ultimately I will contend that it's it's counterproductive to ones true goals. (unless ones true goals are merely to crush human egos and souls...)

purplezooey 7y ago

"The PMs were worse, putting on a perky, chirpy and cheerful show of sounding “engaged,” when in reality I knew they spent most of their day playing games..." Ayup....

deleted 7y ago
[deleted]

wayoutthere 7y ago

I think a lot of this is just a product of the amount of complexity software is expected to manage. No single person can keep it all in their head with all the constantly changing parts. This has followed the shift of oftware development from a capital investment to more of an operational one. The job profile of operational work doesn't fit neatly within the solo developer / deep flow paradigm. Sure, that might be necessary for some dev jobs, but most dev jobs are more figuring out what needs to be built than actually building it. And for better or worse (usually worse for those of us on the spectrum), every job seems headed in this direction.

zozbot234 7y ago
> the amount of complexity software is expected to manage. How much of that is incidental complexity, though? What happened to refactoring and paying down technical debt - weren't these supposed to be tenets of Agile?
- wayoutthere 7y ago
  The best way to think of Agile is "bare minimum project management for the sake of product management". You can get wrapped up in the rituals and "best practices" but at the end of the day, it's usually about delivering software in a way that makes it easy to buy and sell. It's easier to sell software when you can pull a feature on a roadmap up to land a big account than it is to refactor and cut a custom release for them. It's easier to buy software when you know it's constantly improving. Software also does more and integrates with more than it ever has. This is driven by customer requirements, which are pretty much non-negotiable.
  - zozbot234 7y ago
    > It's easier to sell software when you can pull a feature on a roadmap up to land a big account It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Which you'll need to pay down in some way, if you want your software to be "constantly improving". If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.

mellosouls 7y ago

Unfortunately some decent points are somewhat obscured by the condescending and nostalgic tone that hits you in the first line: Many too young to have ever seen the halcyon days of software development... Every generation has blinkered old guys talking in that way, who can safely be ignored. There has never been a more exciting time to code, especially away from the corporate treadmill. I particularly lost patience when he started talking about the Beatles (and I love the Beatles). Mate, if you came of musical age in the early nineties it's spelt Nirvana. Or Wu Tang. Whatever, he sounds like he was always looking back.

coldtea 7y ago
>Every generation has blinkered old guys talking in that way, who can safely be ignored. Can they? Here we are in 2019 and we're reinventing (usually in worse shape) everything people already had in the 70s, 80s, 90s, even the 60s (Go is closer to Algol than to a 2019 language, our IDEs are worse than LISP machines or Smalltalk environments). We all use UNIX (a 70s technology), OS X/iOS (a variation on a 80s microkernel + BSD), and Windows (a 30+ year old OS design, from a prominent 70s/80s OS designer). We reinvented techniques used 40+ years ago in mainframes as containers. Our UI tech of choice is the DOM... >Mate, if you came of musical age in the early nineties it's spelt Nirvana. So? I did, and they still have 1/10th the complexity and breadth and reach of the Beatles. They're not better musically or lyrically or culturally or production wise or music playing wise (so not in any way). They're just closer to the age familiar to the 90s teens. So you're accusing him of clinging to what he knows from his youth, when you're infact clinging to an inferior standard (Nirvana vs Beatles) just because you know it from your youth. So even this makes the author's argument for him...
- mellosouls 7y ago
  The Beatles: Firstly, you don't know what I know from my youth. Please argue the point, not your presumption of my personality. He talks about them as the heros of "our generation". They weren't. The musical heros of that generation (in the sense of being the leaders of that time) included the ones I've mentioned. The tone is nostalgic and rockist, as dull and unimaginative as his tone when talking about coding. Every generation reinvents stuff, and adds new inventions of its own. People shouldn't just dismiss new creators as inferior out of some chronological quirk, just because those people were born at a later time, or because low-hanging fruit are gone. It's exactly the same condescending and arrogant tone that consigns all young creative people to being "unlucky" to have been born when they are. Ironically, the Beatles - and the tech wizards of the past never listened to that moaning nonsense either from their own older rose-tinted, time-locked colleagues, they just got on and changed the world.

nickthemagicman 7y ago

I'm totally ok with Standups as long as they're not every day. I like working remote but I also like working in the office a couple days a week to connect with my team members. It's possible that these ideas taken to the extreme are bad but taken in moderation can be great. Open offices...are still the most horrible idea ever.

ykevinator 7y ago

He is 100% right about flow. 8 hours of super quality concentrated high value work with breaks is what everyone wants but no one gets.

robotron 7y ago

"Refactoring" and "technical debt" are just faddish meaningless words? Alright,buddy. From one old programmer to an even older one, you really are just being a grumpy old man.

coldtea 7y ago
I guess those idiots in the 70s who built UNIX, who didn't use the terms "refactoring" and "technical debt" were also clueless.
koonsolo 7y ago
Fully agree with you (from a 40 yo). I really love the term "technical debt", because it says exactly what it is, and can be communicated properly to management. As long as you have debt, you will keep paying for it until you pay it off. Very clear and precise, love it! Refactoring a bit less, but it is also a very clear term so other people know what you are doing.

loopz 7y ago

People working on laptops like in that picture is unergonomic and unsustainable. Say hello to back- and neckpains. Who pays for that? The text was just a tedious hard-to-follow rant. Flow isn't that special: It's a state of mind when you're engaged in relatively easy logical work, while unsynchronized with other people's work.

zozbot234 7y ago
You can synchronize with others' work without breaking flow. In a software dev context, computer-mediated communication and review, proper issue tracking, etc. make this a lot more feasible.
- loopz 7y ago
  This can be true, though so can collaboration in person also be. Often, time pressures, office politics, culture, etc. get in the way, though can be filtered to some extent through text media, but not without losing some meaning, insights and opportunities. Frankly, modern corporations only appreciate productivity, innovation, creativity and spontaneous combustion, when executed at the dictate of Directors. So whenever you found a sweet spot, know that Change (Winter) is coming.
buboard 7y ago
i assume it's a library and not people working. that would be terrible
- thrower123 7y ago
  No, that's the state of the art these days. You don't even have an assigned desk, you have to battle for prime real estate. Every day.
  - loopz 7y ago
    Only the fittest survive, and no disability checks for the poor.

heidar 7y ago

The good thing about industry standard terms is that it makes it easier for people to work together. As opposed to everyone coming up with their own terms for things. To me that’s one of the big pros about agile.

thrower123 7y ago
I'm not sure if it is better to have everyone use different terms for the same things, or for everyone to use the same terms for different things. With Agile, I feel like we are mostly in the second case...

Marazan 7y ago

'Flow' is the faddiest word in Software Development right now. My entire company has managers talking about flow and rearranging time so that Engineers can flow etc. It completely ignores that masses of people do not work effectively that way. In the field of learning people have long realised that sitting down people for a 3 hour session learning doesn't work, it actively inhibits learning. Why is it not the same for applying knowledge.

donatj 7y ago
I work in the educational space, and I think, as education is discovering, different strokes for different folks. Different people learn best in different ways. Different people work best in different ways. The problem is one-size-fits-all prescribed solutions, telling people how to be productive. Depending on where a person is in a project, their mood, phase of the moon, etc, they may be more productive collaborative or heads down. It varies by person and time. I think there is room to respect how individuals work best.

buboard 7y ago

Ok boomer! that said I feel the same, having worked solo for 10 years. 99% of the stuff i read about in this forum is about processes, management, code review, packaging, testing, automating deployment. Who is doing the actual building? It used to be that , with software, "processes" are automated leaving you with only the highest-of-the high level entities, the code, which is brief like poetry. Code seems less powerful nowadays, not a tool to create, but hidden under layers and layers of process. I 'm kind of thankful i don't have to work for others ever again, but i m also missing out on SV-level salaries. How much time do people spend writing program rather than checking in and out of various systems?

hootbootscoot 7y ago
this. and ultimately, who PAYS for all these deliberate hurdles and the deliberate curtailing of human productivity to serve a tangential dubious (at best) goal?
- marktangotango 7y ago
  Seems like a proof by existence about the predominance of BS jobs?
tarsinge 7y ago
I think these two kinds of environments always cohabited. In the 90's/00's you had enterprise software development (think old school J2EE) which was all about processes (and boilerplate code), with the smallest feature taking months to implement (and usually resulting in an over-engineered outsourced low quality mess). On the other side you had small shops environments like ID Software and startups with a completely different philosophy. My take on the issue is that we have lost the distinction, and now everything is enterprise software development. No matter your size and the scope of your project you must adopt THE enterprise way of developing. The reason is that using the same processes and tech that a FAANG/Unicorn has basically become a requirement in term of signaling, both for companies and developers. Edit: What we miss is that at that size they are (rightfully) solving processes problems. But for startups it's irrelevant (or premature optimization at best). Previously it was simpler: companies with 1000+ developers were not cool.

hootbootscoot 7y ago

...look at all the babylon fans cheering the monster on. how dare a measly lowly human have an opinion after personally suffering at the hands of brainless machinery... the thing is, it takes exactly zero courage or risk to cheer for the status quo. the other thing is, later we often realize that the system was wrong, and the iconoclast was right. where does the true arrogance actually lie?

vsareto 7y ago

Usually the funniest thing about these posts is some kind of implication and surprise that things would have stayed the same across generations

jimws 7y ago

Open space offices is another similar fad that I cannot stand. Who wants to be at the constant risk of being interrupted and be distracted by side-channel chatter! The situation has become so bad that I cannot find many companies I can work for that has not succumbed to this fad. The only workplace that works for me now are the ones where I can work remotely.

RandomInteger4 7y ago
Open source offices are a result of companies not willing to train. Everyone wants to hire someone with experience in their tools, and also only hire young people, so what are young people going to do? They're going to teach themselves free tools. EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.
- ashildr 7y ago
  It seems autocarrot did not only change one word in the beginning your text but fittet the rest of your text to find a new meaning.
  - RandomInteger4 7y ago
    My eyes don't work this early apparently. I completely misread the comment I responded to.

purple_ducks 7y ago

Agreed 100%.

deleted 7y ago

[deleted]

7532yahoogmail 7y ago

I've also been in software for many years. If I wanted to take aim at stupid corporate America (when/where it exists) in software it's pretty easy to be more damning than slashing agile's tire and running away. Btw we should acknowledge that while hw gets cheaper and better, sw has real problems doing the same. A better way to start don rickling software would be to start with the Standish choas report from the 90s.

Nerdfest 7y ago

In my (probably worthless) opinion, the two big problems affecting software industry are: - Organizations, especially large ones, now trust their process over their people. In the "old" days, when a production problem was identified and the prime developer knew what the problem was, it would be fixed, as directly and immediately as possible if there was high confidence. With less than high confidence, maybe a quick test in a test environment is done. In many places, this is now a multi-day, or even multi-week process now. - Developers are not all doing it because they love it anymore. It's a high-ish paying job with lots of hiring being done. Many of the people writing code these days are awful programmers that in the long run cause a lot of damage. Many take away more than they add. In the earlier days, people coded because they wanted to. The second problem is actually a big part of the cause of the first. Perhaps I'm just bitter, but given the abundance of technologies, frameworks, libraries, services, etc, small teams of good coders can put together amazing pieces of work in a very short time. This almost never happens. It seems like complexity of large software projects has exceeded the ability of the current level of general expertise to maintain. It sure seems like we're close to that point. I should add that I don't have the same opinions on most modern techniques. Agile can work very well. Code reviews and unit tests are a must. These are all tools that boost the quality and in the end, save time as well.

deleted 7y ago

[deleted]

RickJWagner 7y ago

I love the look of the house. About the life story, I never cease to be amazed at the level of personal freedom offered by a career in programming. I have friends who move to far away places, take long sabbaticals, etc. What a great thing.

luord 7y ago

While I agree on a couple of things: Primarily how scrum and company are complete bastardization of everything the manifesto stood for and that the tall poppy syndrome against more dedicated developers by pretending they're not "team players" or are "prima donna"s is absolutely ridiculous; that's where my agreement ends. Agile malpractices doesn't mean that writing software with more agility is bad, and I found odd that he derides pair programming but at the same time derides TDD because of the misconception that it means that a second pair of eyes is no longer needed. And, of course, the pretense that the biggest reason MS was successful after it was no longer inside a garage was due mainly to anything other than scummy corporate and monopolistic practices is... Suspect, to say the least. MS, from all appearances, became awful once it was more than ten people, but that's got nothing to do with agile practices.

vaporland 7y ago

yesyesyesyesyes agree 1,000,000%

prothinker 7y ago

it will be very helpful for everyone! thanks for sharing informative https://vyaparapp.in/gst-accounting-pc https://vyaparapp.in/gst-accounting-pc

prothinker 7y ago

Use this software and pay your taxes by using this software by visiting https://vyaparapp.in/online-gst-Invoice-software-free https://vyaparapp.in/online-gst-Invoice-software-free