[HN Gopher] But what about the bus factor?
___________________________________________________________________
But what about the bus factor?
Author : agustif
Score : 56 points
Date : 2021-12-02 14:40 UTC (3 days ago)
(HTM) web link (www.michaelbromley.co.uk)
(TXT) w3m dump (www.michaelbromley.co.uk)
| dpeck wrote:
| Also not to be forgotten is the inverse bus factor:
|
| The number of people who, if hit by a bus and incapacitated,
| would allow an initiative to move forward.
| projektfu wrote:
| I think a good approach for a company betting the farm on an
| external project that may stop being maintained (or may decide to
| head in a different direction) is to basically become expert in
| the project themselves. They should probably pin the version and
| be fully aware of new changes, and ready to modify the project to
| suit their needs.
| temptemptemp111 wrote:
| Imagine being the guy who was in charge of AMD/Intel backdoor
| private key & instruction backups! To all of you who belittle the
| issue of "management engines" being transparent blackbox OSs that
| you "could reverse engineer if you really wanted to, but it is
| probably nothing sinister."
| nomdep wrote:
| nitpicking: the _average_ bus factor cannot be 1 unless there are
| as many projects without maintainer as projects with two or more
| maintainers
|
| ...
|
| On second thought, the average bus factor might be less than one
| Jensson wrote:
| Count only core maintainers and I'd be surprised if it was
| above one, yeah. Companies ensuring they have no core
| maintainers by spreading everyone out essentially has a bus
| factor of 0 all the time, even on new projects.
| twobitshifter wrote:
| You're right, on the other hand I'd guess that the median bus
| factor is 1 and a better metric as this isn't going to be
| normally distributed.
| ChrisMarshallNY wrote:
| Almost every one of my projects has a bus factor of 1.
|
| That's OK, because most were written for my own use, in other
| projects.
|
| The one project that I wrote, that is used by thousands, around
| the world, has been taken over by a new team, and I hardly have
| anything to do with it, anymore. It took ten years, of running
| the project alone, to get to that place.
|
| In all my projects, these days, I develop them as if they are
| major corporate initiatives. I believe this makes it easier for
| others to use and understand (I also tend to use the MIT
| License).
| rurban wrote:
| He forgot to mention the Urban bus factor anti-pattern.
| (comparable to Brooke's Law. The more you add to a project, the
| longer it will take)
|
| The lower the bus factor, the better the project. Raising the
| bus-factor to fight the bus-factor will lead to worse projects.
|
| You can easily see that with popular open source projects. The
| more committers and managers you get, the more fighting, re-
| architecturing for the worse and harmful meta discussions how a
| project should be led. Eg COC. Good projects are usually led by
| 1, max 2. Everything above that is critical. If the one is hit by
| bus, another one can take over eventually. But not before. And it
| might need 10 years to find the one.
| csydas wrote:
| Death by committee is a real thing and it is a problem you need
| to architect around, but the answer to this is not to
| consolidate power. Instead, you build up a structure and system
| by which decisions can be made and a process that all members
| must abide by. If the core persons (the values of the bus
| factor) are unwilling to subject themselves to such a system
| and to work to design such a system, then the project will fail
| eventually under them, or it simply isn't such a great project.
|
| Implementing such systems is absolutely a challenge as there is
| negative feedback to such things all the time; designing such a
| system, putting persons in place whose job it is to enforce the
| process, putting persons in place to weigh in on if an action
| or decision matches the letter and spirit of the process, all
| of this take a lot of discipline and maturity from the
| participating members; I've done this with several orgs now,
| and even with backing from the VP level, at best I get
| belligerent participants, and truly I cannot tell if their
| resistance is that they don't like the decisions we make, or if
| they just don't understand the process and want the ability to
| complain to someone directly.
|
| Most of the issues you get with multiple stakeholders is
| because of a lack of discipline within the org; people who are
| too used to "just doing things" without really considering the
| full consequences of actions in favor of just doing what they
| want. You see this in basically every collective project, not
| just programming projects too. I consider it a win if we have
| people begrudgingly participating, but ultimately
| participating.
| wayoutthere wrote:
| > I've done this with several orgs now, and even with backing
| from the VP level, at best I get belligerent participants,
| and truly I cannot tell if their resistance is that they
| don't like the decisions we make, or if they just don't
| understand the process and want the ability to complain to
| someone directly.
|
| The belligerence is that there's very little benefit career-
| wise to being a good committee member on low-visibility
| committees. At best you get some nominal recognition, and at
| worst it's a distraction from the things that actually do
| further your career. Nobody gets a gold star for that kind of
| work, but you do get big promotions when you can own chunks
| of work yourself (even when done poorly).
| CorrectHorseBat wrote:
| Do you have any examples? In my experience projects with only
| one or two developers just move too slow and often stall for
| months or just die because they have other things to do in
| life.
| rurban wrote:
| We are talking about maintainers here, not developers or
| contributors.
|
| And if a project stalls, he/she probably considers it done,
| in opposition to others. You can easily extend such a project
| under your own maintainance then, but then you must be
| capable of maintaining it.
| lmeyerov wrote:
| most oss projects are 1-2 devs over many years, so easier to
| enumerate those that aren't ;-)
|
| ex: D3 was/is really mike bostock. the exception there has
| been, afaict, the GIS packages and maybe changed over last
| 1-2 years
|
| ex: we use 'got' for JS HTTP, and most dev is 1-2 devs moving
| quickly, and community for QA
|
| ex: caddy felt the same, but that may have also changed post
| acquisition
|
| interestingly, all 3 support plugins/galleries for occasional
| non core contribs
|
| the article was clever to observe that most commercial sw
| does bump up bus factor in a funny way: sustainable bump..
| but typically goes up by only a little!
| CorrectHorseBat wrote:
| How can one know these projects run so good because there's
| only a few devs and not despite? I was more thinking of an
| example of a project that failed because it had too many
| developers.
|
| An example of the opposite I thought of immediately is
| neovim. The vim dev didn't really want too much changes so
| the neovim fork took of, and eventually vim development
| sped up too.
| lmeyerov wrote:
| GitHub stats -- if I remember right, if a project lasts
| more than ~1 year, the odds are it'll keep lasting, and
| you can redo the exercise every year or two
|
| 'few devs vs despite' matters a bit less when picking:
| it's the results + future expectation, irrespective of
| how :)
|
| 'how' is interesting . having observed dedicated oss devs
| owning a proj for years vs contracted devs working
| through tasks for their latest gig, I have unsurprising
| theories. Trickier is when going sustainable via revenue
| (which we do), how to keep that sense of ownership, vs
| usual employee code: industry increasingly adopts OSS
| practices like GitHub flow, but that misses much of the
| OSS maintainer magic.
| ChrisMarshallNY wrote:
| I can tell you that, for myself, having one dev has
| _definitely_ resulted in _much_ higher Quality and a
| usable deliverable.
|
| Most of my OSS projects are 1-file UI widgets (but with a
| _lot_ more testing code than implementation code). I do,
| however, have a couple of monsters.
|
| Because of my experience (which includes _many_
| mistakes), I am able to develop projects of a far more
| ambitious scope than the run-of-the-mill developer. The
| one that I 'm working on now (not OSS), for example, is
| one that would usually be done by a heterogenous team.
| ZuLuuuuuu wrote:
| I am the developer which literally got hit by a bus, AMA!
|
| I miraculously survived the accident with many broken bones and
| got back to work in about 3 months. And now it puts a smile on my
| face whenever I see the term "bus factor". And it probably scared
| our company quite a bit because I was the only software engineer,
| so definitely a bus factor of 1. But our company is mainly not a
| software company so they managed to survive with minimal support
| from me until I got back.
|
| So yeah, it can happen! Be careful when crossing the street!
| PicassoCTs wrote:
| Im sorry for your accident, but it its a funny thing to imagine
| the upper echelon sneaking into the hospital, to install eye-
| tracking software and a beamer on someone who is almost a cast-
| mumy. Imagine waking up after a accident, and a nervous intern
| sits besides you, instead of a loved one, trying to coax the
| passwords out of you before you pass.
| yakubin wrote:
| This reminds me of the beginning of "The Da Vinci Code".
| jacquesm wrote:
| Glad to hear you're ok!
|
| If you see enough companies over a long enough time these risks
| materialize with great regularity. Common reasons: burn out
| (probably #1), underpaid and undervalued so easily 'poached' (I
| don't like that term but don't have a better one),chronic
| illness, accidents, death. The latter is fortunately rare, two
| instances across 200+ companies across 15 years.
|
| But the other ones happen frequently enough to take them
| serious. Most companies, unless they are very small are usually
| able to mitigate this to a very large degree without breaking
| the bank.
| ZuLuuuuuu wrote:
| That is a good point. Fortunately, I do feel like I am valued
| in this company. But at that time, I was relatively new in
| this company and I have moved from another country to work at
| this company. So I was eager to prove myself to them and was
| doing overtime regularly, which might have played a role in
| my carelessness (or is "reverie" the correct word?) at the
| split second of the accident.
| wolverine876 wrote:
| > 'poached' (I don't like that term but don't have a better
| one)
|
| How about just saying that they left? 'Poached' puts the
| agency in the hands of their new employer, as if the person
| was cattle and their job change was due to cattle rustlin'.
| (Not that some management doesn't look at it that way.)
| tikhonj wrote:
| You could say "underpaid and undervalued so they leave" which
| places the agency in the right place _and_ covers strictly
| more situations. You don 't need to be _actively_ recruited
| in a market with pay differentials _this large_.
| asddubs wrote:
| that should put the argument to rest, then. the bus factor is
| not a problem, the data shows that software developers survive
| being hit by a bus
| cvs268 wrote:
| Beware of Survivorship-Bias :-)
| emeraldd wrote:
| This almost had my monitor plastered with dirty moon chai. :)
| alexchamberlain wrote:
| I prefer to call it the Lottery factor. How many people have to
| win the lottery and retire for a project not to have a
| maintainer? It's a little more positive :)
| seanwilson wrote:
| Ha, I'd be open to better names like this. I've seen someone
| talk to a client before about what a bus factor was when
| explaining why we were putting together a handover document and
| you could see the client visibly wince whenever "hit by a bus"
| was said. I usually go with "if one of us is on holiday".
| asddubs wrote:
| ha, he must've had a pretty visual imagination
| detaro wrote:
| On the other hand, the "bus" scenario makes it very clear
| that it's the worst case that's a) not planned, b) no, you
| can't just call them anyways, even if its really really
| important and c) not something you can wait out until they
| return.
| s_severus wrote:
| (author here) That's a nice twist on the idea! You got me
| wondering whether a lottery win would change my plans. I love
| working on Vendure, I consider myself extremely lucky to be
| able to do so full time.
| ChrisMarshallNY wrote:
| I have "retired" (but not out of choice -no one wants to hire
| us "olds" -I stopped looking at 56).
|
| These days, I work harder than ever, for far better quality
| product, than I ever did, when a corporate drone. I don't
| make a dime; but it's never been about the money, for me.
|
| I really love designing and shipping product. There's a
| special joy that comes from architecting and finally
| delivering a _complete_ software project. I consider it a
| craft, and take great pride in my craftsmanship.
|
| Personally, I think it's absolutely _insane_ for corporations
| to deliberately ignore and insult folks like me. I was quite
| upset, when I first ran into it, but, upon reflection, I have
| to admit that it was probably the best thing that ever
| happened to me.
|
| If my hand had not been forced, I would have kept on working,
| making other people money, and never having the joy that I
| experience, every day.
|
| Definitely worth it. Would buy again.
| jes wrote:
| > _I was quite upset, when I first ran into it, but, upon
| reflection, I have to admit that it was probably the best
| thing that ever happened to me._
|
| At 62, I can relate.
|
| I think you might enjoy this short parable, as told by Alan
| Watts:
|
| https://youtu.be/byQrdnq7_H0
| ChrisMarshallNY wrote:
| I _loved_ that! Thanks so much!
| jes wrote:
| You are most welcome.
| jodrellblank wrote:
| I don't know if you would enjoy it, but keying off the
| idea of lifetime crafstmanship is the documentary film
| _Jiro Dreams of Sushi_ [1], he was 85 at the time and ran
| a small but world famous sushi restaurant - no chain of
| stores, no growth at all costs, instead pursuit of
| excellence.
|
| Quotes:
|
| > Jiro Ono: Once you decide on your occupation... you
| must immerse yourself in your work. You have to fall in
| love with your work. Never complain about your job. You
| must dedicate your life to mastering your skill. That's
| the secret of success... and is the key to being regarded
| honorably.
|
| and
|
| > Jiro Ono: I do the same thing over and over, improving
| bit by bit. There is always a yearning to achieve more.
| I'll continue to climb, trying to reach the top, but no
| one knows where the top is.
|
| [1] https://www.imdb.com/title/tt1772925/
|
| [2] https://www.imdb.com/title/tt1772925/quotes/?ref_=tt_
| trv_qu
| jacquesm wrote:
| > but it's never been about the money
|
| That is such a fantastic luxury position to be in.
| ChrisMarshallNY wrote:
| Definitely.
|
| I worked hard to get here. Saved 25-40% of my money,
| while working. Lived real "low on the hog."
|
| It's "f**k you money." I just thought that the idea was
| for _me_ to say "f**k you" to employers; not the other
| way 'round (which is what happened).
| agustif wrote:
| Well ageism is a bitch in our sector, but you certainly
| have to have in mind that maybe for the same reason past-
| entrepreneurs are frowned upon, if they know you don't
| need the money, they know they can't force you to do
| stuff you don't want...
|
| It's a bit like when they want to know if you've
| family/responsabilities, I doubt it is to pay you a
| salary going with those, but more to gauge if you'll be a
| good slave or not...
|
| Anyways, if I was in your position, I would do whatever I
| want, but without working for a company anyways, is not
| fuck you money (or attitude) at leaat, if you still have
| to obey the boss on all the bullshit right?
|
| Best of luck!
|
| PS: Oh now I saw your username, I've read you a lot arund
| here Chris, I think you're doing great with your own
| libraries/iOS stuff, I don't see why you might need to
| apply to a company, maybe you should start yours instead.
| You would make a good leader
| ChrisMarshallNY wrote:
| Thanks!
|
| I was a manager for many years (you can see many
| testimonials on my LinkedIN page). I just hated the job,
| although the consensus seemed to be that I was pretty
| good at it.
|
| I do have a couple of companies, but they are more so I
| can access resources that are not available to
| individuals. I am currently working with a small
| 501(c)(3) (US nonprofit). It is a team, but there's only
| a couple of us tecchies, and I do most of the coding.
| eckesicle wrote:
| Two years ago my team (then) was maintaining 15 or so projects in
| production, and landing 3-4 more every quarter. Each project was
| de facto owned by one person who did the bulk of the work on 2-3
| projects.
|
| After a team member left and a new maintainer had to step in to
| maintain an unfamiliar code base, our new EM decided that the bus
| factor must be raised across all projects. So every quarter we
| shifted responsibilities to new projects and had someone else
| take over ownership - the idea being that the previous person
| would still support and we'd not be in trouble in case someone
| left. That's not what happened though.
|
| It didn't really matter if the old owner was around to support.
| Productivity plummeted with every project. It was as if every
| owner of every project had left the team every quarter.
|
| Now I'm more convinced than ever that it's better to pay the
| price of an owner leaving if and when it happens, rather than try
| to prevent or mitigate that risk up front. The productivity costs
| are far too high for most software products.
| trulyme wrote:
| Sorry to say that, but it sounds like you got it backwards. The
| idea is not to _remove_ the owner from the project, but to
| always have at least two people working on any project at the
| same time. Instead of 2 devs working for 2 months each on their
| own project, put them together on the first project for a
| month, then on the other project for the second month
| (simplified example, of course). They both work on their own
| tasks, but because they are familiar with the code and the
| project, they can review each others changes.
|
| In my experience this works great. Context switching is a
| problem, but there are ways to minimize the impact (similar
| tech stacks, good work organization, clearly defined
| priorities,...).
| eckesicle wrote:
| With strict deadlines and OKRs to hit it wasn't really
| feasible for people to double up on projects.
|
| > Instead of 2 devs working for 2 months each on their own
| project, put them together on the first project for a month,
| then on the other project for the second month (simplified
| example, of course).
|
| We did try this and it sounds good in theory but as the old
| saying goes 'two women can't have a baby in 4.5 months'.
|
| In my experience (in this particular team and org) it
| would've simply been better to invest some time into
| documentation and suffer a short drop in productivity on a
| project when owners left.
| fendy3002 wrote:
| > strict deadlines and OKRs
|
| Simply said, that deadlines and OKRs don't account for bus
| factor.
| bobthepanda wrote:
| It kind of depends on how exactly the sharing mechanism
| works.
|
| If you are in a place with code-review, the 2-person system
| allows one person to at least read the code that is being
| written as it's being written, so the genesis and reasoning
| behind such code might be a little more obvious.
| trulyme wrote:
| I'm sorry to hear you couldn't make it work, but I can
| assure you that this approach works in practice. You don't
| get a child in 4.5 months, but you can get 2 children in 9
| months.
|
| I agree that not all environments are good at managing
| developers though (and that is probably a huge
| understatement).
| neilv wrote:
| Those aren't the only two options. You can try to get a team to
| develop systems that any other capable software engineer can
| pick up reasonably (such as via effective documentation, and
| reasonably maintainable nature of the code).
|
| One of the biggest barriers to that (besides teams needing
| guidance on _how_ to do it) is conflict of interest, which is a
| factor in the _why_. I started saying it upfront with founders
| at my last company, when speaking of who we wanted to hire, and
| how engineering should be done: "One of the jobs of an
| engineer is to 'document themselves out of a job'." Then I add
| something like "And the company has to realize that engineers
| who can and will do that are generally the best engineers, and
| extremely valuable to the company."
|
| Though, if the engineers didn't trust management (e.g., not
| exhibiting analogous professionalism and duty, such only
| looking at near-term selfish impact), then I can't argue that
| engineers should go out of their way to be easier for a
| stereotypical anti-leader to treat poorly. I'd have to appeal
| to the engineer's sense of professionalism, or of some degree
| of duty to other team members. I'd also know it's probably only
| a stopgap, and to give them whatever support I can if/when they
| look elsewhere for a home for an unusually great engineer.
| BigJono wrote:
| > Those aren't the only two options. You can try to get a
| team to develop systems that any other capable software
| engineer can pick up reasonably (such as via effective
| documentation, and reasonably maintainable nature of the
| code).
|
| That sounds nice in theory, but I've only ever seen it be a
| disaster in practice. It's like that mirror thing from Harry
| Potter. As soon as you actually try and make a maintainable
| code base, it starts going the other way.
|
| The only way to _truly_ optimise for onboarding is by writing
| the simplest, cleanest code possible. Everyone is already
| trying to do that by hiring the best devs they can. Any
| further efforts just look like more dependencies, more
| patterns, and more incidental complexity to act as guard
| rails in the pursuit of a newb-friendly codebase.
|
| The end result is that new devs are productive at small and
| simple tasks, but big things take longer. Also, you're never
| going to find a manager that understands this trade off, so
| your new dev is going to be left in a terrible position
| trying to explain how they got so much work done in the first
| month when they knocked off all the small cards, but now the
| new feature that the business desperately needs has taken 3
| months all by itself.
| gregn610 wrote:
| That might work if just one project from each maintainers
| portfolio was shifted.
| _dark_matter_ wrote:
| Didn't you all do code reviews, project planning, etc.? These
| are all ways to get other devs involved and knowledgeable
| without explicit "you are now the owner".
| thrower123 wrote:
| There's no substitute for actually working in a code-base.
| rhipitr wrote:
| Does a code review provide the necessary time for someone
| unfamiliar with the code base to understand all of the
| business logic that will be affected and where this new
| addition sits within that hierarchy? Code reviews have never
| seemed contextually rich to me.
| mikepurvis wrote:
| I think the theory is that for code review to be its best,
| it sits on a contextual pyramid composed of reviewed design
| docs, pair programming, standups, and all the rest of it.
| That the "reviewers" are not hearing about the background,
| motivations, alternatives that were considered, broad
| implementation choices, etc etc for the first time when the
| PR goes up.
|
| But often there are some or all of those pieces missing,
| and so yeah, code review ends up being a bit shallow and
| performative.
| eckesicle wrote:
| Yes of course, but code reviews do not always tend to
| transfer a lot of context.
| bluesnowmonkey wrote:
| If they don't already feel ownership, it's easy to just
| approve PRs without looking at them critically. Why deal with
| confrontation trying to uphold code quality for a project
| they don't _really_ own? I find people don't pay attention in
| reviews unless their personal success is tied to the long
| term success of the project.
| jacquesm wrote:
| The principle is sound, but your managers' way of implementing
| it is stupid. Productivity shouldn't go down as a result of
| knowledge sharing, it should go up.
| marcosdumay wrote:
| Do you base this opinion on any evidence?
|
| Because all I have are anecdotes, but all of my anecdotes are
| on the side of shared knowledge being heavily biased towards
| safety and consensus building demanding a lot of time. That
| happens even between two people that mostly agree, and only
| increase with more people or different opinions.
|
| Of course, some times a bias towards safety is exactly what
| you want. But on informatics projects, that happens very
| rarely.
|
| Once in a long while two people can have complementary ideas
| that make them faster. But it tends to happen more often when
| one is the clear owner of the project and the other is
| advising. Shared ownership seems to almost kill those
| chances.
| amenod wrote:
| My anecdata (at multiple companies) supports their opinion.
|
| What matters is that there is a clear owner who is the
| voice of final decision. In most cases there is no
| objectively better way to do something, so having a person
| who is a tie-breaker is beneficial. Of course, they _must_
| be involved in actual coding, doing code reviews of other
| people 's code and similar. And other people must review
| the owner's and each others code.
|
| But, having an owner is not the same as having a bus factor
| 1. There should be an owner, but other people should know
| the project and the codebase enough to step in at any given
| time, even as (temporary) owners if needed. And this is
| only possible if they actually work on the project, even if
| the approach that the team (/owner) decides upon is not
| what they would pick.
| watwut wrote:
| The project I work in has almost zero knowledge sharing
| beyond code review and I can tell you it is super
| ineffective.
|
| Oh, and we don't do ownership thing either.
| closeparen wrote:
| It's surely an article of faith in the tech management
| community, but practitioner experience says it's dead wrong.
| willcipriano wrote:
| Me and my peers sharing WW2 knowledge at the water-cooler
| probably considerably reduced productivity at one of my jobs.
| Your work on a part of the application that I have no
| interaction with is just about as relevant. Sharing knowledge
| just in case costs time.
| billconan wrote:
| > It didn't really matter if the old owner was around to
| support.
|
| why?
| detaro wrote:
| Given the comment elsewhere that having multiple people on a
| project wasn't possible because they'd not meet their goals
| then, presumably the old owners were more than busy with
| their new tasks and helping others wasn't a priority.
| tgsovlerkhgsel wrote:
| > Now I'm more convinced than ever that it's better to pay the
| price of an owner leaving
|
| And it's also worth to pay the price to get the owner to not
| leave. So many companies seem to think penny-pinching is worth
| it, or only start giving out raises when actual attrition
| starts going up and many more people are already invisibly in
| the process of quitting.
| Xylakant wrote:
| Sometimes you can't pay the owner not to leave. I've had two
| colleagues die. Another one had a stroke. Granted, I'm now
| around for like 20 years and a bit, things like that are
| rare, but no money in the world could have helped in these
| cases.
| ghaff wrote:
| And sometimes people are just ready to move on. It doesn't
| need to be because they're underpaid or it's a bad work
| environment. I was there and just wanted a change to a
| somewhat different type of work.
| twobitshifter wrote:
| Has anyone taken over a project from a departed developer? What
| were the steps that you took? I would wager most people will
| reach for the full rewrite which we know is something that you
| should never do.
| https://www.joelonsoftware.com/2000/04/06/things-you-should-...
|
| However, many senior developers recoil at the thought of quality
| documentation and prefer "self documenting" code which doesn't
| cover the why and thought process behind the code. This makes
| something other than a full rewrite daunting. Even with the best
| self documenting code you will continue to be surprised in large
| projects. The full rewrite allows the rewriter to reexperience
| the process but it's very expensive and may be worse than the
| starting point.
|
| If science and engineering were done like software, so much
| knowledge would be lost. We know that there are giants in the
| space of Science, Einstein's work was published and continued on
| by others to this day. I think the difference is that in science
| the motivation is to learn and teach, whereas in software people
| are pressed to create almost exclusively. We won't publish
| papers, but to get closer to science, I think it's necessary for
| solo developers to keep a development journal as has been done by
| scientists for some time.
|
| I mention nuts and bolts engineering, because in engineering, the
| best are usually mentoring others, catching mistakes, and
| teaching rather than actually doing the legwork. That's an
| alternative angle to fight the bus factor.
| analog31 wrote:
| Yes, multiple times. And this can happen at a well managed
| company. To some extent it's my niche. I'm not a coder (I
| program, but don't touch our product code base), but an
| industrial scientist, and these projects often involve multiple
| disciplines such as mechanical and electrical as well as code.
| My process is to start by just trying to figure out the theory
| of operation, and identify what is usually a single critical
| path of data through the code.
|
| Right now I'm looking at a relatively small code base that was
| written by an engineer in the embedded systems team. The
| original authors are retired. It's generously documented, and a
| pleasure to read. This makes my life easier, but also less of a
| hassle for the un-retired engineers on the receiving end of my
| requests for help. I don't know about commercial coding, but
| adding comments and documentation can help a non-specialist
| work their way through code if they have some decent
| programming background.
|
| The full re-write can happen if the departed developer is an
| entire departed business, e.g., an acquired company comes with
| code that is obfuscated to the point of being Goedel-
| undecidable ;-)
|
| Science isn't flawless. There's the so called reproducibility
| crisis. I think what helps science is that nothing of lasting
| value depends on a single critical path from data to results,
| but is reinforced by looking at things from multiple angles.
| For instance we'd still trust general relativity had the
| Eddington experiment never happened. And scientists such as
| myself are always looking for ways to make our own work more
| open and reproducible. In my work, Jupyter Notebook has been a
| game changer.
| amenod wrote:
| Many times (not departed as in _departed_ , just - not there
| any more).
|
| Could of hard-won experiences:
|
| - under no ciscumstances should you do the rewrite until you
| understand the whole domain, which is not until you know the
| codebase inside-out. And even then it's probably a very bad
| idea ("Yes but the old version allowed us to do X...").
|
| - start with business requirements: make sure you understand
| what people expect from the system, how they use it, what it
| does at high level. Sit with users and watch them use the app!
|
| - tests: do not touch the code until you understand the
| existing tests or, if tests do not exist, until you have
| covered the code with your own, preferably integration or end-
| to-end tests (unit tests are great, but they don't guard you
| against integration failures, which is what you want to be
| protected against here too)
|
| - skim the documentation if it exists, but don't put too much
| faith in it as it is probably out of date. Same for comments.
|
| - slowly start fixing bugs, cleaning up some code... whatever
| you do, make sure it is covered with tests.
|
| - good luck. :)
| watwut wrote:
| Yes, I did multiple times. I had not done full rewrite, because
| there was zero reason to do it. Nor time for that matter. The
| thing I took over was typically developed over a lot of time,
| doing it again would take a lot of time again.
|
| > However, many senior developers recoil at the thought of
| quality documentation
|
| There is no such a thing as quality documentation. An
| individual here and there is able and willing to write one.
| Average developer is not. And I don't even blame them, it is in
| fact skill and job occupation on itself to be able to do so.
|
| Developers are not even trained in how to write good
| documentation. There are no processes to check, test and review
| documentation.
___________________________________________________________________
(page generated 2021-12-05 23:01 UTC)