[HN Gopher] Enterprise Software Projects Killed the Software Dev...
___________________________________________________________________
Enterprise Software Projects Killed the Software Developer
Author : javahippie
Score : 89 points
Date : 2021-08-30 13:36 UTC (9 hours ago)
(HTM) web link (javahippie.net)
(TXT) w3m dump (javahippie.net)
| lamplovin wrote:
| 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 time to help others
| understand what's going on is how teams get to the point of
| depending entirely on 2 people to do all their
| enhancements/fixes.
| 908B64B197 wrote:
| 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.
| pojzon wrote:
| 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.
| runawaybottle wrote:
| What if the NYTimes had journalists that described the news
| in their specific prose or worse, poetically. Speak plainly,
| it's the news, report it as plainly and accurately as
| possible.
|
| Often many people like to attach mathematics and science to
| Software Engineering to _signal_ elitism, but truthfully this
| profession is a lot closer to writing. Write clearly, first
| and foremost, and above all else.
|
| $outsourced_bodyshop_ressource_0443434 needs to be able to
| read the news too.
| xupybd wrote:
| I'm starting to notice a correlation between my prose and
| my code. Writing has not been my strength and I've quietly
| worked on it. Learning to organize my thoughts to best
| communicate with others has enabled me to organize my code
| for others to read. I've found this has improved the
| maintainability of my code. I wish I had put more effort
| into writing through out my schooling and early career.
|
| I've noticed that the most successful business people I
| know are good at written communication. Much like
| programming often the better communicators write less to
| achieve more.
| danielovichdk wrote:
| Great comment. Thank you
| 908B64B197 wrote:
| "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"
| runawaybottle wrote:
| 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.
| andrewflnr wrote:
| 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.
| 908B64B197 wrote:
| What were you suggesting?
| geoffjentry wrote:
| > that's easily understood by others reading it?
|
| The problem in these discussions always comes back to "others"
| aren't a monolithic entity. Different people find different
| things to be readable vs not. Different people will even use
| the exact same phrases (e.g. "as concise as possible without
| being opaque!") but still mean different things due to having
| different interpretations of key words in those phrases.
| derekp7 wrote:
| 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 the code more concise. But that is also
| harder to read for someone who hasn't picked up on them yet
| (which may have been the case when they were first introduced).
| lamplovin wrote:
| I agree with you on language syntax choices, but as far as
| the articles examples are concerned it seemed like the
| "clever" solutions to them were more about OO architecture
| choices via abstraction for example. In which case, if it's
| not a codebase that you have experience in, then those
| architecture choices can get very confusing if not properly
| documented
| tejtm wrote:
| 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"
| jaywalk wrote:
| The order of operations doesn't change because the equation
| is written out in English versus mathematical notation.
| foobar2021 wrote:
| How do you say and/or spell out parentheses?
| [deleted]
| elzbardico wrote:
| Easy: Take two plus five and multiply it by six
| ghaff wrote:
| Yeah. That's a trivial case but I'd still probably use
| parentheses). For more complex precedence operations I
| definitely would.
| windows2020 wrote:
| 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.
| blacktriangle wrote:
| 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.
| windows2020 wrote:
| How will they learn to better express logic or master the
| language without experience?
| watwut wrote:
| 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.
| windows2020 wrote:
| From a syntax perspective, I would argue the grammar of a
| language does make it apparent.
| jcelerier wrote:
| You're generally not supposed to think about grammar
| rules when you read or write a language you know (code or
| prose)
| qznc wrote:
| > 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?
| 0xbadcafebee wrote:
| You'll never see a purely Agile or Lean product from an
| Enterprise, because those don't have a clearly defined set of
| expenses, profits, and timelines.
|
| One terrible thing about Enterprises is the way their finance
| team leads product decisions. In order to maximize their profit,
| they announce a product will be ready by X date, and estimate the
| cost leading up to it. If you don't hit those numbers, it affects
| a lot of other numbers, especially if you're publicly traded. And
| that's before the wild promises Sales makes. They are
| preternaturally addicted to arbitrary deliverables.
|
| Essentially, their products are projects, and the customers are
| incidental to the whole thing. There is no estimate for customer
| happiness in the business case for a new product team. If you
| build it on time and under budget, everything else (getting a
| customer to use it and like it) is taken for granted.
| toxodont wrote:
| 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.
| thinkharderdev wrote:
| 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.
| useful wrote:
| 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.
| [deleted]
| zozbot234 wrote:
| 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.
| slownews45 wrote:
| 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,
| runtime complexity at code comment at top of function (ie,
| O(1), O(n), O(n^2)) some reasonable comments, error handling,
| done. Throw in some unit tests if desired.
| winrid wrote:
| I think the hidden message in your comment is "duplication
| over abstraction" - and I agree! Often duplicating things
| is preferable to complicated abstractions.
| rightbyte wrote:
| 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.
| slownews45 wrote:
| 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.
| thinkharderdev wrote:
| "Reflection, endless hierarchies, complexity on complexity"
| sounds like the exact opposite of "elegant properly
| engineered code"
| slownews45 wrote:
| 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!
| javajosh wrote:
| 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.
| IceNotNice wrote:
| 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.
| Clubber wrote:
| >If developers are prohibited from writing native SQL, they will
| be limited by HQL, writing slower queries or needing multiple
| queries from their application for one task.
|
| We use a similar framework, but we create custom views when we
| need performant retrieval, or the hydration of a big object graph
| is being done and not needed (like a grid).
|
| >If the exact language, framework, libraries are prescribed in
| every detail, developers sometimes need to bend these tools to
| solve their requirements instead of using the right tool for
| their problem. If the layered architecture is to be zealously
| followed, 50% of your code will be the mappers between the
| layers.
|
| We use automapper, which does exactly what it says. We manually
| map one-offs. In fact, that's the basic philosophy of this
| design. Have the framework build everything from the entities,
| then one-off what you need.
|
| Our design is generic so every table has an entity, then we use a
| generic service layer with your normal CRUD + search functions,
| then our controllers are auto-generated using the same thing. We
| do custom work only for one-off stuff that either is more complex
| than CRUD, or requires higher performance. It's cut our
| development time significantly, since for normal crud work, it's
| auto-generated based on the entity itself. You create the entity
| and dto's and the repository, service layer and controller are
| all auto-constructed using generic code. If you need something
| special, you create a custom controller/service. We tend to leave
| the repositories generic. Note this is just for the WebAPIs,
| front end is a different monster.
| rullopat wrote:
| Have you ever had a person in your team "so clever" that as soon
| as he/she learns a new feature of the language, they use it
| everything to look even more clever? Most of them are in love
| with genetics/templates, I call them "the code masturbators".
| trhway wrote:
| what doesn't kill us makes us stronger.
|
| > Personally, I have never seen SCRUM or any agile approach
| working in a project setup ever.
|
| they work great. Just their goal isn't successful delivery of the
| project (on that aspect they fail spectacularly). The goal of
| SCRUM/Agile/Lean - ie. what they are designed for - is extremely
| low latency and high observability by the management (and thus
| the management just loves it, total micromanagement under the
| guise of team freedom). That all comes naturally at a great cost
| of throughput. I.e. the "watched pot" situation. The project
| direction is changed very fast, there is a lot of activity, the
| bees are overly busy, the management always know and able to
| report the current progress state, while the project is hardly
| really moving toward the actually successful state.
| codingdave wrote:
| 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.
| jkingsbery wrote:
| I had the same reaction. I've spent most of my career working
| on non-consumer-facing software (either internal enterprise, or
| external to enterprises or small-medium businesses). At all the
| places I've worked, the team that built software was the one
| that would go on to operate it - there was no hand-off. Then
| again, I've never worked in consulting, nor worked on teams
| that used consultants to deliver code. Many of the points the
| article raised are good ones, it's a shame that the title is so
| misleading (or at least, reflects a narrow experience).
| mousepilot wrote:
| this is written like its bad to "hand over code" to others. I
| don't like it.
| burnished wrote:
| 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 over
| code is bad, but that a team should maintain responsibility for
| a product over time (because they can take advantage of their
| domain knowledge) instead of handing it over (like it was a
| finished product, when it isnt).
| knightofmars wrote:
| 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.
| runawaybottle wrote:
| 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.
| avmich wrote:
| 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.
| commandlinefan wrote:
| > 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" environment. I really wish they had
| actually called that out in the manifesto itself and made that
| more obvious.
| jitter_ wrote:
| 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.
| Jensson wrote:
| 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".
| MisterBastahrd wrote:
| 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.
| cabernal wrote:
| Could you expand on this? A fixed deadline can mean fixed
| budget, which the majority software projects fall under.
| Raidion wrote:
| 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 sprints, and you have execs needing new thing for
| contract launch in X weeks, and guess who wins? It's not the
| software developer, so the agile becomes toothless, because
| you're not learning, or iterating. You're just pushing
| against a gantt chart the whole way a sprint at a time, and
| might not even be able to release beta versions and get
| feedback, because that takes up valuable time.
|
| I'm not as cynical as OP, but there is a really big push/pull
| that happens, and it can turn into a toxic environment if
| forces too far outside the product/development cycle dictate
| priorities (like sales, or execs).
| wavefunction wrote:
| 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.
| mirekrusin wrote:
| 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.
| orthoxerox wrote:
| We must've worked with the same architects!
___________________________________________________________________
(page generated 2021-08-30 23:01 UTC)