- 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
Frist Reminds me of my past life
Admin
TL;DR
Admin
Yep. The one thing I absolutely hate in any job tracking time against projects it is stupid and outdated and does nothing morons continue to look at it as a way to see what they're doing it should not matter as long as things are getting done while I find too often is the people in charge are too stupid or I don't know what to understand this approach or are just lazy and are doing what happened at the jobs they were at previously basically a business version of cargo cult programming
Admin
I have been in the Billable-Hour-Hell myself and seen all the negative effects mentioned here.
Even the reporting for mini-project was a mess, resulting in filling out a 20-page Excel-sheet for two people.
And this "We are an IT-company in the <Whatever> industry" is something that I tell all my colleagues at every oppotunity. Because it is true.
Admin
Nice article. Thanks
Admin
Depends on your company, I guess. If you work for a small consulting firm(1) with multiple EXTERNAL clients, you'll probably end up spending some time each week on this client and some on that one, and a couple of hours on creating proposals for RFPs issued by potential clients, and it is essential that the person who generates invoices (or tracks project-work versus fixed-price contracts, delete as inappropriate) knows how much time is spent on each project.
(1) Like my first post-Uni job, where I was initially the only employee. (OK, there was the owner of the company, but he wasn't an employee, and there was the secretary from a nearby temp agency who came in once a week to do paperwork, but she wasn't an employee either.) That kind of small.
Admin
The road to WTF is definitely paved by detailed timesheets and interdepartmental journal vouchers.
Admin
A lot of these problems go away if you structure your software development process so that deadlines simply do not exist. If management needs code that does not yet exist, management has built its plans on things that "should" be true instead of things that actually are true (generally when they sell or promise something to the customer that doesn't exist yet). ("I need this." "You picked a bad time to need it.") Deadlines come about because management forgets that you never know for sure how long something will take until you have done it at least once, but each program, when it is written, is being written for the first time. People will try to guess, but those guesses are half-assed at the best of times.
Instead, management should give the priorities (implement this fix and then add this feature, etc.), and check on the coders to make sure they aren't slacking. Where I work, I have both high-priority and low-priority work in my queue. There are no deadlines; I submit code only when I think it will work. I work on the high-priority work, and when that's in code review or QA, I work the low-priority stuff. I stay busy, management gets quality code.
Admin
I had forgotten what the world of billable hours looked like. I'm not entirely sure I'm happy to be reminded. On the one hand, I'm really happy I don't have to deal with that crap in my current job. On the other hand, being reminded will probably bring back nightmares. Nice article, Remy.
Admin
Can this article be shared on LinkedIn etc?
Admin
Just wanted to say that the article was very well written. Thanks!
Admin
Nice article. But, by the length of your tome, it makes me wonder if you're not on billable hours...
Admin
I spent five years at [Enormous Software Company]. Despite the fact that their most heavily advertised products are actually software, in my little enclave we were considered "business services" and expected to bill all our hours to either external or internal clients. However, bonuses and raises were doled out based on the high visibility of your project, so if (like me) your specialty was maintaining and upgrading the frameworks that all the other software projects depended on, you were SOL.
I got hauled over the coals a few times for not having enough billable hours. All that taught me was to work very, very slowly. I spent a lot of time blogging and reading fanfics during work hours, because I happened to work much more quickly than some of my more fossilized co-workers - but my manager was happy, because I was billing more hours!
When I finally realized that in five years my salary had remained exactly where it was (as a just-out-of-university student) and I moved to a slightly-bigger-than-startup company, it took me months to unlearn all the bad habits that this mess taught me.
Admin
We need to talk about your TPS reports. You forgot to add the time tracking cover sheet to them!
Admin
TL;DR - Bad management is bad management, but the author blames the effects of bad management on one particular organisational model rather than recognising that what he's actually complaining about is bad management.
Admin
"Of course, this is all founded on the faulty assumption that in-house software development is simply overhead"
That's not a faulty assumption, it's a matter of definition (unless the house is a software developer). Overhead is not something you can do without, it's stuff that is vital to running your business - but is not your core function. Just like IT services can be.
Admin
Sometimes, though, Dave, "overhead" carries a connotation of "things that must be minimized if we are to maximize profits" rather than "good investments in our organization's vitality."
Admin
Many years ago I was a member of a military unit with significant computing needs, but a relatively small core group of developers. We brought in senior NCOs from other sections, trained them in performing basic maintenance of the database systems relevant to their departments, and after a year or two sent them back to be "Technical Coordinators" for their departments. They dealt with the 90% of problems that were user-related or that could just be worked around, and when they sent us a problem report we knew all the simple things had already been looked at AND that the problem report would be detailed and accurate. Those people became "us" while working in our department, but were still "us" to their own people when they returned... nearly perfect liaisons between the core developers and the end users. Not sure how well such a thing could work in a modern business (we had unusually talented people in all our departments, I kid you not, often strange but always capable). It might be possible to do it the other way around, hiring developers and training them among IT or developer staff before sending them to work at desks in other business units, where hopefully they would be accepted (perhaps after a period of suspicion) as members of those units.
Admin
I think what is really happening is that management types get actual fear that if they don't get some kind of information, workers will slack off, and projects will spiral out of control. This kind of thing is the only thing they can think of or even comprehend. And it is honestly a waste of employee time just from the mental distraction alone.
At my most recent job, my boss was quite clued. His much better idea was for everyone once a week to send a mini-report of What I Did This Week, due first thing Monday morning. Most of the time I could crib from the completed items on my own to-do list. (which was a plain text file I'd leave open all the time in Notepad++)
Admin
In place of "We don't make software, we make widgets" I would counter "We make happy customers by supplying them with widgets" and point out, for instance, how VB6 is getting in the way of making happy customers. To say you are a software comany that provides widgets is like saying your car is at heart a mobile computer. Yes it may be true but no one buys a car when looking for a computer.
Admin
And if you don't bill the other departments, they will look down on you as their slaves who have to do as they bid you. They will not appreciate your work, it's free after all. That's the situation in my company to some extent.
Admin
When someone says "We don't make software: we make widgets", say to them "We don't make widgets: we make money".
Admin
Then there are lawyers, and their billable hours. Given how many THEY build, you might think they have nine lives.
A lot of the reason for things like billable hours is because some costs are not "expensed" but "amortized" (due to an accounting rule change in the late 80's). You were supposed to account for the costs and spread them out over the "lifetime" of the product. This was to be similar to a widget-maker that had a definite life time and "wore out". Software for all its quirks, doesn't seem to "wear out" but does need maintenance as bugs are found and new features are added.
So, PHBs will harp on "billable" things, and hope they can get budgets approved.
In the meantime Wally still works on legacy software and goes home at 4pm, while Alice still has squatters at her house since she isn't there. Today's Dilbert.
Admin
Widget shaped money, but still money.
Admin
I was 10 years into an 18 month development of a document management system at a major health products manufacturer. After 10 years of building a state of the art document management system that was Unix based, we were switching to an off the shelf product that still required a lot of development to copy our existing system. The old system had been built on Applixware, a cross platform office suite with an extremely powerful object oriented scripting language. That was primarily my domain. My boss came to me with a proposal - another group needed a spreadsheet based app that aggregated reports from a half dozen different databases. They were 3 years into a 12 month development with another 3 years projected. They needed something to tide them over. So we came up with a plan and a budget and I was supposed to work 50% on that. I whipped something up in record time and they came back and said we really wish we could work with the data in eXcel. I did some googling and ran a few tests and put up an Xvnc server to invisibly convert the Applixware spreadsheet into an HTML page with an embedded eXcel spreadsheet which I pushed to the user. It was a pretty elegant hack. My boss actually got annoyed with me when we met with the customer to discuss how long it would take and I told him it was already betaed and ready for deployment. I think he could squeeze more hours out of them. Probably should have told me first. Anyway, the other job got really busy and instead of returning my billable hours to the spreadsheet customer and getting our original customer to pony up more, he said: "Let's just run out these hours first". The upshot, of course, was to convince our original customer that they could get rid of my hours completely and letting their internal staff split up my duties, like supporting our Oracle database, which led to me being laid off. (It did not go well for them. Many hysterical phone calls ensued which I got to bill at $100/hr).
Admin
I used to write up my status reports on Monday and use them as a template for the work I needed to accomplish by Friday.
Admin
In a previous life, this exact statement resulted in a core application written for MSDOS and managing a "Database" of a collection of binary files still in use to this day because there is always a way to run an MSDOS application in Windows. And of course none of the clients will pay for a conversion to a database.
Admin
Warning incoming Remy recursion. Warning incoming Remy recursion. Warning incoming Remy recursion. ..... ....
Admin
The Real WTF is that I read this.
Admin
About 2 years into my second job (at a military subcontractor), the government decided that it needed more detailed charge back information. We were all given a printout of all of the project codes on which we were supposed to be working, and the maximum number of hours we should be charging for each. In six-minute intervals. Any interruptions (e.g.: phone calls) were to be put on special codes. The running joke was that the codes for the interruptions were not distributed, so you had to hunt down the other person's boss to get the charge code, which took more than six minutes.
They actually created a charge code to be used for time spent looking up charge codes.
That lasted 2 years before the government finally realized it was pointless.
Admin
I completely disagree with much of what is said here. Billable hours do not equate hostile environment. Estimation is not an issue in an agile environment.
Also, hours need to be split into CAPAX and OPEX as the company increases in value as you create software that adds value. It becomes an asset.
Common sense above absolutes such as 'billable hours are poison'. I thought that was more or less the moral of most of the stories on this site?
Admin
Nice article.
It more or less summarizes the cause of every corporate WTF I've ever witnessed. The HTML comments just made em sad because I've also witnessed some of those?
Also, have you considered adding an upvote button for the comments? Some of the ones today were very insightful.
Admin
"there is always a way to run an MSDOS application in Windows"
Well, you might have to install DOSBox or a VM solution because you are running on Win64... (Win64 will not natively run MSDOS applications, nor Win16 applications.)
Admin
Sounds like your company needs a CTO, who determines what gets done when. Other departments can still tell you what needs to be done, but the CTO decides when those things are done and in what order or priority.
"I need this and I need it NOW" then gets the answer "We'll put it in the list with high priority, but if you want it now, you'll have to convince the CTO". Stress levels go way down for the average coder :)
Admin
You just gave the asnwer: there is allways a way to run a Dos application. Other companies then MS have other strategies. HP3000 entered the market 1973. End of lifecycle was 2010. Software created 1973 was guarrantied to run on the latest hardware
Admin
Running the MSDOS application is half the battle. The software is actively maintained to meet evolving customer needs. In practice for developers, this means
For every incremental change, there's no way to justify a full upgrade to modern tools and development methods because the answer is always "yes, it's still possible to accommodate that change". And just like the original article states - there's no way to justify the cost of a full upgrade project that is divided among all departmental units that use the application.
Admin
The MSDOS application also uses "code overlays" (a primitive form of DLLs) to help manage code size.
Admin
At a previous employer (a small company at that!) the boss started asking us to keep more detailed time logs with project codes. We just made up a slew of useless codes, like "WTOI" (wasting time on internet) and "FMUD" (furious masturbation under desk)
Admin
The situation is real, but the severe problems outlined in the post (and comments) are not inevitable. There are proven ways to get the necessary accountability and cost analysis the will provide maximum ROI [which should be the goal of every employee, in every role] to the organization.
If "the business" wants feature "Foo" because it will generate (or save) $X compared to not having it, then the project only makes sense if the cost of development + maintenance is less than $X... So one needs to generate a reasonably accurate estimate.
But how can one determine if an estimate is "reasonably accurate"? Only be doing statistical analysis of estimated vs. actual for previous work! And if one does not have a highly granular means of measuring the actuals, then it all falls apart.
Admin
Where I used to work, supporting a particular (large) set of (complex) tools, we charged a fixed rater per user of the tool set. One manager used to call it a "tax". It was quite a good analogy. This worked quite well.
Far worse was somewhere else where we had to put 40 hours a week on out time sheets for billing, even though we worked a 37 hour week with flexitime. To make it worse the time sheet system drove the progress in the project planing system making its understanding of how a ask was progressing rather meaningless.
Admin
This sort of makes sense of why our IT 'tax' is so generic - it's basically applied to all business units equally, though they do pay for whatever services they consume they don't pay for people's time per se.
Admin
Worse, you may see this within a project. Sure, the developers and coders and IT guys are considered 'essential', but the QA are considered barely-housebroken monkeys, and are treated as such. This leads to the billable hours situation outlined above. This leads to an increased need to 'justify' the expense of having a bunch of people whose job it is to delay release of an important project.
This led to a WTF moment of my own. In response to a new ridesharing incentive, a manager at my QA position emailed a new employee directory - names and contact info for everyone in our little dingy gray hell. This was fine, as it let some folks find new rides to the job and... Wait, some of those Excel lines look a little thick...
We founds some very interesting things by expanding those columns the QA manager thought she had 'hidden'...
First, there were a lot of notes about the QA team. Some of the notes were whether or not someone was a team player, or should be moved to another department. Others were insulting and petty comments about personality and appearance.
Second, there was an unlabelled column with either a + or - in it. We couldn't figure that one out until a few days later, when half the people with a - were laid off...
Third, and getting back to the point, we found out how they were judging performance for QA testers: total bugs found per week. That's it. No other criteria. Just one. damn. number. Yes, this meant that the guy assigned to poke at a pre-pre-Alpha build of a giant complex beast was treated like a goddamn rock star, while the guy dilligently doing repro to close the last few bugs on a tiny application that had gone Gold was seen as 'wasting company time'.
Three guesses which testing block I happened to be in, how many bugs I had, and which symbol I had in that hidden layoff column.
Admin
oh, this reminds me of an earlier story on this site...i forget the name...to summarize: management used log-in times of a single specific program to track "productivity", so one worthless employee would log in and do NOTHING ELSE AT ALL ALL DAY EVERY DAY and management thought he was the "most productive person in the department"... and their real most best employee got fired because her copy of that "specific program" quit working, so they thought SHE DID NOTHING and refused to listen to anything any employee said...