Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enterprise Software Projects Killed the Software Developer

javahippie.net

Post reply on HN
Print view View original

131–140 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#131

Post by baobabKoodaa »

lycopodiopsida wrote: post #129
baobabKoodaa wrote: post #126

Earlier quoted context omitted.

In my opinion, writing code that is so complex it takes an expert to understand it, is undesirable.

But where do we draw the line? If someone does not understand the idea behind interfaces or proper exception handling, who is to blame? If you write Java and Streams are the natural solution, but the developer you work with never bothered to look them up, because they are "complex" and "FP-something"? These are polemic examples, but there is a line where sticking to the lowest common knowledge will hurt your best dev…

> But where do we draw the line?

Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you think mediocre developers can't understand streams, then don't use streams. (Personally I think your examples of interfaces, exception handling, and streams, are all things that have their time and place, so it would be fine to use them when needed, and just expect that developers after you will know/learn that stuff.)

Re: Enterprise Software Projects Killed the Software Developer

#132

Post by thinkharderdev »

slownews45 wrote: post #56
rightbyte wrote: post #42

Earlier quoted context omitted.

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.

Exactly this. The person who knows all the "engineering" - you have this giant mutating pile of impossible to fellow (but maybe 5% faster) code. The person who just codes enterprise style, long but done and easier to follow and edit.

I guess it depends on how you define "enterprise" but I always associated that word with unnecessarily bloated code. Or even worse, trying to reduce the amount of code by pushing more and more to ever more complicated declarative configuration files. That is mostly because when I hear "enterprise" I immediately think Java EE, which to me was the exact polar opposite of easy to edit and follow.

Re: Enterprise Software Projects Killed the Software Developer

#133

Post by thinkharderdev »

slownews45 wrote: post #57
thinkharderdev wrote: post #45

Earlier quoted context omitted.

"Reflection, endless hierarchies, complexity on complexity" sounds like the exact opposite of "elegant properly engineered code"

You may not have worked with folks really into "properly engineered code". But it is amazing sometimes to see how they can twist language into pretzels by knowing every trick and pattern out there. And yes, somewhere in OOP land this is all proper engineering and the abstraction on abstraction on library on library is the key. The worst is when they start talking about future this and that. Trouble!

I've definitely seen my share of impossibly convoluted code written in the name of "best practices" (often done because we need to "future proof" against some imagined future use case), but I've also seen my share of properly engineered code that was elegant, testable, composable and easy to work with (code that "cleaved the problem domain at the joints" if you will).

But what I think the author meant is that the incomprehensible abstraction soup is at least in part a result of the "enterprise development" method. If you are solving a particular problem for a particular application you tend to solve the problem in a straightforward way as possible (if you're any good at least). But if you an "enterprise architect" you are trying to create architectures that both solve no problem in particular and all problems at once. So you tend to get complex abstractions that are both complicated to work with and don't cleanly deal with any particular implementation.

Re: Enterprise Software Projects Killed the Software Developer

#134

Post by frebord »

useful wrote: post #14

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…

In my enterprise experience the remodeler usually just ends up bolting more shit onto the existing heap of shit.

Dev time ends up taking longer and longer, wasting more and more money.

Its funny you mention greenfield being easy in the same sentence - because IMO starting over is often the better option than the shit bolting but no one wants to go down that route because they need it next week. A whole bunch of small shit bolting projects every week instead of sitting down and cleverly engineering better broader solutions.

Re: Enterprise Software Projects Killed the Software Developer

#135

Post by feoren »

smoll wrote: post #122
feoren wrote: post #113

Earlier quoted context omitted.

Then stop writing CRUD APIs; make the compiler do it instead. If you're doing rote, boring, assembly-line programming, then you're doing the compiler's job.

Imagine you’re working at a startup and trying to solve a tough real-world problem by creating software that involves writing some CRUD APIs. You bring on someone to the team who says, “we gotta stop writing these pointless CRUD APIs and write compilers instead.” I’m not trying to be dismissive, but I think this actually well illustrates the central tension between engineers who are more interested in the business pr…

It sounds like you're categorizing me as one of the people interested in solving technology problems more than business problems. In fact the opposite is true, to the extent that I've become a go-to person for questions on the domain I'm working in, even without any programming context around it (e.g. a senior technical review of an Excel document in the domain). I've become a recognized subject-matter expert in multiple business domains. If I'm not focused on solving the business problem, I don't know who is.

In fact it seems like it's quite the opposite: people who think in terms of loops, conditionals, and objects seem to be happy writing repetitive CRUD APIs all day. People who think in terms of business logic want to write business logic. You don't need to write your own compiler (it's weird that this became the thing I supposedly suggested), but you do need to develop good abstractions and data structures that fit your domain to get your code looking more and more like just a spec in the domain language.

The "don't reinvent the wheel" people who want their programmers to just bang out repetitive API code all day aren't any closer to the business logic than I am. They just don't understand what makes good software, and they don't realize that the wheels that are available to them out of the box actually suck for their task and always need some modification.

Re: Enterprise Software Projects Killed the Software Developer

#136

Post by useful »

TeeMassive wrote: post #83
useful wrote: post #14

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…

For me elegant and clever means that 1) my code won't get in your way and 2) can be thrown away easily. In return I ask a bit more time so I won't self-couple my code with introspection magic or make it undebuggable with weird dynamic design patterns nor will I make wormholes to so that A can communicate with B. Deal?

deal. code should be written to be easily replaceable, not extendable

to me, more often than not, it means simple

Re: Enterprise Software Projects Killed the Software Developer

#137

Post by burnished »

runawaybottle wrote: post #37
burnished wrote: post #31

Earlier quoted context omitted.

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 ove…

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.

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.

Re: Enterprise Software Projects Killed the Software Developer

#138

Post by 908B64B197 »

baobabKoodaa wrote: post #131
lycopodiopsida wrote: post #129

Earlier quoted context omitted.

But where do we draw the line? If someone does not understand the idea behind interfaces or proper exception handling, who is to blame? If you write Java and Streams are the natural solution, but the developer you work with never bothered to look them up, because they are "complex" and "FP-something"? These are polemic examples, but there is a line where sticking to the lowest common knowledge will hurt your best dev…

> But where do we draw the line? Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you t…

> If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers.

There's a secret third option: The organization could just hire good devs.

Re: Enterprise Software Projects Killed the Software Developer

#139

Post by baobabKoodaa »

908B64B197 wrote: post #138
baobabKoodaa wrote: post #131

Earlier quoted context omitted.

> But where do we draw the line? Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you t…

> If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. There's a secret third option: The organization could just hire good devs.

> There's a secret third option: The organization could just hire good devs.

That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.

Re: Enterprise Software Projects Killed the Software Developer

#140

Post by pojzon »

baobabKoodaa wrote: post #139
908B64B197 wrote: post #138

Earlier quoted context omitted.

> If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. There's a secret third option: The organization could just hire good devs.

> There's a secret third option: The organization could just hire good devs. That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.

The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.
Post reply on HN