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

121–130 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#121

Post by AstralStorm »

lamontcg wrote: post #73
slownews45 wrote: post #57

Earlier quoted context omitted.

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!

That isn't properly engineered code. And if you dig into all that code usually the designer didn't understand those tricks and patterns as well as they thought they did and were trying to teach themselves along the way. You can often throw away 3/4 of the code, throw away 3/4 of the "requirements" which aren't being used and wind up with something that is actually simple and elegant and solves the problem, but doesn'…

Such features to throw away /s

(You must not actually remove any of them. Enterprise jokers will want all of it.)

- security (the most forgotten until it bites you)

- GUI flow complexity (client requirement you cannot touch)

- distributed state management with logical consistency guarantees (horizontal scaling)

- ability to quickly adapt for new features

- schema upgrade capability (see above)

- advanced database queries

- event reactivity and/or scheduling (logging, security, notifications)

None of the above is quite actually given to you on a silver platter by any one library really, it a combination thereof, and they're rather hard to grow bottom-up organically.

Re: Enterprise Software Projects Killed the Software Developer

#122

Post by smoll »

feoren wrote: post #113
FranksTV wrote: post #99

Earlier quoted context omitted.

Everyone has seen elegant and clever code, but it's really not necessary when you're writing a CRUD API.

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 problem and ones who are more interested in solving technology problems. I know that when you get to a later stage as a company you need both kinds of engineers, but at an earlier stage company you have to ensure all of your engineers are of the former kind and not the latter kind or you will probably not succeed.

Re: Enterprise Software Projects Killed the Software Developer

#123

Post by dirkt »

jitter_ wrote: post #20
commandlinefan wrote: post #7

> 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" e…

I've always been bothered by the (sometimes massive amount of) hate that I see in the internet towards agile. The experiences from other developers always seem a bit off, like something is not right. I think your point might be the missing piece. Agile might not mix too well with fixed timeframes or fixed budgets, but rather needs an environment of continuous development where the requirements have room to drive the…

> hate that I see in the internet towards agile

The reason is that enterprise implementations of "agile" are often the opposite of agile: waterfall with no frequent releases nor customer feedback, but lip service to agile practices and middle management ceremonies.

If you go through the agile manifesto and compare, these implementations violates all the points listed.

Re: Enterprise Software Projects Killed the Software Developer

#124

Post by rswail »

jitter_ wrote: post #20
commandlinefan wrote: post #7

> 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" e…

I've always been bothered by the (sometimes massive amount of) hate that I see in the internet towards agile. The experiences from other developers always seem a bit off, like something is not right. I think your point might be the missing piece. Agile might not mix too well with fixed timeframes or fixed budgets, but rather needs an environment of continuous development where the requirements have room to drive the…

"agile" (the manifesto) was stating the obvious for people working on a product that had a lifetime longer than a "project". It works for products that have an ongoing life.

What it doesn't work with is environments with projects and budgets that are quarterly or annually assigned. That's where abominations like "scaled agile" have arisen.

Scaled Agile (TM) and Scrum and all the rest of the ceremony are like ORMs are to SQL database, an attempt to correct the impedance mismatch between the way software teams work and the way companies work.

Re: Enterprise Software Projects Killed the Software Developer

#125

Post by Fiahil »

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…

I work as a consultant, and we are also looking for talented people interested by solving business problems.

We actively avoid the technology-focused kind, because we know they will not be able to adapt to the work we do. To be honest, we write a ton of CRUD apps, but anyone who would come and say "let's write a compiler" is guaranteed to get funny looks. Even if you are extremely talented and can deliver to the same pace as we traditionally do, you will probably fail to consider one or two "little" things that would turn out to be fundamental requirements! Nobody is impressed by half-working cleverly written software.

Re: Enterprise Software Projects Killed the Software Developer

#126

Post by baobabKoodaa »

pojzon wrote: post #119
1270018080 wrote: post #104

Earlier quoted context omitted.

Are you the good guy in this story? Writing code that no one else can understand unless they've read multiple books to push through the complexity? Do you write in Java by chance?

Good guy? Depends how you define that. And it would be challenge to write infra code in java..

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

Re: Enterprise Software Projects Killed the Software Developer

#127

Post by culopatin »

feoren wrote: post #91
culopatin wrote: post #85

Earlier quoted context omitted.

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, b…

> how much of your code do you actually fully understand vs how much is just copied from somewhere? 100% is fully understood. Every single line. A very small percentage is copied from somewhere (usually adapted in some way), but even then: I understand every single line. And I expect the same of everyone on my team. If I'm doing a code review and someone says "I don't know; I found this code online" it does not go ov…

Well as I said I don’t have enterprise experience but from what I see, all the stuff that is not 100% creativity of a new process seems to be tying libraries together.

I’m learning spring because my company is Java heavy and I’m hoping to do a lateral move there. The whole thing is an arbitrary rule set that the library writers agreed upon. Yes there are many concepts of OOP involved but I watch tutorials and the guy says “you need to write auth.userDetailsService and I can only think “yeah, great but how did you get to that conclusion? Where is the hidden recipe book I’m not seeing? How was I supposed to figure that out if I wasn’t following this tutorial?”

Re: Enterprise Software Projects Killed the Software Developer

#128

Post by culopatin »

HillRat wrote: post #100
culopatin wrote: post #85

Earlier quoted context omitted.

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, b…

To be honest, you’re doing the right thing: you should stop and try to figure out where things come from, why they’re there, and what they’re doing. Usually, if you’ve got “magic coupling” from a framework, that’s the part that’s going to bite you or it’ll be where you need to dig in for some critical piece of functionality. It’s not unusual for reflection-, plugin-, or attribute-heavy code (and I’ve abused all those…

All the answers I’m getting are actually confirming my theory.

For vanilla code I get it. Vanilla Java I can totally understand where things came from and why. It’s the libraries that get me. How am I supposed to know that the library expects X? Is a very common question I have.

I understand it at the end but that’s because someone’s given me the answer. But I couldn’t derive that by deduction if I wanted to because I didn’t even know that was a thing.

And all the guys giving the tutorials seem to be running off their memory but they don’t tell you how they figured it out

Re: Enterprise Software Projects Killed the Software Developer

#129

Post by lycopodiopsida »

baobabKoodaa wrote: post #126
pojzon wrote: post #119

Earlier quoted context omitted.

Good guy? Depends how you define that. And it would be challenge to write infra code in java..

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 developers by either sucking the joy out of their work or by forcing write them a lot of boilerplate code. And I've heard of teams, where the whole team would ban features of a new standard of the language, because they've written code for 20 years without them before.

Re: Enterprise Software Projects Killed the Software Developer

#130

Post by aahortwwy »

jitter_ wrote: post #20
commandlinefan wrote: post #7

> 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" e…

I've always been bothered by the (sometimes massive amount of) hate that I see in the internet towards agile. The experiences from other developers always seem a bit off, like something is not right. I think your point might be the missing piece. Agile might not mix too well with fixed timeframes or fixed budgets, but rather needs an environment of continuous development where the requirements have room to drive the…

> The experiences from other developers always seem a bit off, like something is not right.

That's the point.

Agile is difficult to do exactly right. When done wrong my perception is that is produces far more dysfunction and stress at an individual level than alternative project management methodologies.

If you've heard the fitness saying, "the best workout plan is the one you stick to," my feelings about project management are pretty similar. Agile may be great, but if your organization isn't capable of sticking to its central ideas then it's just not going to work. In that situation you're better off picking a methodology that's less efficient but easier to implement (like waterfall).

There are also some fundamental challenges presented by the methodology that are genuinely difficult to deal with. These tend to be ignored and then they manifest as dysfunction elsewhere in the system.

Post reply on HN