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

11–20 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#11

Post by windows2020 »

lamplovin wrote: post #3

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…

IME, writing code as concise as possible (semantically and syntactically) is almost always the best route. I don't believe superfluous assignments, parenthesis, braces, visibility modifiers or comments make things more easily understood by others. In time, experience and mastery of the language will reveal superfluous code as something that does the opposite as well as much cleverness as mere utilization of the language or abstraction.

Re: Enterprise Software Projects Killed the Software Developer

#12

Post by tejtm »

derekp7 wrote: post #5
lamplovin wrote: post #3

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…

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"

Re: Enterprise Software Projects Killed the Software Developer

#13

Post by codingdave »

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.

Re: Enterprise Software Projects Killed the Software Developer

#14

Post by useful »

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.

Re: Enterprise Software Projects Killed the Software Developer

#15

Post by blacktriangle »

windows2020 wrote: post #11
lamplovin wrote: post #3

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…

IME, writing code as concise as possible (semantically and syntactically) is almost always the best route. I don't believe superfluous assignments, parenthesis, braces, visibility modifiers or comments make things more easily understood by others. In time, experience and mastery of the language will reveal superfluous code as something that does the opposite as well as much cleverness as mere utilization of the langu…

That's the key...in time.

In time doesn't help when the majority of your devs are junior which is a common case in large internal dev shops.

Re: Enterprise Software Projects Killed the Software Developer

#16

Post by watwut »

windows2020 wrote: post #11
lamplovin wrote: post #3

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…

IME, writing code as concise as possible (semantically and syntactically) is almost always the best route. I don't believe superfluous assignments, parenthesis, braces, visibility modifiers or comments make things more easily understood by others. In time, experience and mastery of the language will reveal superfluous code as something that does the opposite as well as much cleverness as mere utilization of the langu…

Strongly disagree. Working on codevase that was written by "short is better" people was harder and I hated it.

I don't care for your saved strokes. Make it apparent.

Re: Enterprise Software Projects Killed the Software Developer

#17

Post by javajosh »

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…

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.

Re: Enterprise Software Projects Killed the Software Developer

#18

Post by qznc »

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

Re: Enterprise Software Projects Killed the Software Developer

#19

Post by [deleted] »

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…

[deleted]

Re: Enterprise Software Projects Killed the Software Developer

#20

Post by jitter_ »

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 project within wide enough budgetary boundaries.

This to me feels sort of a natural way to build things. If we need something we build it, otherwise we don't. And those "needs" might pop up at any time, by external (customer requests etc.) or internal (new techical requirements become apparent as the project is being developed) events.

My experiences of agile development have been from companies without deadlines and are generally positive.

Post reply on HN