This started as a series of response to a thread discussing Boeing's disasterous decision to outsource the coding of their firmware "to the lowest bidder", with the thread starter originally claiming that "you still have to spec and test" the outputs of those outsourced workers. In general I agree that, the senior folk who were responsible for writing the specs that the code followed (AND most likely should also be responsible for testing/verifying that the obtained results were fit for integration into the codebase) *SHOULD* bear some responsibility for ensuring that the work done is up to required standards. However, I'd also like to point out that in many ways, this way of working is in many ways much harder for everyone involved, so the blame-torch shouldn't be aimed at these folks dropping the ball (save for complete systemic dereliction of duty). My own mini-thread of response follow (inlined together + tweaked to follow read a bit better).
~~~~~~~~~
In my experience, it really is a *MUCH* harder job to write a spec done by a junior or external engineer who you don't know that well (especially if they are relatively inexperienced in that codebase and your processes).
The only thing worse than writing such a spec yourself though, is to have a body of work done by such engineers thrust on your desk, with only minimal / incomplete documenting context (or worse, wads of INCORRECT documentation), and then being asked to review + double-check that work to ensure that it is essentially up to scratch + won't cause problems for the project in future (especially on tight turnarounds).
It really is next level pain, especially if you have your own work to carry on with, the complexity + volume or reviewing work required is non-trivial (or exceeds the time originally budgeted for by management), and/or the system in question is at all mission critical somewhere and has regular (i.e. multiple a year) releases.
(Note: I will freely admit that even after doing a lot more code review these days, I'm still far from great at it... for instance, there are frequently times when other colleagues can look at stuff and pick out a lot more issues than the ones I'd flagged. Which I guess is why good processes end up needing to have multiple reviewers / inspectors in general)
~~~
Honestly, in most cases if you are senior enough, it really is faster to do it yourself when you have to spec like that. Either:
* You don't spec the problem enough initially, then pay for it answering queries throughout your workday alongside your other work (i.e. "hello frequent context switching"), filing or fixing followup defects (i.e. "hello massive bug-squash-crunch technical debt" causing a budget / schedule overrun),
OR
* You invest loads of time upfront doing all the detailed spec work, in which case all the hard time consuming part of the work is done already (and actually in more detail than if you'd just done it yourself to begin with!)
But, wait - Oh yeah, the code now still isn't written yet, and as much as you're now itching to code it to see it come to life, you're not really allowed to do so, and have to sit on your hands waiting for someone else to do it, hoping they do it right, and wishing you'd get to do it as you already know the problem inside-out!
(*) I guess it shows what role I often took in group projects LOL - Master delegator, and final integrator + cleanup artist :P
~~~
In that sense, TBH I'm currently at a stage in my career where I'm honestly a bit sick of having to mentor junior engineers (at least for the immediate short-term). Which is a big reason why I've stepped away from University environments and to a lesser extent large open source communities (i.e. You're practically condemned to a lifetime of working with a rotating cast of novices for trying to bring your visions to life. Occasionally you might hit a home run and find a rare gem, but then the very best of those folk end up becoming some of your fiercest rivals in the worst case... or, in the even rarer case, yes you may gain a new friendly collaborator)
I'm not saying I don't want to do so again in the future, but it's more that I would like a break from doing that - to enjoy just getting to work with a bunch of similarly capable / skilled professionals, where we all know that everyone is skilled enough to just get the job done without anyone needing to hand-hold anyone else. (Yes, that is quite a revelation when delegating tasks, and finding that there's a lot of "implicit common-sense" stuff that you don't need to spec as your colleagues "get it" and are competent to pull it off)
~~~
IMO, all that "no code" / model based design stuff that academic software engineering professors from the US (?) are pushing is really trying to cut out the need for that outsourcing part, thinking that doing that will help the MBA's find the savings they so desire.
Really though, we are just changing the programming language that the senior folks have to use 😜
IMO you're better off fixing the abstractions + primitives your programming language / stack offer instead (i.e. instead of wasting time filling out a lot of boilerplate or making GenAI tools to build it), your programming language environment should abstract away / package up the best practice approaches so you're just worrying about the unique domain-specific problems. But of course, this sort of thing is historically not done - as enterprise architecture approaches with all those multiple layers (and the requisite plumbing to flush data up and down the stack) requires many "billable man hours" to build, which guarantees job stability to many... You know, the "folks can be blind to that which their continued salary depends on" thing 😜
Such is life
No comments:
Post a Comment