Interviewer = I, Me = M

I: What is your project all about?

M: It is about reading data from memory of a program and transfer it to output register via a dedicated bus attached inside CPU and then projecting data of registers onto LCD crystals of display.

I: Can you show the working of your project?

M: Runs "hello world" program

Me - 1, Interviewer - Slap on my cheeks with shoe in one hand.

Those living in Sydney know there's an app called Opal you can use to navigate public transport.

Part of this is app is a trip planner which can suggest the fastest route to your destination, and is aware of train and bus movements in real-time (supposedly)

Me: Fastest route from station T to station C
App: In 5 minutes, walk 12 minutes to station M and board train. You will arrive at your destination by 20:12

5 minutes later...
Me: Fastest route from station T to station C
App: In 1 minutes, board train. It is the same train that will arrive at station M in 12 minutes. You will arrive at your destination by 20:12

Am I going mad, or does they algorithm stink?

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.

!rant

Just did some really satisfying refactoring. Much happier with my work now. Its a little cli app to poll M-bus devices and write the data to file if the user wants. Can scan the whole range, search for specific devices and VIFE codes, parse an input file for lots of the previous data and one or two other things.

How's everyone's else's weekend?