14 ms·

Anti-patterns and malpractices in modern software development (2015)

232 points by barry-cotter 7y ago

hootbootscoot 7y ago
*of :D
dang 7y ago
Discussed at the time: https://news.ycombinator.com/item?id=12778824 https://news.ycombinator.com/item?id=12778824 a bit more: https://news.ycombinator.com/item?id=13270271 https://news.ycombinator.com/item?id=13270271
PavlovsCat 7y ago
archive of the wayback machine archive, just in case: http://archive.is/hxEU9 http://archive.is/hxEU9
petermcneeley 7y ago
"I suspect that most discrimination that happens against older programmers is not, in fact, age discrimination, but is, in fact, ‘wisdom discrimination’."
- shantly 7y ago
  As long as hiring and technology decisions remain largely hype-driven, having someone around who says "we don't need k8s, hadoop, machine learning, and AWS with some big-ass Terraform-driven constellation of supporting serices for our expected data, workload, and use case; look, give me one middle-weight server, or one heavyish VM somewhere, and I can show you how to do all this with awk, sed, cron, and maybe a few lines of Perl or Python. We can have it up fast and anyone who can read man pages and a README can admin it, and anyway it's so simple and the workload static enough that once some initial kinks are worked out it'd probably run in a closet without issue for so long you'd forget it was in there—so, longer than this project is likely to be alive, anyway" isn't really something you want unless you plan to ignore them. For their fellow developers, that's résumé poison, you need "real world" experience with all this crap for the next job hunt. For the product manager, owner, and sales, you can't baffle stakeholders or investors or prospects with fancy bullshit when there isn't any fancy bullshit.
  - ironmagma 7y ago
    It’s always fascinating to me how people can get to this point where they eschew new technologies just because there is an older way that works fine. Yes, having a tried and true pipeline is important, but it shouldn’t be surprising that companies are made of people who want their company to push the envelope to further evolve the systems. Someone was the first person to use Python for a production project, and that evolution has to happen somewhere, with real applications to test them.
    - NicoJuicy 7y ago
      Well, the "older tech" is ridiculously cheaper.
      - shantly 7y ago
        I work mostly in the "webshit" and mobile industry. The last time, in a work context, that I saw a site (in this case, from a vendor) and went "goddamn, for what it's doing, that is fast, this is really nice to use!" it turns out it was... PHP running on some normal-ass single instance VM or server somewhere, serving mostly just HTML.
        ironmagma 7y ago
        It's really a spectacular outlier how well-optimized PHP is contrasted to how poorly designed the actual language is.
        ncmncm 7y ago
        Thank Facebook for that. Likely, more specifically, Andrei Alexandrescu.
      - ironmagma 7y ago
        Not universally, no. For instance, C programmers are harder to find than Python coders, and the farther back you go the harder it is to find good people (COBOL, Fortran). The newer the tech, the more people there are riding in on the hype train to choose from.
29athrowaway 7y ago
History of computer programming: - Having an accumulator (abacus) - Accumulator with operations (calculator) - Multiple registers with more complex operations (early computers with plugboards) - Stored program computer (abstraction over the plugboards) - Imperative programming (simple abstraction over operations + registers) - Procedures, Functions, Structures - OOP, functional programming, and beyond. Why do we keep making layers of abstraction? reusability. We want abstractions that reduce effort by making code reusable. But abstractions are only a tool, using the tool correctly is on the programmer. Code is written once, read many times. Languages that focus on "easy to write" are a trap. Languages that focus on "easy to reuse" are what you want.
- profalseidol 7y ago
  > Languages that focus on "easy to write" are a trap Reminds me of that time when my company abused Scala Implicits, possible because one of it's libraries for mapping scala to relational database had examples of it. --- Regarding re-usability. Does that imply well defined interfaces and private scopes? Does that eventually lead us to Pure functions? Afaik, pure func has maybe the highest ease/simplicity for reuse. Happy to be hear your thoughts.
- gimboland 7y ago
  Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well-defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.
  - zo1 7y ago
    I highly agree with this. It's almost a necessity these days with a major push to hire "junior" developers at a discounted rate. By doing those lower abstraction layers, you allow them to write the necessary high-volume business code while reducing their ability to do something subtly stupid for the business/data. Usually this involves abstracting away a lot of the database transaction-type stuff. And on a side note: Never let juniors anywhere near the database design without supervision by the team/seniors. They won't learn anything that way, and they will inevitably make a mess.
ummonk 7y ago
>Some propose that the phenomenon of easy credit and low-interest rates make it economically nonviable for a company to act in its longer-term interests. Wouldn't it be the other way around? High interest rates would increase the discount rate for future value?
- lazulicurio 7y ago
  I think the idea is that low-interest rates cause investors to push companies to adopt riskier behavior and that easy credit enables said riskier behavior.
purplezooey 7y ago
There is so much truth in this article I nearly fell off my chair. Especially #2 and #3.
- shantly 7y ago
  > Oh sure, you can solve the endless little meaningless problems that plague the day-to-day life of programmers everywhere, but the source of these problems — defects at the engineering level — are effectively untouchable. Also untouchable are the systemic issues that cause each of these should-be-trivial-to-fix problems into 5–8 hour tasks. That part of #4 is so true it hurts. Most of the software I use is full of brokenness and "WTF"s. About a year ago: AWS Lamba supports Java. Sweet, should be easy. Oh but the command line tools are broken in several ways you won't discover until you try, find they're broken, google around for a while trying to figure out what's wrong, then realize it's not your fault when you find the relevant unfixed issues. About three years ago: Well I'm writing an Android app so this Google Maps feature should be a piece of cake, I mean, Google makes the OS so surely Maps is amazing on here. Except. Wait. No. That cannot be right. It can't. The Android maps SDK is missing features that the Javascript version has? No. That doesn't make any sense. Oh. Here's a GH repo someone already made to provide a convenient interface from Android Java to the Javascript maps SDK for this exact reason. I mean I guess I don't have to write it myself now but seriously, this was a fucking waste of half my day for no good reason. A few days ago: Debian installer is flat-out incapable of writing Grub correctly. Several tries, every reasonable combo possible, boot fails with missing OS every time. This ain't my first damn rodeo—something's wrong. Think it's maybe a UEFI issue. Force UEFI. Now my video card doesn't work. Because it's not UEFI compatible? Why dafuq is that even a thing? Open case, reset bios so I have a display again, install again just to be safe, boot to installer's recovery mode, mount, chroot, install grub manually and in precisely the way I'd told the installer to do it the first time, and without changing a damn thing about the config the installer had just written, and it's fine. This is basically how everything goes every time I try to do anything with software at all. Which is my job. So this is my life. Software is terrible. [EDIT] in fact I can think of one area where my tools are consistently as shitty, broken, and unsuitable for their intended purpose as software usually is: it's when I cheap out on power or (especially) hand tools to try to save a buck.
mindvirus 7y ago
I think as a profession we've been bad at quantifying and communicating the value of clean infrastructure and good development practices to the business. Why should they pay you to make things "nicer"? One of your big customers is threatening to churn if you don't deliver this new feature! To them, it sounds like you are asking them for a ton of money for better feng shui - pseudoscience with unclear benefits - when they can directly see the benefit of delivering features to the customers. Instead, I think we need to learn how to measure and quantify the value of a good codebase and good practices, and communicate that to the business. Google's error budgets are a step in the right direction here, but I think there's a lot more that can be done.
- crdoconnor 7y ago
  Definitely. Developing a unit of account is key to solving this problem. The problem was never that businesses didn't "get" technical debt, the problem is that they could only measure it by the volume of developers' whining.
- sopooneo 7y ago
  I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost multiplier" for every requested feature. So far, no one has the like the idea or phrase. I can't really blame them. But there must be some quantity or term, with a nice memorable ring to it, that could get this across and at least let business people make decisions with full information at hand. Granted, any such numbers delivered in that guise would be wild guesses. But still, better than nothing. Edit: However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully.
  - m_mueller 7y ago
    How can story points be used for that? To me that's only relevant in the short term. Can management be made to understand that velocity can be too high? Edit: Expanding with my previous thoughts on this - as a software architect I've explained my role to management by saying it's like I work in an agile team, but the waterfall is in my head - someone needs to keep the architecture together and drive it towards green pastures where it keeps great flexibility for developing future anticipated features without giving up stability.
darepublic 7y ago
this problem is about as intractable to me as why I don't eat healthier. Maybe one day I will achieve one or both.
albertTJames 7y ago
This feels borderline sociopathic.. working in team is hard and demand compromise, and yes, although necessary no political system is perfect. But the work conditions of a software engineer are way better than any other job I have done.
itsmejeff 7y ago
The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don’t complain about business constraints and they put out stellar work. “business people” most often do understand what makes the money flow through their company (and into engineers’ bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don’t understand the technical details of an engineer’s work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It’s not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business. (fwiw I’m a director-level engineer so I’m technical but bordering on being a “business person”)
- xaybey 7y ago
  Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.
  - Hackbraten 7y ago
    Depends. To > clearly articulate trade offs to stakeholders may be the constructive cousin of complaining.
  - stiray 7y ago
    ... and is quite a funny statement. If "our" engineers dont "complain", then someone is not listening. Or you have really bad company culture / recruiting / engineering. The DUTY of engineer is to complain to bussiness decisions as they are quite frequent orthagonal to what does make sense to do and in which order. Make sockets as first priority and then write tcp stack as "unneeded"/postponed is quite frequent from a bussiness standpoint. Not complaining about situations like this is just hurting the bussiness.
    - yibg 7y ago
yibg 7y ago
Is it just me or does this article read as basically “everyone else is an idiot, executives (1), managers (2, 8), architects (3) and other developers (5, 6, 7) and only I can see the future and know what needs to be done.”
- 7777fps 7y ago
  The author also equates "late nights" with hard work in point (2) which is a dangerous malpractice in itself.
- vorpalhex 7y ago
  The article reads to me as "I didn't get my way and our code isn't perfect, therefore it's everyone's fault but mine and if only we'd embraced X, this would have all been avoided."
- pdimitar 7y ago
  Pretty dismissive take. The author presents a vision on how engineering can be more effective and protests against micro-management that gives them zero room for creativity and being able to put their best work.
interblag 7y ago
5sts
galaxyLogic 7y ago
The so-called "Business People" are people who's main goal is to make money. And if you think about it that really means their main goal is is to make money for themselves. Techies' in contrast are more concerned about building great products. This naturally creates some tension between techies and the business-people. What should be the division of labor, and rewards?
tomohawk 7y ago
What a bunch of huey. I've consulted on government programs with massive amounts of money and easy to meet deadlines, and the resulting software systems were still crap. Why? Because yagni (you aint gonna need it) went right out the window and they ended up creating the most resume padding, shiny rock encrusted POS ever.
agentultra 7y ago
I don't recall ever having worked on a large code base with a team of developers where everyone was 100% happy with it. Developers complain about everything. It's never good enough and never will be. I believe this is related to our brains being hard-wired to prioritize negative phenomenon and stimuli. Most of those projects shipped and were successful. Users did like using them. However the developers often only saw the bug reports and the endless requests for new features. They never got a chance to talk to users and see how the software was being used and improving the lives of real people. They only see the barb-wire and duct tape. I had a young developer ask me once about refactoring: how do you get time to refactor your code? Never. You will never find a person willing to hand you a paycheck to take a month to change absolutely nothing. It gives the business no advantage. But the bugs! the young developer says. To which I say, dear summer child, risk tolerance. The business is willing to take the chance that 1-2% of the time a user may get frustrated, encounter a bug, and file a report or complaint. If the company has to pay you to fix it later that's fine. They can tolerate the cost. You refactor your code as you go. After you write the code and your tests pass and you think you're done -- refactor first. Abstract away superfluous variables with function application, remove duplicated code, break up long branches with decision tables, etc. Fix that code up before you check it in. As you get better your refactor steps will be much shorter as you internalize the data structures and patterns that lead you to clean, concise code to begin with. When you write software commercially you need management that understands how to balance capital, people, and technology. And you need engineers who are pragmatic about their work and the real outcomes: the systems and the people who use them.
- pdimitar 7y ago
  > You refactor your code as you go. That's one of my most valuable self-taught truths! I fought with management and colleagues for years until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains both the desired feature (or fix) and the refactoring that slightly improves the status quo of the code. This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.
  - dep_b 7y ago
sli 7y ago
My two bosses keep asking me how the code I write for myself is so stable (it's Elm), and yet we're always fixing bullshit bugs in our company's codebases (they're JS and TS -- sorry guys, TS isn't good enough). But when I try to sell them on the stuff I use personally, the response I get is "it will be too expensive if we have to hire someone for that," yet no thought to the cost-effectiveness of needing to calling a dev on a weekend with overtime pay to fix a null reference that snuck into the codebase during the week somewhere. Or months ago. I'd say another developer is more valuable than clinging to classes of bugs that don't need to exist any longer. We do what we can but can only do so much to make and keep our code stable, we're a small company with a small dev team and one of the two managers like to meddle in the code. We get by well enough, but despite all the evidence directly in front of them, I am simply not allowed to take the leap into something that would be better in the long run. It just doesn't matter to them. Another one I get is "that language is too weird," but I've taken to just directly telling them that isn't a criticism and that I need a better reason. Of course it just goes right back to the hiring excuse from above. We aren't hiring and have no plans to hire anytime soon. We're small enough to move quickly, there's no giant organization to migrate into new tooling, none of that, I'm just basically being told that I'm planning too far in advance.

232 points by barry-cotter 7y ago

*of :D

dang 7y ago

Discussed at the time: https://news.ycombinator.com/item?id=12778824 https://news.ycombinator.com/item?id=12778824 a bit more: https://news.ycombinator.com/item?id=13270271 https://news.ycombinator.com/item?id=13270271

PavlovsCat 7y ago

archive of the wayback machine archive, just in case: http://archive.is/hxEU9 http://archive.is/hxEU9

petermcneeley 7y ago

"I suspect that most discrimination that happens against older programmers is not, in fact, age discrimination, but is, in fact, ‘wisdom discrimination’."

shantly 7y ago
As long as hiring and technology decisions remain largely hype-driven, having someone around who says "we don't need k8s, hadoop, machine learning, and AWS with some big-ass Terraform-driven constellation of supporting serices for our expected data, workload, and use case; look, give me one middle-weight server, or one heavyish VM somewhere, and I can show you how to do all this with awk, sed, cron, and maybe a few lines of Perl or Python. We can have it up fast and anyone who can read man pages and a README can admin it, and anyway it's so simple and the workload static enough that once some initial kinks are worked out it'd probably run in a closet without issue for so long you'd forget it was in there—so, longer than this project is likely to be alive, anyway" isn't really something you want unless you plan to ignore them. For their fellow developers, that's résumé poison, you need "real world" experience with all this crap for the next job hunt. For the product manager, owner, and sales, you can't baffle stakeholders or investors or prospects with fancy bullshit when there isn't any fancy bullshit.
- ironmagma 7y ago
  It’s always fascinating to me how people can get to this point where they eschew new technologies just because there is an older way that works fine. Yes, having a tried and true pipeline is important, but it shouldn’t be surprising that companies are made of people who want their company to push the envelope to further evolve the systems. Someone was the first person to use Python for a production project, and that evolution has to happen somewhere, with real applications to test them.
  - NicoJuicy 7y ago
    Well, the "older tech" is ridiculously cheaper.
    - shantly 7y ago
      I work mostly in the "webshit" and mobile industry. The last time, in a work context, that I saw a site (in this case, from a vendor) and went "goddamn, for what it's doing, that is fast, this is really nice to use!" it turns out it was... PHP running on some normal-ass single instance VM or server somewhere, serving mostly just HTML.
      - ironmagma 7y ago
        It's really a spectacular outlier how well-optimized PHP is contrasted to how poorly designed the actual language is.
        ncmncm 7y ago
        Thank Facebook for that. Likely, more specifically, Andrei Alexandrescu.
    - ironmagma 7y ago
      Not universally, no. For instance, C programmers are harder to find than Python coders, and the farther back you go the harder it is to find good people (COBOL, Fortran). The newer the tech, the more people there are riding in on the hype train to choose from.

29athrowaway 7y ago

History of computer programming: - Having an accumulator (abacus) - Accumulator with operations (calculator) - Multiple registers with more complex operations (early computers with plugboards) - Stored program computer (abstraction over the plugboards) - Imperative programming (simple abstraction over operations + registers) - Procedures, Functions, Structures - OOP, functional programming, and beyond. Why do we keep making layers of abstraction? reusability. We want abstractions that reduce effort by making code reusable. But abstractions are only a tool, using the tool correctly is on the programmer. Code is written once, read many times. Languages that focus on "easy to write" are a trap. Languages that focus on "easy to reuse" are what you want.

profalseidol 7y ago
> Languages that focus on "easy to write" are a trap Reminds me of that time when my company abused Scala Implicits, possible because one of it's libraries for mapping scala to relational database had examples of it. --- Regarding re-usability. Does that imply well defined interfaces and private scopes? Does that eventually lead us to Pure functions? Afaik, pure func has maybe the highest ease/simplicity for reuse. Happy to be hear your thoughts.
gimboland 7y ago
Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well-defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.
- zo1 7y ago
  I highly agree with this. It's almost a necessity these days with a major push to hire "junior" developers at a discounted rate. By doing those lower abstraction layers, you allow them to write the necessary high-volume business code while reducing their ability to do something subtly stupid for the business/data. Usually this involves abstracting away a lot of the database transaction-type stuff. And on a side note: Never let juniors anywhere near the database design without supervision by the team/seniors. They won't learn anything that way, and they will inevitably make a mess.

ummonk 7y ago

>Some propose that the phenomenon of easy credit and low-interest rates make it economically nonviable for a company to act in its longer-term interests. Wouldn't it be the other way around? High interest rates would increase the discount rate for future value?

lazulicurio 7y ago
I think the idea is that low-interest rates cause investors to push companies to adopt riskier behavior and that easy credit enables said riskier behavior.

purplezooey 7y ago

There is so much truth in this article I nearly fell off my chair. Especially #2 and #3.

shantly 7y ago
> Oh sure, you can solve the endless little meaningless problems that plague the day-to-day life of programmers everywhere, but the source of these problems — defects at the engineering level — are effectively untouchable. Also untouchable are the systemic issues that cause each of these should-be-trivial-to-fix problems into 5–8 hour tasks. That part of #4 is so true it hurts. Most of the software I use is full of brokenness and "WTF"s. About a year ago: AWS Lamba supports Java. Sweet, should be easy. Oh but the command line tools are broken in several ways you won't discover until you try, find they're broken, google around for a while trying to figure out what's wrong, then realize it's not your fault when you find the relevant unfixed issues. About three years ago: Well I'm writing an Android app so this Google Maps feature should be a piece of cake, I mean, Google makes the OS so surely Maps is amazing on here. Except. Wait. No. That cannot be right. It can't. The Android maps SDK is missing features that the Javascript version has? No. That doesn't make any sense. Oh. Here's a GH repo someone already made to provide a convenient interface from Android Java to the Javascript maps SDK for this exact reason. I mean I guess I don't have to write it myself now but seriously, this was a fucking waste of half my day for no good reason. A few days ago: Debian installer is flat-out incapable of writing Grub correctly. Several tries, every reasonable combo possible, boot fails with missing OS every time. This ain't my first damn rodeo—something's wrong. Think it's maybe a UEFI issue. Force UEFI. Now my video card doesn't work. Because it's not UEFI compatible? Why dafuq is that even a thing? Open case, reset bios so I have a display again, install again just to be safe, boot to installer's recovery mode, mount, chroot, install grub manually and in precisely the way I'd told the installer to do it the first time, and without changing a damn thing about the config the installer had just written, and it's fine. This is basically how everything goes every time I try to do anything with software at all. Which is my job. So this is my life. Software is terrible. [EDIT] in fact I can think of one area where my tools are consistently as shitty, broken, and unsuitable for their intended purpose as software usually is: it's when I cheap out on power or (especially) hand tools to try to save a buck.

mindvirus 7y ago

I think as a profession we've been bad at quantifying and communicating the value of clean infrastructure and good development practices to the business. Why should they pay you to make things "nicer"? One of your big customers is threatening to churn if you don't deliver this new feature! To them, it sounds like you are asking them for a ton of money for better feng shui - pseudoscience with unclear benefits - when they can directly see the benefit of delivering features to the customers. Instead, I think we need to learn how to measure and quantify the value of a good codebase and good practices, and communicate that to the business. Google's error budgets are a step in the right direction here, but I think there's a lot more that can be done.

crdoconnor 7y ago
Definitely. Developing a unit of account is key to solving this problem. The problem was never that businesses didn't "get" technical debt, the problem is that they could only measure it by the volume of developers' whining.
sopooneo 7y ago
I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost multiplier" for every requested feature. So far, no one has the like the idea or phrase. I can't really blame them. But there must be some quantity or term, with a nice memorable ring to it, that could get this across and at least let business people make decisions with full information at hand. Granted, any such numbers delivered in that guise would be wild guesses. But still, better than nothing. Edit: However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully.
- m_mueller 7y ago
  How can story points be used for that? To me that's only relevant in the short term. Can management be made to understand that velocity can be too high? Edit: Expanding with my previous thoughts on this - as a software architect I've explained my role to management by saying it's like I work in an agile team, but the waterfall is in my head - someone needs to keep the architecture together and drive it towards green pastures where it keeps great flexibility for developing future anticipated features without giving up stability.

darepublic 7y ago

this problem is about as intractable to me as why I don't eat healthier. Maybe one day I will achieve one or both.

albertTJames 7y ago

This feels borderline sociopathic.. working in team is hard and demand compromise, and yes, although necessary no political system is perfect. But the work conditions of a software engineer are way better than any other job I have done.

itsmejeff 7y ago

The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don’t complain about business constraints and they put out stellar work. “business people” most often do understand what makes the money flow through their company (and into engineers’ bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don’t understand the technical details of an engineer’s work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It’s not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business. (fwiw I’m a director-level engineer so I’m technical but bordering on being a “business person”)

xaybey 7y ago
Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.
- Hackbraten 7y ago
  Depends. To > clearly articulate trade offs to stakeholders may be the constructive cousin of complaining.
- stiray 7y ago
  ... and is quite a funny statement. If "our" engineers dont "complain", then someone is not listening. Or you have really bad company culture / recruiting / engineering. The DUTY of engineer is to complain to bussiness decisions as they are quite frequent orthagonal to what does make sense to do and in which order. Make sockets as first priority and then write tcp stack as "unneeded"/postponed is quite frequent from a bussiness standpoint. Not complaining about situations like this is just hurting the bussiness.
  - yibg 7y ago

yibg 7y ago

Is it just me or does this article read as basically “everyone else is an idiot, executives (1), managers (2, 8), architects (3) and other developers (5, 6, 7) and only I can see the future and know what needs to be done.”

7777fps 7y ago
The author also equates "late nights" with hard work in point (2) which is a dangerous malpractice in itself.
vorpalhex 7y ago
The article reads to me as "I didn't get my way and our code isn't perfect, therefore it's everyone's fault but mine and if only we'd embraced X, this would have all been avoided."
pdimitar 7y ago
Pretty dismissive take. The author presents a vision on how engineering can be more effective and protests against micro-management that gives them zero room for creativity and being able to put their best work.

interblag 7y ago

5sts

galaxyLogic 7y ago

The so-called "Business People" are people who's main goal is to make money. And if you think about it that really means their main goal is is to make money for themselves. Techies' in contrast are more concerned about building great products. This naturally creates some tension between techies and the business-people. What should be the division of labor, and rewards?

tomohawk 7y ago

What a bunch of huey. I've consulted on government programs with massive amounts of money and easy to meet deadlines, and the resulting software systems were still crap. Why? Because yagni (you aint gonna need it) went right out the window and they ended up creating the most resume padding, shiny rock encrusted POS ever.

agentultra 7y ago

I don't recall ever having worked on a large code base with a team of developers where everyone was 100% happy with it. Developers complain about everything. It's never good enough and never will be. I believe this is related to our brains being hard-wired to prioritize negative phenomenon and stimuli. Most of those projects shipped and were successful. Users did like using them. However the developers often only saw the bug reports and the endless requests for new features. They never got a chance to talk to users and see how the software was being used and improving the lives of real people. They only see the barb-wire and duct tape. I had a young developer ask me once about refactoring: how do you get time to refactor your code? Never. You will never find a person willing to hand you a paycheck to take a month to change absolutely nothing. It gives the business no advantage. But the bugs! the young developer says. To which I say, dear summer child, risk tolerance. The business is willing to take the chance that 1-2% of the time a user may get frustrated, encounter a bug, and file a report or complaint. If the company has to pay you to fix it later that's fine. They can tolerate the cost. You refactor your code as you go. After you write the code and your tests pass and you think you're done -- refactor first. Abstract away superfluous variables with function application, remove duplicated code, break up long branches with decision tables, etc. Fix that code up before you check it in. As you get better your refactor steps will be much shorter as you internalize the data structures and patterns that lead you to clean, concise code to begin with. When you write software commercially you need management that understands how to balance capital, people, and technology. And you need engineers who are pragmatic about their work and the real outcomes: the systems and the people who use them.

pdimitar 7y ago
> You refactor your code as you go. That's one of my most valuable self-taught truths! I fought with management and colleagues for years until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains both the desired feature (or fix) and the refactoring that slightly improves the status quo of the code. This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.
- dep_b 7y ago

sli 7y ago

My two bosses keep asking me how the code I write for myself is so stable (it's Elm), and yet we're always fixing bullshit bugs in our company's codebases (they're JS and TS -- sorry guys, TS isn't good enough). But when I try to sell them on the stuff I use personally, the response I get is "it will be too expensive if we have to hire someone for that," yet no thought to the cost-effectiveness of needing to calling a dev on a weekend with overtime pay to fix a null reference that snuck into the codebase during the week somewhere. Or months ago. I'd say another developer is more valuable than clinging to classes of bugs that don't need to exist any longer. We do what we can but can only do so much to make and keep our code stable, we're a small company with a small dev team and one of the two managers like to meddle in the code. We get by well enough, but despite all the evidence directly in front of them, I am simply not allowed to take the leap into something that would be better in the long run. It just doesn't matter to them. Another one I get is "that language is too weird," but I've taken to just directly telling them that isn't a criticism and that I need a better reason. Of course it just goes right back to the hiring excuse from above. We aren't hiring and have no plans to hire anytime soon. We're small enough to move quickly, there's no giant organization to migrate into new tooling, none of that, I'm just basically being told that I'm planning too far in advance.