12 ms·

Enterprise Software Projects Killed the Software Developer

150 points by javahippie 5y ago

mousepilot 5y ago
this is written like its bad to "hand over code" to others. I don't like it.
- burnished 5y ago
  Reading code is harder than writing code, right? And handing code over to some one else is inherently handing it over to some one who does not have the experience or knowledge you gained writing it. If you want that person to be successful then there is pressure to make that code simple. The author thinks that pressure causes the code to also be poorly or naively engineered. I don't think the idea is that handing over code is bad, but that a team should maintain responsibility for a product over time (because they can take advantage of their domain knowledge) instead of handing it over (like it was a finished product, when it isnt).
  - runawaybottle 5y ago
    It is also the most empathetic thing you could do. Try to imagine what it would be like if someone handed over their ‘brilliant’ code to you.
    - burnished 5y ago
      I think thats part of the authors point, you can't really have brilliant (or even just clever) code if its expected to be handed off to another team.
  - knightofmars 5y ago
    While it's not as drastic a handoff, handing code from your present self to your future self is also important. I find myself thanking my past self out loud and by name at times.
- JanisL 5y ago
  Handing over code comes with some very real costs, I think it would be naive to not consider these costs.
  - hunter2_ 5y ago
    That's the main reason for DevOps, as I understand it: one team develops and operates the product. And in the case of DevSecOps, also secures it, rather than a separate team doing so. Some individuals will specialize, but a cross-trained core team ties both (or all three) of these functions together throughout the product's life cycle.
lamplovin 5y ago
Why would it be a problem to write code in a way that's easily understood by others reading it? If your code is so complicated that a little bit of documentation can't explain it or at least help get people started then you're probably being too "clever" with your code and need to simplify it a bit. Simple code doesn't mean it has to be under-engineered or non-performant, and creating a culture that doesn't take the time to help others understand what's going on is how teams get to the point of depending entirely on 2 people to do all their enhancements/fixes.
- derekp7 5y ago
  Because sometimes the clever code may be easier to understand by an experienced developer even if it is less accessible to a less experienced developer. Non-coding example: "Two plus Three times Five" is easy to understand, because you don't need to know math symbols. But to anyone who knows math, "2 + 3 * 5" is easier/quicker to read. For a coding example, in Javascript you have things like arrow functions that make the code more concise. But that is also harder to read for someone who hasn't picked up on them yet (which may have been the case when they were first introduced).
  - lamplovin 5y ago
    I agree with you on language syntax choices, but as far as the articles examples are concerned it seemed like the "clever" solutions to them were more about OO architecture choices via abstraction for example. In which case, if it's not a codebase that you have experience in, then those architecture choices can get very confusing if not properly documented
  - tejtm 5y ago
    It is ambiguous, "Two plus Three times Five" as a sentence reads and is naturally processed from left to right for a result of " is twenty-five". But to anyone who knows math (precedence), "2 + 3 * 5 = 17"
    - jaywalk 5y ago
      The order of operations doesn't change because the equation is written out in English versus mathematical notation.
toxodont 5y ago
Sounds like you didn't have a very good try at presenting your alt. architecture to the enterprise architecture team. As an architect I don't mind alternative approaches and variances from a stated architecture if they can be justified.
- thinkharderdev 5y ago
  The issue is that the team/person doing the implementation has to "justify" their architecture to someone who won't be themselves working on the implementation. Or just in general separating "architecture" and "implementation" into separate tasks done by separate teams. The people in the best position to weigh the relevant tradeoffs and design the best architecture are the people who have the most domain knowledge of the problem being solved and who will ultimately be on the hook for the system when it is production.
commandlinefan 5y ago
> I have never seen SCRUM or any agile approach working in a project setup ever. I am biased, though, because a company that truly lives agile values won’t do software development in a project setup When I first read the Agile Manifesto - around '99, I think - it seemed clear to me that this was a great leap forward in software design, but that it was clearly implied that this couldn't be used in a "fixed deadline" environment. I really wish they had actually called that out in the manifesto itself and made that more obvious.
- cabernal 5y ago
  Could you expand on this? A fixed deadline can mean fixed budget, which the majority software projects fall under.
  - Raidion 5y ago
    Agile requires just in time requirements and priority setting, coupled with the ability to make small changes and iterate. If you have a "this feature needs to be delivered by X date" type of corporate culture, then you have to make a commitment, and because dates are almost always tight, you need to be as efficient as possible to achieve that goal. So basically you have the software teams wanting to work in two week sprints, and you have execs needing new thing for contract launch in X weeks, and guess who wins? It's not the software developer, so the agile becomes toothless, because you're not learning, or iterating. You're just pushing against a gantt chart the whole way a sprint at a time, and might not even be able to release beta versions and get feedback, because that takes up valuable time. I'm not as cynical as OP, but there is a really big push/pull that happens, and it can turn into a toxic environment if forces too far outside the product/development cycle dictate priorities (like sales, or execs).
    - wavefunction 5y ago
      I don't agree that Agile requires JIT requirements but benefits from and thus promotes them as the best way to deliver requirements for a feature. Under waterfall, a document is written by an analyst that describes a problem to be fixed. Six months later, the task is picked up but legal regulations or market conditions or even the rest of the software has changed. However, the Waterfall requirements are the requirements and that's what gets implemented. Best-case scenario is that the business analyst that wrote the original spec is still employed and has been updating the requirements as conditions change. What we've done at successful agile shops I've been a part of is quarterly planning that collects at a high-level the current requests/needs of the business, prioritizes them, they get a t-shirt size to determine if all of the requests/needs can be met during the quarter and they fall off by priority until you're left with a manageable high-level plan of work for the quarter. Then those high-level requests are decomposed into epics and stories which are specced out and estimated, etc. It works very well but it requires that people work collaboratively from the executives and business stake-holders to the technical leadership and individual engineers.
0xbadcafebee 5y ago
You'll never see a purely Agile or Lean product from an Enterprise, because those don't have a clearly defined set of expenses, profits, and timelines. One terrible thing about Enterprises is the way their finance team leads product decisions. In order to maximize their profit, they announce a product will be ready by X date, and estimate the cost leading up to it. If you don't hit those numbers, it affects a lot of other numbers, especially if you're publicly traded. And that's before the wild promises Sales makes. They are preternaturally addicted to arbitrary deliverables. Essentially, their products are projects, and the customers are incidental to the whole thing. There is no estimate for customer happiness in the business case for a new product team. If you build it on time and under budget, everything else (getting a customer to use it and like it) is taken for granted.
- Mxs2000 5y ago
  Would you mind telling me at what kind of Enterprise you had that experience with finance? I led a product finance team at a SaaS company (ServiceNow, Atlassian, Okta, etc. tier) and all of our models and analyses are product driven including a/b testing and surveys with customers.
  - 0xbadcafebee 5y ago
    Largely Enterprises that had too much profit to care, or were controlled by a parent org with a tight leash on expense with no regard to product. Old-school businesses that had barely begun digital transformation. As long as they got their 2% growth YOY, there was no interest in closely tracking anything but the core BI metrics for growth and expense. I would add that a/b and surveys are not good enough to identify customer pain and solve the problems they most want solved. There's a raft of feedback mechanisms that most Enterprises ignore because their products are so complicated that nobody wants to sit with the users and find new methods for continuous improvement. Agile/Lean/DevOps/SRE constantly emphasize quality and immediate halting of product work until bugs are fixed, yet no Enterprise I have ever heard of does this (even for reliability - one of the core metrics of any online product!)
trhway 5y ago
what doesn't kill us makes us stronger. > Personally, I have never seen SCRUM or any agile approach working in a project setup ever. they work great. Just their goal isn't successful delivery of the project (on that aspect they fail spectacularly). The goal of SCRUM/Agile/Lean - ie. what they are designed for - is extremely low latency and high observability by the management (and thus the management just loves it, total micromanagement under the guise of team freedom). That all comes naturally at a great cost of throughput. I.e. the "watched pot" situation. The project direction is changed very fast, there is a lot of activity, the bees are overly busy, the management always know and able to report the current progress state, while the project is hardly really moving toward the actually successful state.
Clubber 5y ago
>If developers are prohibited from writing native SQL, they will be limited by HQL, writing slower queries or needing multiple queries from their application for one task. We use a similar framework, but we create custom views when we need performant retrieval, or the hydration of a big object graph is being done and not needed (like a grid). >If the exact language, framework, libraries are prescribed in every detail, developers sometimes need to bend these tools to solve their requirements instead of using the right tool for their problem. If the layered architecture is to be zealously followed, 50% of your code will be the mappers between the layers. We use automapper, which does exactly what it says. We manually map one-offs. In fact, that's the basic philosophy of this design. Have the framework build everything from the entities, then one-off what you need. Our design is generic so every table has an entity, then we use a generic service layer with your normal CRUD + search functions, then our controllers are auto-generated using the same thing. We do custom work only for one-off stuff that either is more complex than CRUD, or requires higher performance. It's cut our development time significantly, since for normal crud work, it's auto-generated based on the entity itself. You create the entity and dto's and the repository, service layer and controller are all auto-constructed using generic code. If you need something special, you create a custom controller/service. We tend to leave the repositories generic. Note this is just for the WebAPIs, front end is a different monster.
codingdave 5y ago
The disclaimer at the top, where they say their experience comes from being an external consultant is key. Because when I worked in Enterprise IT, we had our own team of senior software folk, and my experience does not match this article. I'm not saying we didn't have our problems, they were just different than described. At the end of the day, though, the point of treating internal products like products and not projects is accurate. Every good IT shop I was a part of landed at this answer, even if we got there through different experiences.
- jkingsbery 5y ago
  I had the same reaction. I've spent most of my career working on non-consumer-facing software (either internal enterprise, or external to enterprises or small-medium businesses). At all the places I've worked, the team that built software was the one that would go on to operate it - there was no hand-off. Then again, I've never worked in consulting, nor worked on teams that used consultants to deliver code. Many of the points the article raised are good ones, it's a shame that the title is so misleading (or at least, reflects a narrow experience).
useful 5y ago
Elegant and clever code wont live through a maintenance cycle. I'll take a software developer who writes and structures code so change requests and code are written in a way that the DSL is the same across the organization. This makes changes easy. Clever people should be writing libraries or doing research. Don't kid yourself, you are either the guy who builds the building and its easy because its greenfield, or you are doing remodeling and the hard part is making the upgrade fit in the building and not look like shit.
- zozbot234 5y ago
  The fix is to properly document your code. "Clever" code is an anti-pattern, but there's no need to make your code less elegant or less properly engineered than it otherwise could be. Hacked-together, low quality code is even less maintainable than "overly clever" code, so it's worth trying to avoid that.
  - slownews45 5y ago
    Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP script kid basically writes a linear program (tons of duplication) with no crazinesses. Yes, it's "low quality", but if you do a few function out refactorings you've got something very easy to work with. I just wish there was a standard template - access check, runtime complexity at code comment at top of function (ie, O(1), O(n), O(n^2)) some reasonable comments, error handling, done. Throw in some unit tests if desired.
    - rightbyte 5y ago
      I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.
      - 5y ago
qznc 5y ago
> The more standardized the environment for a software developer is, the more under-engineered their code will be. Ok, so there is a tradeoff. It does not mean that the Enterprise approach is wrong in general. Maybe that standardization is worth it? How could one quantify that?
mirekrusin 5y ago
The best enterprice architects I worked with don't know shit. They can plot 3 boxes with 4 arrows and call it a day. They can take credit for working system, it doesn't matter. What really matters is that they don't waste time on useless preplanning, don't give you (as tech lead/senior dev) solutions to implement, but problems to solve. They don't know how to solve integration problems, but they know how to click to schedule teams meeting with people who take care of those systems. Solution is usually easily agreed between tech people during those calls/folloups. Architect is able to wrap it in power point presentation with 2 boxes and 1 arrow and call it integration solution. It sounds like a joke, but I'm serious.
- orthoxerox 5y ago
  We must've worked with the same architects!
- Aeolun 5y ago
  Hmm, yeah. The worst ones are the ones that think they actually know coding, or how a system should be implemented. But mostly it’s annoying since we spend hours or days going around in circles until we arrive at the obvious solution (which the engineering team proposed at the start).
- TeeMassive 5y ago
  I agree with this. They know most of the parts, what works smoothly and what needs more love, and they talk to people. Then they can give an informed advice with a few UML diagrams and a few code examples.
- HillRat 5y ago
  Speaking as a — now former — architect, I’d agree! The best use of my time always turned out to be dealing with scope and feature risk, areas of ambiguity, and governance. Part of this is because very few software projects hinge their success on complex and elegant solutions to thorny conceptual problems, but also because competent developers generally don’t need an architect doing much more than sketching out the broad contours for them to get in and design/build the system; what they really need from the architect is client alignment, well-defined feature scope and dependencies, locked down RACIs, realistic team sizes and schedules, and just enough governance to keep everything on track without overmanagement. A successful architect, in other words, is technically-competent enough to figure out what has to go into the solution (which crosses many disciplinary boundaries) and what the overall project size roughly looks like, but the second they try to create detailed technical plans they’re wasting time and money.
rullopat 5y ago
Have you ever had a person in your team “so clever” that as soon as he/she learns a new feature of the language, they use it everything to look even more clever? Most of them are in love with genetics/templates, I call them “the code masturbators”.
avmich 5y ago
There was that interview with Peter Norvig - https://www.youtube.com/watch?v=_VPxEcT_Adc https://www.youtube.com/watch?v=_VPxEcT_Adc - I believe there he said something roughly like "before programming was about composing algorithms, structures etc. - and engineers used ideas from SICP - now it's about composing 3rd-party libraries and solutions - and engineers don't read manuals, don't worry about how systems work internally etc." Pardon if I stretched the meaning too much. I think this more modern approach has some important pitfalls which we're uncovering now and getting hurt by them.
- stevenalowe 5y ago
  ah, yes and no. You really can't know the internal workings of everything, it's not practical anymore. in other words: you can stand up a web site in less than an hour that will handle enormous loads across the globe, but not if you pause to read all the library code that goes into it. fortunately, humans are pretty good a having faith in things
  - avmich 5y ago
    There is "From NAND to Tetris". There are not-too-few people with knowledge "from quantum mechanics to UI". At some point you get accustomed to actually know everything :) and you're annoyed with details which are excessive. The non-essential ("incidental") complexity. You can probably make website faster if you learn 3rd party tools for that... but then you won't be in the position of Paul Graham in Viaweb, where a small team run circles around competition, being that much more productive. I suspect Apple's success is largely because Woz knew ins and outs of the system. Your important here word is "anymore". Maybe we're at the wave of complexity which will wane. I don't actually think it will last.
  - culopatin 5y ago
    As a self taught person who likes to dive deep, I’m starting to realize why I fall behind some dude that watched some YouTube videos, did leetcode and got a job somewhere. I follow a tutorial and if I’m not understanding how the guy got to knowing that the property we should use in that scenario was X, I think I’m not understanding anything and that I won’t be able to build anything, so I halt trying to figure out, but I’m so inexperienced that I can’t understand the docs anyway. What I should be doing is putting that code in my notes and moving on having faith in that code. I was thinking of opening an Ask HN about “how much of your code do you actually fully understand vs how much is just copied from somewhere “
cjtrowbridge 5y ago
"When Hiro learned how to do this, way back fifteen years ago, a hacker could sit down and write an entire piece of software by himself. Now, that's no longer possible. Software comes out of factories, and hackers are, to a greater or lesser extent, assembly-line workers. Worse yet, they may become managers who never get to write any code themselves." Neal Stephenson, Snow Crash, 1992
- valzam 5y ago
  When I started reading Snow Crash and he described basically Uber/Doordash etc. in the first 10 pages I nearly fell off my chair. Insane how prescient Stephenson is.
  - hnzix 5y ago
    I really, really hope Stephenson's Fall in Hell isn't prescient when it comes to the rise of Ameristan. That book plus Palahniuk's Adjustment Day are a terrifying glimpse of our boring dystopia morphing into complete dystopia.
dangus 5y ago
This post largely glosses over the business motivation of these efforts. Businesses want to reduce risk. That means reducing the probability of expensive surprises. That means they'd rather spend 10% more on inefficient code running in production than to risk their 10x developer quitting and nobody else being able to understand the codebase, costing the company a lot more. A lot of developers and engineers just want to have their space to tinker, to grow their skills and their mind. As a bonus, under this arrangement they'd get paid for it! That's not how the real world works. Work follows the money, not the passion, and that's why work generally sucks. E.g.: Photographers don't get to spend all day doing art photography, they largely have to do wedding photos to pay the bills. If you don't want your hobby to suck, don't do it as a job (or accept that work sucks and do stuff on the side for your own enjoyment if you have the energy for it). My best advice for any engineer is to take active interest in the business' needs and wants and consider those to be on a higher pedestal than implementation details.
kumarvvr 5y ago
A lot of software development paradigms seem to have developed from requirements of Enterprise Software. Sure, you'd have a Caramack here and there, but if left to their own devices, most software would end up being spaghetti code. Especially when it involves a steady stream of changes over time.
lkrubner 5y ago
This covers some points that were discussed on Hacker News in response to my essay "Why are large companies so difficult to rescue (regarding internal technology)". If this interests you, then this old conversation might also interest you: https://news.ycombinator.com/item?id=20260114 https://news.ycombinator.com/item?id=20260114
fukmbas 5y ago
MBAs killed the software developer (and all other tech jobs)
twirlock 5y ago
ITT we eat sour grapes about codebases that are subordinate to cohesive theories.

150 points by javahippie 5y ago

mousepilot 5y ago

this is written like its bad to "hand over code" to others. I don't like it.

burnished 5y ago
Reading code is harder than writing code, right? And handing code over to some one else is inherently handing it over to some one who does not have the experience or knowledge you gained writing it. If you want that person to be successful then there is pressure to make that code simple. The author thinks that pressure causes the code to also be poorly or naively engineered. I don't think the idea is that handing over code is bad, but that a team should maintain responsibility for a product over time (because they can take advantage of their domain knowledge) instead of handing it over (like it was a finished product, when it isnt).
- runawaybottle 5y ago
  It is also the most empathetic thing you could do. Try to imagine what it would be like if someone handed over their ‘brilliant’ code to you.
  - burnished 5y ago
    I think thats part of the authors point, you can't really have brilliant (or even just clever) code if its expected to be handed off to another team.
- knightofmars 5y ago
  While it's not as drastic a handoff, handing code from your present self to your future self is also important. I find myself thanking my past self out loud and by name at times.
JanisL 5y ago
Handing over code comes with some very real costs, I think it would be naive to not consider these costs.
- hunter2_ 5y ago
  That's the main reason for DevOps, as I understand it: one team develops and operates the product. And in the case of DevSecOps, also secures it, rather than a separate team doing so. Some individuals will specialize, but a cross-trained core team ties both (or all three) of these functions together throughout the product's life cycle.

lamplovin 5y ago

Why would it be a problem to write code in a way that's easily understood by others reading it? If your code is so complicated that a little bit of documentation can't explain it or at least help get people started then you're probably being too "clever" with your code and need to simplify it a bit. Simple code doesn't mean it has to be under-engineered or non-performant, and creating a culture that doesn't take the time to help others understand what's going on is how teams get to the point of depending entirely on 2 people to do all their enhancements/fixes.

derekp7 5y ago
Because sometimes the clever code may be easier to understand by an experienced developer even if it is less accessible to a less experienced developer. Non-coding example: "Two plus Three times Five" is easy to understand, because you don't need to know math symbols. But to anyone who knows math, "2 + 3 * 5" is easier/quicker to read. For a coding example, in Javascript you have things like arrow functions that make the code more concise. But that is also harder to read for someone who hasn't picked up on them yet (which may have been the case when they were first introduced).
- lamplovin 5y ago
  I agree with you on language syntax choices, but as far as the articles examples are concerned it seemed like the "clever" solutions to them were more about OO architecture choices via abstraction for example. In which case, if it's not a codebase that you have experience in, then those architecture choices can get very confusing if not properly documented
- tejtm 5y ago
  It is ambiguous, "Two plus Three times Five" as a sentence reads and is naturally processed from left to right for a result of " is twenty-five". But to anyone who knows math (precedence), "2 + 3 * 5 = 17"
  - jaywalk 5y ago
    The order of operations doesn't change because the equation is written out in English versus mathematical notation.

toxodont 5y ago

Sounds like you didn't have a very good try at presenting your alt. architecture to the enterprise architecture team. As an architect I don't mind alternative approaches and variances from a stated architecture if they can be justified.

thinkharderdev 5y ago
The issue is that the team/person doing the implementation has to "justify" their architecture to someone who won't be themselves working on the implementation. Or just in general separating "architecture" and "implementation" into separate tasks done by separate teams. The people in the best position to weigh the relevant tradeoffs and design the best architecture are the people who have the most domain knowledge of the problem being solved and who will ultimately be on the hook for the system when it is production.

commandlinefan 5y ago

> I have never seen SCRUM or any agile approach working in a project setup ever. I am biased, though, because a company that truly lives agile values won’t do software development in a project setup When I first read the Agile Manifesto - around '99, I think - it seemed clear to me that this was a great leap forward in software design, but that it was clearly implied that this couldn't be used in a "fixed deadline" environment. I really wish they had actually called that out in the manifesto itself and made that more obvious.

cabernal 5y ago
Could you expand on this? A fixed deadline can mean fixed budget, which the majority software projects fall under.
- Raidion 5y ago
  Agile requires just in time requirements and priority setting, coupled with the ability to make small changes and iterate. If you have a "this feature needs to be delivered by X date" type of corporate culture, then you have to make a commitment, and because dates are almost always tight, you need to be as efficient as possible to achieve that goal. So basically you have the software teams wanting to work in two week sprints, and you have execs needing new thing for contract launch in X weeks, and guess who wins? It's not the software developer, so the agile becomes toothless, because you're not learning, or iterating. You're just pushing against a gantt chart the whole way a sprint at a time, and might not even be able to release beta versions and get feedback, because that takes up valuable time. I'm not as cynical as OP, but there is a really big push/pull that happens, and it can turn into a toxic environment if forces too far outside the product/development cycle dictate priorities (like sales, or execs).
  - wavefunction 5y ago
    I don't agree that Agile requires JIT requirements but benefits from and thus promotes them as the best way to deliver requirements for a feature. Under waterfall, a document is written by an analyst that describes a problem to be fixed. Six months later, the task is picked up but legal regulations or market conditions or even the rest of the software has changed. However, the Waterfall requirements are the requirements and that's what gets implemented. Best-case scenario is that the business analyst that wrote the original spec is still employed and has been updating the requirements as conditions change. What we've done at successful agile shops I've been a part of is quarterly planning that collects at a high-level the current requests/needs of the business, prioritizes them, they get a t-shirt size to determine if all of the requests/needs can be met during the quarter and they fall off by priority until you're left with a manageable high-level plan of work for the quarter. Then those high-level requests are decomposed into epics and stories which are specced out and estimated, etc. It works very well but it requires that people work collaboratively from the executives and business stake-holders to the technical leadership and individual engineers.

0xbadcafebee 5y ago

You'll never see a purely Agile or Lean product from an Enterprise, because those don't have a clearly defined set of expenses, profits, and timelines. One terrible thing about Enterprises is the way their finance team leads product decisions. In order to maximize their profit, they announce a product will be ready by X date, and estimate the cost leading up to it. If you don't hit those numbers, it affects a lot of other numbers, especially if you're publicly traded. And that's before the wild promises Sales makes. They are preternaturally addicted to arbitrary deliverables. Essentially, their products are projects, and the customers are incidental to the whole thing. There is no estimate for customer happiness in the business case for a new product team. If you build it on time and under budget, everything else (getting a customer to use it and like it) is taken for granted.

Mxs2000 5y ago
Would you mind telling me at what kind of Enterprise you had that experience with finance? I led a product finance team at a SaaS company (ServiceNow, Atlassian, Okta, etc. tier) and all of our models and analyses are product driven including a/b testing and surveys with customers.
- 0xbadcafebee 5y ago
  Largely Enterprises that had too much profit to care, or were controlled by a parent org with a tight leash on expense with no regard to product. Old-school businesses that had barely begun digital transformation. As long as they got their 2% growth YOY, there was no interest in closely tracking anything but the core BI metrics for growth and expense. I would add that a/b and surveys are not good enough to identify customer pain and solve the problems they most want solved. There's a raft of feedback mechanisms that most Enterprises ignore because their products are so complicated that nobody wants to sit with the users and find new methods for continuous improvement. Agile/Lean/DevOps/SRE constantly emphasize quality and immediate halting of product work until bugs are fixed, yet no Enterprise I have ever heard of does this (even for reliability - one of the core metrics of any online product!)

trhway 5y ago

what doesn't kill us makes us stronger. > Personally, I have never seen SCRUM or any agile approach working in a project setup ever. they work great. Just their goal isn't successful delivery of the project (on that aspect they fail spectacularly). The goal of SCRUM/Agile/Lean - ie. what they are designed for - is extremely low latency and high observability by the management (and thus the management just loves it, total micromanagement under the guise of team freedom). That all comes naturally at a great cost of throughput. I.e. the "watched pot" situation. The project direction is changed very fast, there is a lot of activity, the bees are overly busy, the management always know and able to report the current progress state, while the project is hardly really moving toward the actually successful state.

Clubber 5y ago

>If developers are prohibited from writing native SQL, they will be limited by HQL, writing slower queries or needing multiple queries from their application for one task. We use a similar framework, but we create custom views when we need performant retrieval, or the hydration of a big object graph is being done and not needed (like a grid). >If the exact language, framework, libraries are prescribed in every detail, developers sometimes need to bend these tools to solve their requirements instead of using the right tool for their problem. If the layered architecture is to be zealously followed, 50% of your code will be the mappers between the layers. We use automapper, which does exactly what it says. We manually map one-offs. In fact, that's the basic philosophy of this design. Have the framework build everything from the entities, then one-off what you need. Our design is generic so every table has an entity, then we use a generic service layer with your normal CRUD + search functions, then our controllers are auto-generated using the same thing. We do custom work only for one-off stuff that either is more complex than CRUD, or requires higher performance. It's cut our development time significantly, since for normal crud work, it's auto-generated based on the entity itself. You create the entity and dto's and the repository, service layer and controller are all auto-constructed using generic code. If you need something special, you create a custom controller/service. We tend to leave the repositories generic. Note this is just for the WebAPIs, front end is a different monster.

codingdave 5y ago

The disclaimer at the top, where they say their experience comes from being an external consultant is key. Because when I worked in Enterprise IT, we had our own team of senior software folk, and my experience does not match this article. I'm not saying we didn't have our problems, they were just different than described. At the end of the day, though, the point of treating internal products like products and not projects is accurate. Every good IT shop I was a part of landed at this answer, even if we got there through different experiences.

jkingsbery 5y ago
I had the same reaction. I've spent most of my career working on non-consumer-facing software (either internal enterprise, or external to enterprises or small-medium businesses). At all the places I've worked, the team that built software was the one that would go on to operate it - there was no hand-off. Then again, I've never worked in consulting, nor worked on teams that used consultants to deliver code. Many of the points the article raised are good ones, it's a shame that the title is so misleading (or at least, reflects a narrow experience).

useful 5y ago

Elegant and clever code wont live through a maintenance cycle. I'll take a software developer who writes and structures code so change requests and code are written in a way that the DSL is the same across the organization. This makes changes easy. Clever people should be writing libraries or doing research. Don't kid yourself, you are either the guy who builds the building and its easy because its greenfield, or you are doing remodeling and the hard part is making the upgrade fit in the building and not look like shit.

zozbot234 5y ago
The fix is to properly document your code. "Clever" code is an anti-pattern, but there's no need to make your code less elegant or less properly engineered than it otherwise could be. Hacked-together, low quality code is even less maintainable than "overly clever" code, so it's worth trying to avoid that.
- slownews45 5y ago
  Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP script kid basically writes a linear program (tons of duplication) with no crazinesses. Yes, it's "low quality", but if you do a few function out refactorings you've got something very easy to work with. I just wish there was a standard template - access check, runtime complexity at code comment at top of function (ie, O(1), O(n), O(n^2)) some reasonable comments, error handling, done. Throw in some unit tests if desired.
  - rightbyte 5y ago
    I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.
    - 5y ago

qznc 5y ago

> The more standardized the environment for a software developer is, the more under-engineered their code will be. Ok, so there is a tradeoff. It does not mean that the Enterprise approach is wrong in general. Maybe that standardization is worth it? How could one quantify that?

mirekrusin 5y ago

The best enterprice architects I worked with don't know shit. They can plot 3 boxes with 4 arrows and call it a day. They can take credit for working system, it doesn't matter. What really matters is that they don't waste time on useless preplanning, don't give you (as tech lead/senior dev) solutions to implement, but problems to solve. They don't know how to solve integration problems, but they know how to click to schedule teams meeting with people who take care of those systems. Solution is usually easily agreed between tech people during those calls/folloups. Architect is able to wrap it in power point presentation with 2 boxes and 1 arrow and call it integration solution. It sounds like a joke, but I'm serious.

orthoxerox 5y ago
We must've worked with the same architects!
Aeolun 5y ago
Hmm, yeah. The worst ones are the ones that think they actually know coding, or how a system should be implemented. But mostly it’s annoying since we spend hours or days going around in circles until we arrive at the obvious solution (which the engineering team proposed at the start).
TeeMassive 5y ago
I agree with this. They know most of the parts, what works smoothly and what needs more love, and they talk to people. Then they can give an informed advice with a few UML diagrams and a few code examples.
HillRat 5y ago
Speaking as a — now former — architect, I’d agree! The best use of my time always turned out to be dealing with scope and feature risk, areas of ambiguity, and governance. Part of this is because very few software projects hinge their success on complex and elegant solutions to thorny conceptual problems, but also because competent developers generally don’t need an architect doing much more than sketching out the broad contours for them to get in and design/build the system; what they really need from the architect is client alignment, well-defined feature scope and dependencies, locked down RACIs, realistic team sizes and schedules, and just enough governance to keep everything on track without overmanagement. A successful architect, in other words, is technically-competent enough to figure out what has to go into the solution (which crosses many disciplinary boundaries) and what the overall project size roughly looks like, but the second they try to create detailed technical plans they’re wasting time and money.

rullopat 5y ago

Have you ever had a person in your team “so clever” that as soon as he/she learns a new feature of the language, they use it everything to look even more clever? Most of them are in love with genetics/templates, I call them “the code masturbators”.

avmich 5y ago

There was that interview with Peter Norvig - https://www.youtube.com/watch?v=_VPxEcT_Adc https://www.youtube.com/watch?v=_VPxEcT_Adc - I believe there he said something roughly like "before programming was about composing algorithms, structures etc. - and engineers used ideas from SICP - now it's about composing 3rd-party libraries and solutions - and engineers don't read manuals, don't worry about how systems work internally etc." Pardon if I stretched the meaning too much. I think this more modern approach has some important pitfalls which we're uncovering now and getting hurt by them.

stevenalowe 5y ago
ah, yes and no. You really can't know the internal workings of everything, it's not practical anymore. in other words: you can stand up a web site in less than an hour that will handle enormous loads across the globe, but not if you pause to read all the library code that goes into it. fortunately, humans are pretty good a having faith in things
- avmich 5y ago
  There is "From NAND to Tetris". There are not-too-few people with knowledge "from quantum mechanics to UI". At some point you get accustomed to actually know everything :) and you're annoyed with details which are excessive. The non-essential ("incidental") complexity. You can probably make website faster if you learn 3rd party tools for that... but then you won't be in the position of Paul Graham in Viaweb, where a small team run circles around competition, being that much more productive. I suspect Apple's success is largely because Woz knew ins and outs of the system. Your important here word is "anymore". Maybe we're at the wave of complexity which will wane. I don't actually think it will last.
- culopatin 5y ago
  As a self taught person who likes to dive deep, I’m starting to realize why I fall behind some dude that watched some YouTube videos, did leetcode and got a job somewhere. I follow a tutorial and if I’m not understanding how the guy got to knowing that the property we should use in that scenario was X, I think I’m not understanding anything and that I won’t be able to build anything, so I halt trying to figure out, but I’m so inexperienced that I can’t understand the docs anyway. What I should be doing is putting that code in my notes and moving on having faith in that code. I was thinking of opening an Ask HN about “how much of your code do you actually fully understand vs how much is just copied from somewhere “

cjtrowbridge 5y ago

"When Hiro learned how to do this, way back fifteen years ago, a hacker could sit down and write an entire piece of software by himself. Now, that's no longer possible. Software comes out of factories, and hackers are, to a greater or lesser extent, assembly-line workers. Worse yet, they may become managers who never get to write any code themselves." Neal Stephenson, Snow Crash, 1992

valzam 5y ago
When I started reading Snow Crash and he described basically Uber/Doordash etc. in the first 10 pages I nearly fell off my chair. Insane how prescient Stephenson is.
- hnzix 5y ago
  I really, really hope Stephenson's Fall in Hell isn't prescient when it comes to the rise of Ameristan. That book plus Palahniuk's Adjustment Day are a terrifying glimpse of our boring dystopia morphing into complete dystopia.

dangus 5y ago

This post largely glosses over the business motivation of these efforts. Businesses want to reduce risk. That means reducing the probability of expensive surprises. That means they'd rather spend 10% more on inefficient code running in production than to risk their 10x developer quitting and nobody else being able to understand the codebase, costing the company a lot more. A lot of developers and engineers just want to have their space to tinker, to grow their skills and their mind. As a bonus, under this arrangement they'd get paid for it! That's not how the real world works. Work follows the money, not the passion, and that's why work generally sucks. E.g.: Photographers don't get to spend all day doing art photography, they largely have to do wedding photos to pay the bills. If you don't want your hobby to suck, don't do it as a job (or accept that work sucks and do stuff on the side for your own enjoyment if you have the energy for it). My best advice for any engineer is to take active interest in the business' needs and wants and consider those to be on a higher pedestal than implementation details.

kumarvvr 5y ago

A lot of software development paradigms seem to have developed from requirements of Enterprise Software. Sure, you'd have a Caramack here and there, but if left to their own devices, most software would end up being spaghetti code. Especially when it involves a steady stream of changes over time.

lkrubner 5y ago

This covers some points that were discussed on Hacker News in response to my essay "Why are large companies so difficult to rescue (regarding internal technology)". If this interests you, then this old conversation might also interest you: https://news.ycombinator.com/item?id=20260114 https://news.ycombinator.com/item?id=20260114

fukmbas 5y ago

MBAs killed the software developer (and all other tech jobs)

twirlock 5y ago

ITT we eat sour grapes about codebases that are subordinate to cohesive theories.