Live data from Hacker News

Enterprise Software Projects Killed the Software Developer

javahippie.net

51–60 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#51

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…

We must've worked with the same architects!

Re: Enterprise Software Projects Killed the Software Developer

#52
post #12
post #5

Earlier quoted context omitted.

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…

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"

Yeah. That's a trivial case but I'd still probably use parentheses). For more complex precedence operations I definitely would.

Re: Enterprise Software Projects Killed the Software Developer

#54
There was that interview with Peter Norvig - 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.

Re: Enterprise Software Projects Killed the Software Developer

#55

Earlier quoted context omitted.

"Let's not use inheritance, it's complicated and could confuse programmers. Better to just copy-paste code." "Source control? I don't know, this git command line is a little bit too much. Let's just use zip files and email the source"

That is not what I am suggesting, but alas, you seemed to have proven my point. I did not write clearly enough, and behold the outcome. Now imagine if we all do this in a codebase.

Your writing was fine. HN is big enough that you can't take a single critical comment as strong evidence you were unclear. Maybe it's them, not you.

Re: Enterprise Software Projects Killed the Software Developer

#56

Earlier quoted context omitted.

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…

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.

Re: Enterprise Software Projects Killed the Software Developer

#57

Earlier quoted context omitted.

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…

"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!

Re: Enterprise Software Projects Killed the Software Developer

#58

Earlier quoted context omitted.

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.

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…

I think the hidden message in your comment is "duplication over abstraction" - and I agree! Often duplicating things is preferable to complicated abstractions.

Re: Enterprise Software Projects Killed the Software Developer

#59
post #20

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

It's probably because Agile devolved from a system teams use to keep track of developer progress on bugs and features to some weird cult lead by managers who have 20 hours of meetings a week and can't begin to describe half of the projects they're meeting about.

Re: Enterprise Software Projects Killed the Software Developer

#60
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…

Excellent comment. This is true, and I think golang embodies the idea (or attempts to). Enterprise wants consistency over anything else. That said, there is a type of cleverness that can be brought to bear on Enterprise systems that, for example, take a simple, unidirectional data flow into account - something that is rather abstract, but which can and will thwart lots of complexity down the line.

Can you elaborate a bit on the golang part? As someone who dabbled with Go but never found it too alluring when comparing to other options (if I wanted ease-of-use I'd go with Python, if I wanted performance I'd go lower level - C++/Rust), I'm interested what you mean by it. Go did find a footing in the industry and a lot of cloud infrastructure relies on it, I do think it's the most interesting option out of compiled garbage-collecting languages.
Post reply on HN