Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
You don’t have a “Brent” problem. You have a organizational structure problem. You don’t appear to have functional teams, those teams don’t appear to be responsible for supporting their crappy shit, and no one is testing effectively.
If everyone on multiple teams is responsible for quality for one repository, then no one is.
Agile, or better yet Lean, documentation is minimal. As soon as it’s in the Wiki it’s obsolete unless it’s just focused on principles and practices. Application documentation should be in the repository README.md or, best yet, written as functional tests.
Again, Brent isn’t your problem. You’ve no constraint like that. What you have is chaotic development. That needs to be fixed first. -
@yamatoman we're a single team but the app is very large. Don't even get started about other teams we need to deal with...
But take 1 project for example, there's like 50 packages, 1000s of source code files.
We have JIRAs and whoever is assigned the ticket makes the change/feature.
That maybe the problem. But basically there's 1 entry app and it runs all other apps (Spring configs, DI setup).
New process? Add a new package. It may use some common components or create new ones.
Another example, some of the code I wrote a year ago. I come back to it and now the logic had changed, there some new usage, requirement added.
But I dunno what or why and now I need to melee a change. -
My conversations with my boss tend to be like:
-ask ... about... He should know
-oh he left, you'll have to see what you can find from the source code and wiki
-work with the business to figure out where wrong with ... And fix it
And so a lot of things get out on hold or I there's a lot of time spent doing required or I think stepping on top of each other.
Lately been getting the feelings of move fast and break things, shoot first ask questions later, bring in the Wild West where everything is always changing. I leave something for a month come back and now it's broken for some reason...
And getting information feels like squeezing out of an almost dry rag... Where really this info should be written down and in plain sight... -
Feel your pain. Been there and it takes a push from devs and upper management to fix. On my old team, we focused heavily on application and test design to make sure that we protected ourselves from chaos when timelines compressed. One of my old team members moved to a company on the east coast that’s a startup that doesn’t test shit. He’s now living a nightmare and wishing he hadn’t had to leave. What it sounds like, and correct me if I’m wrong, is there’s no real design. You have a giant entangled monolith with minimal real testing. Processes are pretty manual, and the team is either bigger than 10 people, doesn’t know what “good” is, or just doesn’t give a shit. All of those situations suck. You can try to start changing it. Bring in hygienic coding practices, BDD, TDD, C4 design, etc. keep pushing. Get management support. If that doesn’t work, we’re hiring people who give a shit. :)
Regarding the readme: yes, commit to version control with the source. See every good OS project ever. -
@yamatoman thanks, pretty much what I feel. (actually rereading my reply, so many typos, amazed you actually understood it). A lot of manual stuff, and I'm probably slowing down as well... My last team I ended up being the only dev so owning the whole code base (4 medium apps), I cleaned up and automated so much, there wasn't much left to do by the time I was transferred.
When I first joined my current team, I told my manager and his manager... read The Phoenix Project AND follow it.
I remember a bit of BDD and TDD (I m usually the only person that "yells" at business ppl and my boss to specifically define their use cases with real inputs and desired outputs). I prefer not having to change the whole design halfway thru when all the specs suddenly change because now they have a "better" idea of what they actually wanted... but the deadline is still the deadline...
Not familiar with C4, will take a look. The other problem is the senior devs (their code quality leaves much too be desired) are too busy to review jr devs code.
There's no time for code review and i m not in a position to demand change. but the original problem is still lack of docs so ppl can get up to speed quickly when needed.
Some days I feel, i m going at 10x coding what i need, then i m suddenly given a Prod issue (because i m the guy that seems to be able to figure out anything) but because I have to dig thru stuff, i slow down to .5x... and all my plans for the day go poof... -
@billgates you have terrible management. Company I work for has pockets like that and pockets like mine. Being a fortune 5 company, we pretty much have everything, really. I’d find someplace that meets your standards. Life is too short to be prevented from reliving something you’re proud of.
-
@yamatoman the other part I think is that ppl should be made to clean up their own shit... Otherwise they'll keep making shit...
I tried looking for better but not much luck get stuck on technical interviews and not being a good fit.
Never really understood technical interviews much... what's so good about knowing how a Tree works when you'll never use it (even when you should) on the job... And ur code looks like shit...
Nowadays I'm sorta shifting I guess, spends more time on life than work... Just need to work to pay the bills... -
@billgates I work to pay for hobbies. Don’t believe in the cult of “all good coders do nothing but code”. There’s better out there. Takes looking to find it. Yes, most tech interviews are stupid.
Long post, TLDR: Given a large team building large enterprise apps with many parts (mini-projects/processes), how do you reduce the bus-factor and the # of Brent's (Phoenix Project)?
# The detailed version #
We have a lot of people making changes, building in new processes to support new flows or changes in the requirements and data.
But we also have to support these except when it gets into Production there is little information to quickly understand:
- how it works
- what it does/supposed to do
- what the inputs and dependencies are
So often times, if there's an issue, I have to reverse engineer whatever logic I can find out of a huge mess.
I guess the saying goes: the only people that know how it works is whoever wrote it and God.
I'm a senior dev but i spend a lot of time digging thru source code and PROD issues to figure out why ... is broken and how to maybe fix it.
I think in Agile there's supposed to be artifacts during development but never seen em.
Personally whenever i work on a new project, I write down notes and create design diagrams so i can confirm things and have easy to use references while working.
I don't think anyone else does that. And afterwards, I don't have anywhere to put it/share it. There is no central repo for this stuff other than our Wiki but for the most part, is like a dumping ground. You have to dig for information and hoping there's something useful.
And when people leave, information is lost forever and well... we hire a lot of monkeys... so again I feel a lot of times i m trying to recover information from a corrupted hard drive...
The only way real information is transferred is thru word of mouth, special knowledge transfer sessions.
Ideally I would like anything that goes into PROD to have design docs as well as usage instructions in order for anyone to be able to quickly pick it up as needed but I'm not sure if that's realistic.
Even unit tests don't seem to help much as they just test specific functions but don't give much detail about how a whole process is supposed to work.
question