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

41–50 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#41

Post by knightofmars »

burnished wrote: post #31
mousepilot wrote: post #2

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

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…

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.

Re: Enterprise Software Projects Killed the Software Developer

#42

Post by rightbyte »

slownews45 wrote: post #38
zozbot234 wrote: post #36

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

Re: Enterprise Software Projects Killed the Software Developer

#43

Post by wavefunction »

Raidion wrote: post #26
cabernal wrote: post #10

Earlier quoted context omitted.

Could you expand on this? A fixed deadline can mean fixed budget, which the majority software projects fall under.

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…

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.

Re: Enterprise Software Projects Killed the Software Developer

#45

Post by thinkharderdev »

slownews45 wrote: post #38
zozbot234 wrote: post #36

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…

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

Re: Enterprise Software Projects Killed the Software Developer

#46

Post by pojzon »

908B64B197 wrote: post #9
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…

The real problem is that the while the same code might look obvious to John Carmack, it might not look obvious to $outsourced_bodyshop_ressource_0443434. Then you start coding for the lowest common denominator.

Recently we hired a consultant for our infrastructure. I wrote the code for that infrastructure using best practices I learnt from books, workshops etc.

While some ppl from my team have huge issues understanding it, the consultant read it ONCE and knew everything. He was simply a good dev that had a pleasure working for other big shops that wrote the books I read and lead those workshops I attended to.

So its like always a matter of „Do I hire cheap HR resource or an expert?” question.

Nothing more, nothing less. The issue with writing smart code is that there is not a lot of smart devs. Thats why we always derotate to lowest denominator.

Re: Enterprise Software Projects Killed the Software Developer

#47

Post by thinkharderdev »

toxodont wrote: post #4

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.

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.

Re: Enterprise Software Projects Killed the Software Developer

#48

Post by Jensson »

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…

How would your team motivate that it should keep its headcount during a budget cut? Without deadlines they could just say "Since nothing you do is urgent we will cut your headcount in half, other teams needs it more".

Re: Enterprise Software Projects Killed the Software Developer

#49

Post by 908B64B197 »

runawaybottle wrote: post #35
908B64B197 wrote: post #32

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.

What were you suggesting?

Re: Enterprise Software Projects Killed the Software Developer

#50

Post by mirekrusin »

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.
Post reply on HN