The Rabbit Hole
-
@Bulb said in The Untests:
¹ We do reviews wrong, of course. The rabbit hole goes deep.
¹ We do the reviews wrong, of course. The code is checked in the mainline first—because branching in TFS is pain, especially with the structure we have²—, then the task sits in the queue for sometimes couple of months—because nobody likes doing the paperwork³—and then it's too late to redo it.
² TFS (with the old VC component) is similar to Perforce and Subversion in that branches look like directories, but unlike those two, it can only branch at designated points called ‘components’. Well, because some components are shared between projects, the project is not one component. So far it makes sense. However, instead of two components—shared parts and the project specific rest—it is seven components, most tightly coupled. So to make a branch, you need a script to branch each of those seven directories for you. There is a plan to switch to the saner layout in future (and switch to newer TFS with Git backend), but everything takes ages around here.
³ The software is subject to FDA certification⁴, so we have to document what we do. Except nobody really understands the point⁵, so we just fill in some description template and then somebody reviews it, looking for random⁶ things.
⁴ Apparently the people in charge of it can weasel their way through the certification pretty well anyway. There is another project that is utter crap—it is in production and in maintenance mode, it used to have unit tests, but nobody ran them for years, QA tests are all manual and take so long that they don't re-run the complete batch when releasing update, it breaks down all the time requiring costly shipping of replacements… and it somehow passes, probably because it isn't actually that critical.
⁵ Of course there is some requirement that everybody should know the process. Well, their Solomon solution is to dump all the document templates and check-lists into an e-learning system⁷ and have everybody sign off they read them. Yes, everybody all of them. As if reading check-lists taught you the point of the process. Of course it does not; check-lists are designed to be printed out and checked off when you do the process so you don't forget anything, not to explain why and how to do it.
⁶ And it's not like any of those document explains reviews anyway. So some reviewers look at code quality (makes sense), conformance to the requirements (still makes some sense, though it's kinda duplicating QA's job⁸) and others just look whether the task description matches their arbitrary idea of what it should be.
⁷ That e-learning system is a story of its own. It only works reliably in internet explorer and in an old version of it at that. So the most reliable way to access it is by logging into a Citrix server with that version installed. It is slow as molasses, but somehow it manages to be just as slow if you try to access it with local browser and that is if it even somehow manages to work.
⁸ QA generally takes their job quite seriously and that's fine. On our project (and most, but not all others; see ⁴ above) they have automation⁹ for all the components and they write tests for the requirements and run them. Unfortunately most of the dev team does not know much about that automation¹⁰ and does ‘integration tests’ (there has to be an integration test case described for each task¹¹) by hand.
⁹ It is a pile of ugly hacks though, so the tests generate quite a few spurious failures and are therefore routinely re-run until they pass, which is obviously “great” for detecting sporadic issues.
¹⁰ I asked about it, so we got a brief introduction, but beside me and one other colleague, nobody bothered to use it anyway. I suppose it would be better if each feature and the tests for it were developed in lockstep, so the developer and tester could cooperate on developing the tests and fixing any deviations from the requirements¹². However reality is that the scheduling is mostly independent and coordination is close to none.
¹¹ Obviously if the task actually corresponded to a user-story¹² in the usual sense of the word, it would not be that hard. However the tasks are often created in rather ad-hoc fashion and attached to ‘user stories’ that encompass large sets of features with many details often not yet known then the thing is planned, so the ‘integration test’ ends up being just as ad-hoc.
¹² Being a certified product, there have to be detailed requirements and there have to be tests for each. And they are. Eventually. However, the requirement writing is often in trail of development. That is, obviously, not particularly helping the scheduling¹³.
¹³ Speaking of scheduling, the ancient TFS 2012 we currently use does have fields for entering the estimates and actual effort for tasks, but nothing to actually track the time in progress. So we use another system that duplicates the tasks in TFS just to be able to track the hours.
… see, the rabbit hole of
goes really deep here.
-
Why did I read 'Perforce and Subversion' as 'Perversion'?
Filed Under: On second thought, I think I already know why
-
Parsing the OP was fun...
-
@tsaukpaetra Yeah, it's basically Read by Numbers™.
-
@jbert And he stopped at 13.
He's pushing his luck
-
-
@jbert said in The Rabbit Hole:
@tsaukpaetra Yeah, it's basically Read by Numbers™.
More of a "Choose your own adventure", really.
-
@anotherusername In that case: where's the good ending?
-
@jbert I usually wrote my own "good ending". Especially nice when they had a male and female "main character" so you could identify with either one of them...
Oh no! You're trapped! As the water slowly rises, you spend your last few moments
pondering the life choices which brought you to this untimely end.fucking, 'cuz neither one of us wants to die a virgin amirite?THE END
-
@anotherusername Isn't that usually called "happy ending" rather than "good ending"?
-
@anotherusername said in The Rabbit Hole:
@bulb said in The Rabbit Hole:
FDA certification
I found TRWTF.
Well, that's what you get when you work with devices that the patients depend on with their lives. The fact itself is not a WTF. The original process itself probably isn't either. The process after passing through the bowels of a big company, yes, that certainly is.
-
@bulb said in The Rabbit Hole:
@anotherusername said in The Rabbit Hole:
@bulb said in The Rabbit Hole:
FDA certification
I found TRWTF.
Well, that's what you get when you work with devices that the patients depend on with their lives. The fact itself is not a WTF. The original process itself probably isn't either. The process after passing through the bowels of a big company, yes, that certainly is.
You're right in that it's a necessary thing from a conceptual point of view. I'd be more inclined to blame the A part of FDA than the Co part of WTFCo, though, for the WTFs in actual implementation.
-
@anotherusername said in The Rabbit Hole:
You're right in that it's a necessary thing from a conceptual point of view. I'd be more inclined to blame the A part of FDA than the Co part of WTFCo, though, for the WTFs in actual implementation.
I don't think so. FDA just requires requirements are documented and tested and some other documentation, mainly pertaining to risk analysis. But all the inefficiencies in the process, the crappy tooling and all that stuff goes after the Co part.
Hell, they have bet essentially the whole company on one project and it's slipping because of inner platform effect and really, really crappy implementation done in the most famous Indian quality (because the Indian subcontractor was the only who could quickly give them the two or three hundred developers they wanted—obviously with corresponding attention to actual abilities of said developers).
They already had one failed project (if I heard right, an important piece of hardware didn't pass the certification) and if this one fails, which is quite possible, they'll be in really big trouble.
-
@bulb I hope you have your resume polished. Best of luck with that mess.
-
@benjamin-hall Yes, yes, I do.
-
