Granularity
http://trenchescomic.com/comic/post/granularity
Yo Mama so Tedious
AnonymousAs a systems admin, I’ve had to do my share of testing, but nothing compared to when I was first starting in the field.
My cousin ran a QA firm in the west coast and often would call me up for little projects he needed an extra hand with, especially during the crunch. It was good contract work but I always knew it meant no sleep and no soul. The first job was on the website for that awful ‘Yo Mama’ show that MTV used to run. They made this e-card sender where you could upload a picture of your face, enter your friend’s name, pick some details, and a little animated version of you would tell crappy jokes about your soon to be ex-friend.
This was fine, except for the fact that we had a list of hundreds of names, spoken by male and female, and over a hundred jokes in three categories. Picked at random. This led to thousands of tests to check everything off the list. The hours began.
It started fine, It was even a little funny as we IM’d the most awful jokes back and forth, but then my cousin had to shift to another project. I was left alone with a pot of coffee, a million bad jokes, and a buggy flash interface. I finally wrapped up at about 7 AM the next day as the sun came up, I laid down on my bed and dreamed of punching the host repeatedly, but at least the site could launch and I got paid.
The TV show was canceled two weeks later. I still cry.
Posts
We don’t need to test.
03/19/2013 - Anonymous
I am the sole developer for an in-house fully custom CRM. It was developed by an amateur and was clunking along managing a mid-sized company’s affairs. It was undocumented, messy, and riddled with tricky bugs. I was brought in to maintain and extend it.
The first thing I wanted to do was document it, clean it up. Nope. “That’s not what we’re paying you for” I was told. “We need you to fix the big problems and add features, and we need you to do it fast.”
Okay then.
I made a herculean effort to give every senior employee every item on their wish list, no matter how nonsensical. The timeframe I was given was something like half of what I needed to do a good job, so I half-assed it. I’d write a new feature, test it once, and call it good.
Months down the line, I’m still getting so many requests for new features and behaviour tweaks that I have absolutely no time to make sure my code works well. Occasionally, something will fail spectacularly and I’ll have to scramble to fix it. My boss will not allow me the time to slow down and do a better job, and when asked if I could have a tiny percentage of someone (anyone!)‘s time in the office so that I could have SOME kind of QA I was told that my code shouldn’t have bugs in the first place. This was accompanied with some pointed words about my upcoming personnel review. I attempted to explain that ALL software has bugs, and that QA (and documentation!) are a necessary part of the process. No joy.
The lesson here, fellow trenchermen, is twofold, number one, INSIST on the time and resources you need to do your best work. If you do not get what you require, communicate that you will not be responsible for problems down the line. Put it in writing. The second lesson is don’t work for a boss that can’t code. It sucks big fat hairy monkey balls.
Dear VP of Technology,
I am writing this because I am in a bad position, and although I would really like to keep my job, I am desperate enough to write you because I have a major problem I have not been able to resolve through talking with my boss and my boss' boss.
I am supporting our CRM system, for which I am expected to introduce new features and also fix any defects found. However, I am being denied requests to get sufficient time to unit test my code, and am constantly denied requests to have even one resource to QA my work. I am not proud of the work I have put in, although it was the best I could do with the time allotted to me. I think that going forward I could do a whole lot better job if I was granted the opportunity to unit test my code, or if I had access to someone who could even do 10 hours a week of QA for me.
As I said above, I would like to keep my job, and so I have an additional request- please do not share this email with others or bring to anyone's attention that I have contacted you. But if it is brought to your attention that there are issues with the CRM system, please make some inquiries and look deeper than "The developer is doing a bad job." I am truly doing the very best I can given the time constraints I have been placed under, but when I am being told that "my code should not have bugs in the first place", there is only so much I can do. Attached are a few emails that illustrate some of the issues I am facing.
Sincerely,
My actual name
Moral of the story: Don't code.
kingworkscreative.com
kingworkscreative.blogspot.com
Didn't he already insist on time and resources and fail spectacularly?
It's just a glitch in the way Geth pulls them to autopost the new threads. It's been pointed out in bug reports, I'm sure it'll be fixed.
A trapezoid is the kind of pyramid a bitch would draw.
Basically most organizations have a bunch of different systems talking to each other, and the CRM system is the one that holds the "most correct" version of individuals' contact information and anything that relates to the individual contacts (events they attended, membership status, campaigns they were part of).
It's also the system that companies use to spam your email account, and if they're kosher it's where they keep their list of people who have asked not to be contacted by the company.
I believe the runes G•A•M•E•S in the capstone mean in the common tongue, "Everything of value on this Earth."
If you're lucky they will argue for weeks over who has priority while you get to work on the highest ranking person's requests. By the time they present you with the schedule you should have a good head start.
The route that he is on now can end in only one destination, and you do not want to be there.
That mans knows his shit. I worked for a large company with a very old system, and the main consultant was an expert at this. He was so good, in fact, that meetings were schedulded to discuss the allotement of his workhours. He was of course present at said meetings.
He made a very comfortable life. Also was a good drinking buddy. Myself, i got temp'd for 5 months to get some shit in order and then had to train the person who would replace me. Standard practice.
I've definitely been in the situation where management is giving you more feature requests than you can feasibly do, and the system you're working on needs to be refactored and tested thoroughly. Normally, I go to the business owners in person, explain my situation, and ask which two features they need the most, so I can work on them first.
Talking to people in person helps them feel like you've got their back and that you care about their interests. Sometimes this doesn't work though, and if your manager doesn't have your back, then you're screwed and need to get a different job.
If my direct reports were buffering at 100% we would be having some pretty interesting chats about why their work took so much longer than their peers, especially when code reviews started to roll in and the disparity became obvious.
("It took you a week to write a 15-line function?")
"Yeah, but I wrote an API that will allow everyone else to do similar tasks in 15 minutes."
That's great, have you informed the team? Did you pilot test it with another dev to ensure compatibility? Is anyone using it? Did it go through design review? What was it about this API that took a week? Was this the costed work on your plate, or did this eat up buffer?
You have it easy. I was hired 8 years ago to not just manage the CRM, but also QA tools, Bugtracking, Client forum (ancient phpBB2), random reports, and FTP server which needed to interface with three databases for authentication.
The initial code was decent, written by a guy I met this year and had the pleasure of working with. His buddy, the owner's son, also wrote some decent code before handing it off to me. However, he'd still been learning MVC at the time and didn't think to keep the software up to date. This was back in the days of Mambo CMS before it became Joomla.
It was the documentation manager who discovered that the intranet server's folders were shared on the network and he decided to start modifying and writing his own code for documentation and QA. And that is where our horror story starts. Spaghetti code galore, with horribly written SQL, numerous database connections opened and never closed, sections just waiting to crash even the most robust IBM DB2 database and the Apache server trying to serve out PHP-generated pie charts surrounded by blinking neon header tags that are followed by ActiveX-based rotating dotted and dashed borders.
And every Monday and Tuesday between 11am and 4pm the entire database and network would slow down as managers ran reports and certain web pages in preparation for managerial meetings. God forbid they ever need to run certain pages again during the meeting because it would most likely cause the entire intranet to grind to a halt. So for about a year my job was to clean up code and put in security permissions so that only myself and the original owner's son had access to the intranet server's code.
Eight years later... the original owner's son is now the Development department head. And he's actually good at his job. I'm glad to have him as a boss. I'm even more grateful we see eye to eye on how disgusting the original code was.
And even more, I'm grateful he's bringing in FogBugz. Now if only I could convince him to completely trash Joomla 1.0 and start over from scratch with something like... maybe Umbraco or SiteFinity.
Sincerely,
Beleaguered Developer
The operative phrase is "realistic time-frame". That is, assuming nothing goes wrong, that's how long it will take you to write it. Of course, something usually goes wrong. If not on that request, it will on the next one. So, you need to have some slack to handle the realities of the business.
Personally I give a "Two-thirds Worst Case" estimate. Which is what I estimate the worst case expectation to be, then chop 1/3 off. That is usually a much more accurate estimate than "Double the Expected Time" estimate. But you need a lot of experience to know what a realistic worst case actually is. And the OP did not sound like he has a lot of that.
There are of course other more complicated estimating processes, but generally you don't really have enough information to really make them any more accurate than what I do. And they take a lot more time, and bosses like the OPs generally don't give you time to do a full proper estimate anyway.
Further, unless your job completely isolates you from your customers (as is obviously not the case with the OP) you need to take into account the time that you will have to spend interacting with the customers. (Phone support, training, hand holding, request taking, etc...) I doubt OPs boss would allow him to schedule 2 to 4 hours a day for answering tech support calls from his customers. So you need to include it in your estimate too. So maybe the OP might need to triple his estimates.
If you exist in a fully supported and process complete IT department, the advice I gave above is really not needed. But it can still be helpful. In my current job, I have a full IT department around me, but the customers still like to inject scope creep any time they can manage it. So, I pad the estimates a little more than I would like, but at least I don't have to say 'no' as often as I would otherwise. This makes the customers happy even if my estimates are a little high. And not missing deadlines makes the brass happy too. So it's a win-win.
Sounds like this guy hadn't been working long.
PSN ID: fearsomepirate
Split things down into stories and tasks, plan the next two weeks of work by estimating the effort (which is completely divorced from the concept of time) of each task, and then give it a few iterations and eventually it effort becomes informally standardised in the team (it has no formal value but people get a feel for how much "effort" a task is going to be worth) and it becomes clear how much effort can be done in an iteration. Better for everyone, so long as the upper management can accept that planning more than two weeks of work for a developer is so fundamentally flawed a concept in as fluid a field as programming when requirements and priorities can shift so quickly...
But maybe I got my brain sucked and replaced with "agile, hells yeah!" when I started working at once such company.
Steam: adamjnet
Doing the best you can is, by itself, something you can be proud about.
Free CRMs ain't no picnic either. I'd rather pound nails into my dick than try to track down bugs in CiviCRM.
My guess is there is some code that posts these to the forum, and there is a lack of QA. (Irony right?) I only really read these trenches posts, but the fact it is the user who posts these is Geth makes me think it's a bot.
Having worked for both billable hours firms and firms that rationalize effort and base their goals on what we need to produce, rather than the hilariously obtuse metric of hours on the clock (which can be eaten up by meetings, managers, stupid bullshit, you having a migraine headache or an off day), I will readily concur. Timelines get pushed! Internets be complicated, yo! If I could somehow get across to all managers everywhere that any deadline the team agrees to will have a +/- of six days at minimum, I could die happy.