- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
How discoverable were the utility functions? Could a person have a rough idea of one they might want an find it in under 90 seconds (commonly accepted as the timebox for "readily discoverable")????
Admin
Also, I was under the impression that mucking with prototypes of built in JS objects, like String, is also widely regarded as a total WTF.
Admin
If the person can listen and speak, or read and write textual messages, then it's possible to, you know, gdmf ask people who've been in the company for a while.
That, of course, assumes that the person is willing to learn about this stuff rather than just bashing out another pointless lump of crap code.
Admin
Steve - In my experience (consultant for decades), it is quite common for the information to not be readily available to anyone. There are changes in staffing, other commitments, et. al.
Consider an engagement I am working on right now. A C++ program written 25+ years ago. Parts of it were migrated to C#, but with lots of C++/CLI in the middle. The last of the original development team left the company over 15 years ago; the last professional C++ developer about 6 years ago..... NOBODY at the company has any detailed knowledge of the codebase.
"Tribal knowledge" (that which you have to ask someone - often a specific person to get the information) is considered one of the top 5 problems of today (not just in the software development area, but in many fields).
Admin
It depends. It's really common in polyfills, which ensure library functions are available even on older browsers, and the pattern you see in the article is what they generally look like - check if the library function exists, and inject your own if it doesn't. Since the polyfill is coded to match a well-known specification, there's no ambiguity about what it should do, and more importantly, no chance of a newer version of the spec ganking the name out from under you. That's not a WTF (although you should probably use one of the polyfill libraries instead of doing it yourself).
But
formatisn't a library function, which is where things get dubious. On the one hand, it's conceivable that a newer version of Javascript would defineString.prototype.formatto do something different (probably using a different formatting syntax). On the other hand, our protagonist has probably just done this without getting a sign-off from the team, so they're injecting a function that isn't formally specified or documented, which brings us right into WTF territory.Admin
Yes, this is a really common and hair-pullingly-frustrating situation, but the article strongly implies Jessica knows exactly where to find it.
Admin
Also replying to a few others above. Coming new to a project for some enterprise implementation with quite some programmers you spend 80-90% of your time reverse engineering to try to find out what's already there. Also how things have been named far from expectations on common stuff
You would be surprised how little knowledge or documentation available.
Admin
When a project falls behind, remove features instead of adding people. Just get a newsletter signup button up, and build a community who will likely build everything for you themselves. Usually what people really want and what the market demands is completely different than what you have everyone breaking their backs to work on. Project's up and making money. Pressure's off. People can build something they really need.
Think of the Joker. When he promised the mob he was going to kill Batman, he didn't charge head on against the Batmobile with some $30 saturday night special. No! He just found the nearest bum on the street dressed up as Batman, tortured him to death and threw him in front of the cameras.
Admin
It can happen even faster than that. Team ABC, that works near me, created a nice foo-pipeline. And then, within 3 years of creating it, every single person on that team moved elsewhere - either out of the company, or to a radically different team. Team ABC still exists, and still has people working on that foo-pipeline, but until six months ago, they just treated the whole thing as a black box: "it works, but we're not sure how or why; when people ask us about details, or ask for new features on it, just delay and prevaricate". Fortunately, the people currently on Team ABC still know the language the foo-pipeline is written in, so they're not as lost as your poor team.
Summarized: created foo-pipeline 6 years ago, last original engineer/PM left 3 years ago, replacements finally started making changes 6 months ago.
I'm honestly not sure why everyone left; maybe management?
Admin
Of course, but the newcomers should at least try to find out. The indications in this case are that the newcomer just squirreled himself into a corner and bashed out random junk without asking.
Admin
I'm on a project where information seems to run and hide. What I mean is that there are a number of important facts and decisions that I was present for. However, new project members (and sometimes people that were present at the same meeting as me) manage to not be able to find this information, or are able to find information that contradicts the most accurate version of the facts.
It's not about whether the people who don't need the documentation can find it, it's about whether a random team member can find the right version of it when it's needed. Addressing information organization problems by saying "Go ask Steve" is how this problem got as bad as it is in the first place. One of the potential fixes is to cut down the number of people in meetings and the number of emails and phone calls. You will quickly learn if you have a useful knowledge base.
Admin
All very well suggesting your staff ask around, but that's not as straightforward as that when colleague 1 never answers his email, colleague 2 barks "I don't have time, it's not my job to teach you how to read a codebase" and colleague 3 treats every question like an episode of The Crystal Maze.
Admin
I'm going to ask a really stupid question here.
Given that the perp is re-implementing "String.prototype.format", is it entirely impossible for a Javascript IDE (WebStorm, Komodo, NetBeans, Eclipse, Visual Studio) to track down references and so on and so forth?
I'm not picking favourites (which would be Komodo, I recommend Komodo for PHP in particular, and VS and possibly NetBeans).
I'm just suggesting that, if you are tooled up, you should be able to spot this nonsense. At least in a code review.
Admin
Good point. As part of my process I always wrote the man page for whatever utility or function I was building FIRST, using it as the design document as well. Most people left documentation for last, if they did it at all. I always preached the need for a documentarian (generally, cheaper than a programmer) whose job is not only to document the project but also to assign names for functions and stored procedures and to cross train everyone on the available library. The above case couldn't happen because when the individual went to get a function name they would be informed it already existed.
Admin
I love that approach. When formulating documentation, design flaws can also be recognized early. Some things suddenly make obviously no sense, when you try to explain them...
Starting into a real-world project I was shocked to see how far from actual practice it is though.
Admin
No matter, according to the comment, we're actually trying to implement a STING format function. Those are quite different.
Admin
Even better if your documentation is in some kind of format that can be automatically checked for consistency with the actual code, perhaps some kind of literate programming model or "executable documentation" which actually invokes usage examples of the code it is documenting. We could call it "test-driven development"...
Admin
Either that's depressingly common or we shared a team at some point. I adopt the role of colleague 3, usually, if you can't actually be helpful at least try and alleviate the soul-crushing boredom.
Last time I was in that kind of team it was me and a malevolent little character who combined colleague 1 & 2 and had a coding style that could best be described as obfuscation personified. I was trying to introduce some structure, a few sensible comments a little documentation, if only to help me navigate and understand one of the worst piles of putrefying spaghetti I ever saw, he used to sneak around after me deleting and changing stuff to sabotage the effort.
In fact, in terms of this WTF, I was probably doing the same ... adding my own utility functions ... as if I introduced a dependency on one of his he'd literally target it for a change so my calling functions would fail because it was his utility function and I shouldn't have used it.
Admin
Ouch
Admin
"Which lead to this"
Remy, please: the past tense of "lead" is "led". Tell Alex too.
I'll let you guys off with a warning this time.
Admin
you have no idea how right you are. Bashing out random junk is exactly what he did!
The utility js file is called application.general.js. If that's not enough of a giveaway of 'generic, reusable js code here' then I don't know what is.
There was an element of 'I'm busy leave me alone' but the longer standing team members really did try to help out the newbies where possible. The project was so huge we all had our areas to work on and some didn't even cross over at all. We tried the old, 'remove features to deliver on time' but the bosses were having none of it. The entire saga is a giant WTF that I'm still trying to forget. Now I just deal with finding these little gems in the code-base and doing whatever we can to prevent new gems being added in.
The worst thing about this is that the string function is being declared inside another function, multiple times. If it had been done at the top of the file (every file he made) then that would have been something, but this is turning up multiple times in the same file... don't think he understood the principle of DRY
Admin
Theyre all good dogs, Brant.. except maybe this one
Admin
90 seconds might be your commonly accepted definition of "readily accessible", but around here, we have mountains of documentation, and one isn't expected to get through it that quickly.
To be fair, we have had some exemplary people who knew how to do searches who could find stuff in about that time. So, in that sense, yeah, we have stuff that's documented in readily accessible locations, by your standards.
That said, most of those exemplary people were WTF generators, because they found the individual bits of documentation they were looking for, and didn't slog through the larger body of documentation that explained things they did not know to look for specifically.
I'll admit our documentation isn't written the most efficient way possible, and that's mostly on me, because I've written most of it, and I haven't really been trained in tech writing. That said, we have had people get up to speed by taking a few days to read through the documentation we pointed them at, who have then managed to produce decent code while only asking the existing team a few questions here and there. So I'm comfortable with saying my documentation isn't completely horrible, at least. It's partially horrible, because I've probably written less than a third of the documentation I should have, but that's generally a management priority issue.