4 ms·
Well, FWIW I have to use all the things you were proposing. However I find them eminently crappy and if I were in a position at my workplace to reject them I wo
by geodel 4y ago
Well, FWIW I have to use all the things you were proposing. However I find them eminently crappy and if I were in a position at my workplace to reject them I would have absolutely done that.
> I took an unmaintainable pile of bugs and made it stable and maintainable.
Same here, except it was supposedly using all best practices e.g. Spring Boot, DI/IoC, Mock testing framework, YAML configs, extremely elaborate package hierarchy and so on. The only thing it did not have was working solution for the business problem it was written for.
- yarg 4y agoIn the case of Spring what I wanted was adequate dependency injection. I was dealing with having to support releases across multiple historical branches, and wanted to separate the core and business logic to allow for easier support on the older branches. I needed the dependency injection in order to break up cyclic dependencies across modules (without which the core and client logic could not be broken into separate repositories). Internally, the deployment tooling treated the profile as hierarchical; when I took over the project it was already using dynamically generated keys to store trees of data in the .properties files it was using for user profiles. It only became more hierarchical as time went on and the internal representation fully so - using a tree structure internally allowed for very clean subtree selects (which helped to clean up an entire class of bug, introduced on mass, during a particulary ill advised (and strongly advised against) piece of work (completed (despite being given without notice) in a single iteration - when it really needed at least 2). I would still have preferred to use an external format that allowed me to specify or generate schemas for the user profiles, and it also would have helped with supporting profile versioning (which would have been valuable for company internal users).
- bitexploder 4y agoThe one thing agile is aimed in the right direction about is that software is for users. Users use it to create value in a business context. Many developers are too far removed from value creation and making sure their features and design changes will actually benefit users in the long run. Tech debt is a thing, but so is business value driven development that works well for users. All of these refactoring side treks need to really be necessary. I do greatly empathize with grandparent, lack of being seen and acknowledged really sucks. And who knows what their situation really was like.
- TeMPOraL 4y agoLet's be clear on who the users are, then. In general, I see several different broad groups of stakeholders: 1. The developers who create the software. 2. The rest of the company developers work for, and possibly other people in other companies - who all make money selling or renting the software. 3. The actual users stuck with the software. I'm not sure if Agile meant 3 > 1 and 2, or just pretended to, but actually meant 2 > 1, but your comment does read as advocating for 2 > 1 > 3, which is arguably the current industry standard.
- tharax 4y agoAre you me? Our services with all the best practices are also the worst to work on because the business value is hidden in layers and layers of indirection, abstraction and nested packages. It’s like someone took a recipe card to bake a cake and wrote each word on a single page (because god forbid we ever repeat ourselves) and then abstracted away a function behind a series of factories and interfaces that will join those pages with string, and now each word has a single context-less definition so we can tick the “S” box in SOLID.
- throw827474737 4y agoHahaha, everyplace everywhere. I think two things play into this: Layers.. it is just easier for people to add layers around something, not touching and understanding the original code and doing it right there. And then profs or someone else always says layering is good! (It may sure be, or also sometimes such "hacks" are the right thing to do, but if that is always the default mode... uhh oh). And second, university training: OOP, design patterns, software layers, all claimed to lead to structured good programming automatically still taught in 2023, which is just not true. By untrained or unexperienced personnel leads to worse than 80s spaghetti code.. Just yesterday I exercised with relative who is in university for exam.. Java, design patterns, arggh. Imo it just makes no sense at all to try to teach students inheritance and design patterns with Cat/Dog/Animal et al, it is so backwards. You need to program for a while bigger real systems to see some patterns emerge and their usefulness, and then can relate to the formal way and maybr use some patterns reasonably. But starting with those on toy examples just leads to what you describe: People going in with their trained knowledge and applying that to everything without rhyme or reason. What could be a simple five liner function already becomes a convoluted abomination. Just one concrete example, but this then on many levels of software engineering. Who or what will save our future? :D No, it won't be ChatGPT. (Second lol btw, relative really showed me how likely all of then may use ChatGPT i. their online exams...)
- jen20 4y agoProbably the mainstream adoption of functional programming, if anything can save our future. Most people do not have the memory span to work with mutable state, so something simpler should be the default.