- 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
We sell mainly to giant companies and government organizations, though, so every so often for their sake, we do have to hotfix a bug for the bug-reporter (this only happens maybe a few times a year, though).
Admin
Paper in a filing cabinet is, in fact, a database. It isn't an RDBMS and it certainly is not ACID compliant, but it is a database.
--Lego
Admin
Bonus WTF -- must be a prime number.
Admin
you know what? i´d love to work with that kind of procedure now... I'm at the opposite side of that.
Bugs, modifications, improvements, changes , roof cleaning ,bath cleaning, timetables changes, and everything else you can imagine , its communicated by phone just one time.
Every programmer here has at least three or four projects assigned (most of the time all of them involving very different technologies ) , and the company keeps a very "close and friendly" relationship with the clients (read: They keep asking for changes which our bosses always accept ).
I'm going to get crazy!
Edit: And don't you dare to mention things like testing, because you sure are going to have problems....
Admin
I think we're actually in violent agreement here, as long as "IM" gets replaced by "bug tracking system", and the definition of "immediate" becomes something along the lines of "the next time the next person in the workflow checks their email". My issue is with unnecessary interruptions -- IMHO, IM carries an urgency level of "drop everything and look into this now", but I'll grant that that may be different in different corporate cultures. An issue tracking system lets urgency levels below "now" get managed more appropriately -- again, IMHO.
Admin
+1
Admin
Ah. Then yes, I think we are - testers IM us about live bugs when they're urgent, which is neither terribly common nor terribly rare; otherwise we just get an email, and we all check our email constantly anyway, since most of our email comes from our bug tracker.
But it's also true IM is probably different, different places - our office uses IM for pretty much everything. Anyway, my main point was, I don't think there should ever be a need to put "physically walk over to the bug reporter's desk" into a process specification, unless perhaps you're writing code for the space shuttle or hospital life support systems. (In which case, replace "walk" with "run".)
Admin
If you've got the luxury of only (or mainly) internal customers, this isn't necessarily a bad process step -- <chuckle> unless your users are better than most about submitting accurate bug reports. :-) But, I think we agree more than disagree here too; to me, this sounds like there was a communications issue in the past where the developers didn't reply to emails, and the pendulum simply swung too far in the other direction.
Admin
I'm sorry, but even if you guys think the process is "Not a WTF", I'd be surprised if you think this is acceptable:
Seriously? It's "not a WTF" that the guy was called-out by his boss in front of a user for giving potentially valid-input?
Makes me think of Tom from Office Space.
"I already told you, I deal with the god-damn customers so the engineers don't have to! I have people skills! I'm good at dealing with people! What the hell is wrong with you people?"
Admin
At one old company, our CCB devolved into a weekly opportunity to goof off, watch movie trailers and occasionally get involved in religious debates regarding the positioning and color of certain web controls. It's good work if you can get it.
Admin
Have to agree with this. It has "justification for the existence of middle management" written all over it.
Recording and tracking defects? Fine. Recording and tracking who resolves those defects? Fine. Throttling the communication between those who find problems and those who (can) fix them? LOL WUT
Captcha: conventio -- sometimes there can be too much!
Admin
No. 1.0: Don't quote me regulations! I co-chaired the committee that reviewed the recommendation to revise the color of the book that regulation's in. [hardens his tone] No. 1.0: We kept it gray!
Admin
Admin
Actually, it can be both random and unique. Restricting the numbers you generate to "those not previously used" does not magically make it nonrandom.
Admin
From dictionary.com Random
- adjective
<snip> of or characterizing a process of selection in which each item of a set has an equal probability of being chosen. (my emphasis)So, in the set of 12 digit numbers, if those alredy selected are exclulded then they have a significantly lower probablility of being chosen than any of those "not previously used."
My verdict? The 12-digit numbers are not random.
Admin
And the set is "12-digit numbers not already chosen".
There, it's random.
Admin
Clearly, you don't understand randomness.
Suppose I have a deck of cards. I shuffle it, draw a card. And I don't put it back.
Is the next card I draw nonrandom?
You might argue that it's nonuniform, yes, but it is most definitely random.
Admin
Is a function that only returns 4 random? Yes, if your set only has one number in it. Not a very useful set, though.
Admin
Yes, a filing cabinet of paper could be a database - back in the days when a good secretary provided the ACID access control.
Anyway, this WTF reminded me of a flight I was on years ago. I - a white British engineer working for a European Telecoms company - found myself sitting next to a black American chemist working for an American photography company. Would we have anything in common? Yes - we were both suffering from the introduction of ISO 9000!
That said, our QA man gave wise advice on how to write ISO 9000 processes: document what you actually do, not what you think you ought to do in a perfect world. Otherwise you'll be forced to do it - but without the perfect world's unlimited resources.
Admin
A filing cabinet is a database. The paper card catalog at the sad county library that hasn't seen funding in 20 years is a database. C'mon son. If you aspire to be snarky and/or pedantic, you need to step up your game. What you are describing with referential integrity, atomicity etc is technically known as a "Database Management System" or DBMS.
Admin
I dunno. Picture the situation: "puff, puff. Bob! The life support system has just crashed! I ran over to your desk to tell you that you have four, maybe six minutes to fix the bug before all of the patients suffer irreversible braing damage and/or death! Okay, three to five minutes, now."
In either of those situations, it's hard for me to picture a situation where you'd have to run to the developer's desk to get the bug fixed...
Admin
Its much better when the users are accustomed to taking problems straight to the developer. Developers really enjoy the constant feedback and communication. It enables them to get much more done - the developers can be fixing multiple undocumented bugs simultaneously.
Admin
If this definition were correct, the universe as we know it would not exist.
Admin
It reminded me of Office Space also, but in a different way:
""I'm sorry," Eric's boss said, "I know you're new here, but we all really need to follow procedure. Did you get the memo about TPS cover sheets a copy of the Developer's Handbook?"
Admin
captcha: distineo
Admin
I'm quite sure you meant something else, be careful not to spread mistakes else you'll be partly responsible for global stupid-ization (and i'm sure you don't want that :) ) .
And of course, a wikipedia blabla thing :
http://en.wikipedia.org/wiki/Capability_Maturity_Model
I guess you were referring to the CSI (ITIL) / ME (COBIT) process of CMMI ... right ?
Admin
Well well well. How do I report a defect in the process?
Admin
Admin
This question is genius.
According to the Defect Resolution process, first you should "cease performing any further actions" in the process.
Nothing more you can do now other than wait for them to resolve the defect. Should take 4-6 months, at least.
Admin
I once attended a presentation by a department in our organization that had just achieved ISO something-or-other certification. The entire presentation consisted of them boasting about how much paperwork they were now doing, and would now require us to do to get anything from them. I mean, literally, they were really really proud that they had managed to increase the volume of paperwork. There was not one word about how or why this extra paperwork would help anyone. It was clear from the tone of the presenters that they considered more paperwork to be a desirable end in itself.
I understand when someone tells me, "Yes, we now ask you to fill out this form to get service from us, because this helps us to get all the information we need. We use to let people just email requests or leave a note on our desks, but they would often forget to tell us important things like what product it was they were reporting a problem with or a phone number where we could contact them for more information, etc etc" But I've had plenty of times when I've been told that I need to fill out all sorts of paperwork that I am sure no one ever reads, much less does anything about.
Admin
Just because the stated or apparent goal of a process is a good goal, doesn't make the process a good process.
Like, "We are getting too many bug reports that turn out to be that the user misunderstands how the system is supposed to work. Therefore, we will make the users fill out a long form and submit it for prioritization and generally jump through all sorts of hoops before we will accept a bug report." Does this even address the problem? It might reduce the number of bug reports by leading the users to just give up on reporting bugs, but that's about it. Real solutions might range from, "hold some classes to explain how the system is supposed to work" to "tell the tiny number of users who keep submitting stupid bug to read the manual before submitting another one".
Or, "We want to reduce the number of poor people in our city. Therefore, we will drop a bomb on the poor section of town."
Admin
I think the point where the process fails waiting for "their weekly defect-prioritization meeting". It's not unreasonable to have user-assistance folks and developer/sysadmin folks separate (I'm a user-assistance guy, though we are technical enough to do most of our debugging ourselves without help from the vendor or sysadmin.), but when we get a bug that's out of our scope, we immediately email the person who knows what to do to try to get our user up and running ASAP--our weekly ticket meeting is just to discuss high priority tickets, not to assign issues that could've been solved days ago.
TRWTF is the insistence on adherence to the rigid protocol. Sure, we've got stuff like that at our lab, but everyone still does what needs to be done. If a sysadmin overheard a conversation with a user, he could certainly contribute, even if that's not what was in the protocol. I think that, in such a small organization, it's harder to distinguish between general adherence to protocol and asinine insistence on it.
Admin
I think the idea is to make sure that the "I can't be bothered to read the manual" users are handled by the interns while the "I've just discovered a major security flaw that's almost impossible to fix" tickets are funneled to the senior developers.
Also, remember that most developer-types aren't exactly the people you want to be the face of your organization--user-assistance people have to keep in mind not only the real problem and potential solution, but the proper treatment of the user, management's official policy, the user's level of technical expertise (and how to bridge that gap, when necessary), and a lot of other stuff. You don't just want users calling up developers--you'd end up with pissed-off developers and confused, insulted users.
That's a good solution, but it's quite expensive, hard to coordinate, and you have to make sure that the material that's being asked is actually covered--and, of course, the "special" users never end up attending anyway.
You've obviously never dealt with an angry Italian postdoc who just lost a year's worth of data to a routine scratch-filesystem purge. "RTFM" doesn't cut it.
Admin
What Eric should have asked was "What dumbass thing did the dev team do before someone over-reacted and put in place a Draconian process to prevent us from causing more Dumbass Damage?" There is probably a whole closet in their building that is full of production-issue skeletons caused by developers with no sense of control and a misguided sense of urgency.
I'm currently evolving process at a small company where the developers have lived in a free-for-all, orgasmic adventure of "doing whatever the hell they want" for far too long. The merest hint of "hey, have you considered maybe not being such a cowboy" is met with intense resistance and derision.
I feel like I'm trying to teach labrador retriever puppies to not pee on the rug before guests comes over.
i.e. - "Seriously? I have to TELL you not to make changes to the client's production environment without coordinating with the client? SERIOUSLY?" Bad developer swat on the nose with a paper
In my experience, a massive process like this is a reaction, not a proaction. Somewhere in their history, some jerk of a developer or group of jerk developers messed it up for everyone.
Admin
The 1, 2 and 3 of Lotus 1-2-3 were a spreadsheet (a Visicalc ripoff), a database (which is what the VLookup thing is all about) and a graphics/charting program, respectively. Excel does everything that 1-2-3 did. So yes, a spreadsheet is a database -- even if it isn't a multiuser database server or doesn't fit into the SQL/RDBMS mould -- it is a data store that keeps its data atoms in separate niches and is searchable by key and value.
(I'm not for a moment advocating its use in the context cited, just being pedantic. For personal use, though, Excel makes a hell of a lot more sense as a database than, say, Access, the ghosts of Approach, Dbase or Paradox, or any of the SQL stand-bys.)
Admin
Is this Lifestyle Services Group?
Admin
I don't know much about programming and even I had to facepalm at that
Admin
This is why I love that our defect tracking system has a category for the cause of the bug. And one of the items in that category is "Process Problem".
That's right, even the process itself can have bugs in it; Gosh, who would have thought! Surprise surprise, we even fix the process that caused the problem - OMG!
Admin
This process does sound draconian, especially with all those half baked tools to support it and such few people with double roles etc.
But if I play the devil's advocate for a second; there is another side to the coin.
We started out with this highly idealized "no-process-and-everybody-is-equal" approach. So we sat in one room with 12 people and it sort of worked. Than we grew to 30 people, 40 people, 60, 70... and it became a total disaster!
We had like 20 developers and some 30+ different people constantly interrupting the programmers with all kinds of different wishes, bug reports, awkward stories and of course all of them conflicting. Person A would go to programmer X and ask for some column on some page to be removed. Afterwards, person B would suddenly notice the column was gone and would go directly to programmer Y and ask for this column to be put back.
Then a certain programmer was working on feature 1 and while half at it, another person would interrupt and ask for feature 2, which is of course the most important thing on earth and will make the company an instant €10000! Naturally, the programmer instantly drops working on feature 1 and hastily starts with feature 2. Who doesn't want to earn €10000 (actually the company would supposedly earn that, but that doesn't matter, the number sounds impressive).
Just when the programmer is ready to type the first lines of code for feature 2, another person approaches the programmer. He has just booked a lot of items in the system under the wrong name. He can correct this manually, that will take him at least half an hour and this person has to go home soon (needs to attend some party tonight). Can the programmer write and execute some SQL query to put the items back on the right name?
Of course, the programmers pities this poor person. Having to do mundane work for a whole half hour? And miss some party? No way! So the programmer instantly stops working on feature 2 and starts writing the query. With all those normalization and constraints to take into account, it of course takes longer than half an hour to write. And then it needs to be tested, but before that some test case needs to be produced and after that has all been done it needs to be deployed. Of course, it can't be deployed just like that on the live system, so it needs to be scheduled and ...
Before you know it the programmer has spent 2 hours on this and is just about ready when yet another person comes with a very nasty bug that prevents him from doing his work. This really needs to be fixed now, since there is this important client coming today and this can't be rescheduled since <bla bla bla>. Without giving it much thought, the programmer forgets about the query and starts looking into the bug.
2 weeks and 40 switches to different things later, the programmer finally finishes a single thing; feature 23 for person 16 and proudly presents this to him, only to get a blank stare and a response: "Can't remember I asked this?". After the programmer details the event of this person coming to his desk, mentioning customer Q and the €20000 the company would earn, the person requesting the feature remembers, but replies: "Oh yeah, that feature, no I don't need it anymore, it's maybe not such a good idea after al".
I've seen this stuff happening. A lot. Over and over. It's NOT a pretty thing.
Having some sort of process to protect your programmers from being constantly and directly approached really often is a Good Thing.
Admin
Excel is almost, but not quite, entirely unlike a database.
(Access is almost like a database.)
And in my book a DB has to pass the ACID test.
Admin
And this process WTF is most likely that it, at it's core, it is good and well in intention. So we cannot deny it. But it is a complete mess in RL, so we want to avoid it. The typical split personality a developer often has, or aquires during its life. Is it a job related sickness, we wonder?
That said, i spent some years under such a process with even more points to connect in the automata. It also involved review cycles (documented in word) and test cycles (you guessed it - exel). Programmer != Reviewer != Tester. Oh, and we were two developers.
Attempts to streamline this mess w.r.t. the small team reliably summons some PHB who talks about the "true teachings" which this process is...
Head, meet wooden table.
capcha: ap(e)tent
Admin
No, Excel really, really isn't a database, no matter which way you cut it. It's a spreadsheet program, plain and simple, that just happens to be used to hold information by some people who don't know what a database is, or how to use one.
Access is a database, albeit a not very good one. A major WTF is attempting to use it for anything useful.
Excel only gives rudimentary lookup functionality, doesn't enforce any data constraints on cells (we'll refer to them by their proper name and not the database name of fields see), has no idea of indexing and (on older versions at least) placed a ridiculous limit on the number of rows per sheet.
Given the choice, I'd go with a proper database over a spreadsheet any day.
Admin
Ahhh, I love how everyone levels criticism like they've had the problem solved for donkey's years. Show me a person who believes they have the process right and I will show you a person deceiving themself.
Admin
Their process is solid and better than at most organisations. It obviously needs some refining if necessary communication channels are impeded, but it is not unusual for a team lead "To ensure developers aren't bogged down with unneeded defect assessment" by acting as the go-between. This ensures they stay apprised of all defects, enables them to think strategically about the defects, allows them to determine whether requests are defects (or enhancements), etc.
Further to this, it is not unusual for a person to wear many hats (QA manager, dev manager, etc) in a small department. Eric needs to grow-the-fuck-up and get used to how things are done in business.