Serious question about WTF jobs
-
I've worked for 3 organizations now as a developer. The first one I was the only programmer and developed everything myself so it doesn't count. The last 2 have been complete disasters with systems and processes full of WTFs.
My question is are most development shops out there just one WTF after another or do the majority of shops out there follow sane and logical development processes like proper use of source control, object oriented design, etc...
Thanks
-
My experience is that there are some WTFs in every job, but the best jobs let people and subunits do their own WTFs and leave the rest not to have to deal with them. The worst jobs are ones that punish you unless you repeat or cooperate in the WTFness, or constantly let shit roll downhill when an obvious WTF is in progress. My rate is about 1/2 decent and 1/2 WTF. Since I stay at non-WTF organizations longer, though, the non-WTF parts of my career have been longer.
Lots of organizations start sane but quickly slide into WTF when they expand. There's no good way to avoid it except to watch for rats overboard to starboard and become one of them if the time is right. This kind of problem is primarily caused by a desire to grow too quickly and an organization that doesn't know how to hire well.
-
I guess that only a small number of development shops do it "by the book" and actually survive.
-
The problem is that as organization (or development team) gets bigger, the number of WTF opportunities as well as the scope of single WTFs rises linearly, which means the total WTF potential rises quadratically.
Avoiding this takes effort, you have to be smart-lazy, i.e. look out for budding WTFs and do something about them, find better ways to do something, ask questions and talk to people. Of course, those people have to listen and be cooperative. The more the organization encourages and rewards such behaviour, the better it works. There's tons of management literature on how to do that.
A lot of people prefer to be dumb-lazy and just do what the requirements say, and go along with any WTF because they don't want to spend that effort. Many organizations discourage people straying from the tasks they've been assigned. That's the environment in which WTFs amass and grow to epic proportions.
-
Also, in my experience the smaller the company, the more the WTFs. Especially in very small companies, since the owners usually have no clue about technology at all, so some Paula type (well okay, not her because you actually have to *produce* code) can get in there and fuck everything up with shitty code, no documentation or source control or tests, $20 routers used for networking, 10x copies of Office but one license ("What do you mean I need to buy 9 more? I already paid for this one!") common home desktops reconfigured as "servers" to save money, and the like.
After getting burned yet again with a small company, I'm making a resolution to never work for one with less than a certain amount of employees, unless it's a startup or something and I'm a partner/shareholder or something with it. It's not worth the headaches and stress from the huge number of WTFs that inevitably turn up in such an organization.
-
@ObiWayneKenobi said:
After getting burned yet again with a small company, I'm making a resolution to never work for one with less than a certain amount of employees, unless [snip]
I'd like to know the magic number for that "certain amount of employess".
-
@ammoQ said:
I'd like to know the magic number for that "certain amount of employess".
My three guesses are: 1337, 666 and 42.
-
-
@ammoQ said:
I'd like to know the magic number for that "certain amount of employess".
About 25-30. Any less than that and, unless it's a startup, there are usually some hidden issues that become evident several months in. At least that's been my experience.
-
My experience has been different. I work for a small consultant company (12 employees), and there are hardly and WTFs. The companies I've worked for were large (thousands of employees) and one had loads of WTFs that led to the section's continuous decline in revenue and budget, while the other has its share of major WTFs, but the section I'm working in is making a good effort to avoid them.
-
@MasterPlanSoftware said:
static int rnd(int seed) {
Fixed that for you.
return 42; //Determined by fair dice (d%) roll
}
-
" so some Paula type (well okay, not her because you actually have to produce code) can get in there and fuck everything up with shitty code, no documentation or source control or tests, $20 routers used for networking, 10x copies of Office but one license ("What do you mean I need to buy 9 more? I already paid for this one!") common home desktops reconfigured as "servers" to save money, and the like."
Sorry, but some very large companies have the same problems. I work for a corporation that's 20,000+ employees. All it takes is for a Paula type to be promoted to dept manager. She's clueless about whether her people are doing a good job or generating WTF's, and the managers above her just trust that she's doing a good job. We also have dept managers that demand that everybody share copies of software because they don't want to budget or pay for legal licenses. Similarly, despite the fact that the corporation is swimming in profits, the dept manager pretends he has no money to train his employees. And actually, very often the corporate beaurocracies get in the way of doing things correctly. For example, we're required to go through certain channels when purchasing hardware. Yet recently we got migrated to a whole new accounting system and the people authorized to do the purchasing were not allowed to use the new software, so some of our projects got put on hold for months while that was worked out. Several years ago replacement laptops were delivered by the IT group supposedly preconfigured and secured. We were not allowed any privilieges, so could only look at files in the My Documents folder, could not change the time, install programs, run degrag, etc. Since the IT dept didn't really have a clue what our group did, they didn't install the software we needed on them and the development tools we needed were not on the corporate list of approved software. So the laptops were completely useless. Despite running the problem up the chain of command, we could NOT get that policy changed.
There are TONS of ridiculous WTF's in large companies.
-
@arty said:
My rate is about 1/2 decent and 1/2 WTF.
Can you give a general overview of what it is like at a NON-WTF job? What types of processes are in place? What type of structure does the code take on?
Do they have code revisions and go back to make things better? etc etc...
Thanks
-
@jetcitywoman said:
We also have dept managers that demand that everybody share copies of software because they don't want to budget or pay for legal licenses.
Quick fix: http://www.BSA.org/reportpiracy
-
I know this makes me part of the problem instead of part of the solution, but.... that would result in the removal of the software we need to do our jobs. You think they'd buy the licenses? LOL. Yep, the same way they were giving us laptops we couldn't use. The same way we have a large part of the organization dedicated to training and employee development that we can't use because our managers won't pay for it.
On the original topic, I'm really curious too. I read all these books about how software development should be done, about how to do project management correctly, etc, but I NEVER see those principals in use in any of the companies I've worked for. We've documented for decades now how projects fail, go overbudget, over schedule, and we know how to avoid those problems. Isn't *anybody* actually using the proper methodologies and procedures?
-
@jetcitywoman said:
Isn't anybody actually using the proper methodologies and procedures?
Possibly. But you must have a soul, and as we all know, as soon as those types of people are promoted to positions of power, they forfeit their soul to the machine known as corporate bureaucracy. The only reason our Engineering department does anything half right is because I helped orchestrate a coup against management (us = US, they = Canada). So, we do things our own way now. They still won't give us the software we need, but thanks to Sourceforge, we can usually find a reasonable replacement.
-
As the above posts indicate there isn't any real correlation between the number/severity of WTFs and company size. I've been at small companies that are just as WTFy as large companies. I suggest that is the quality of management that is the primary cause.
I've had exactly one position where there were good development standards in place when I walked in the door. The rest I've had to institute them along with help from my colleagues. It takes a long time to implement. I'm not just talking about setting up source control and coming up with naming conventions, but teaching the end-users about the necessity for change management, testing, requirements, etc.
As far as not getting the software I need to do my job, I'll either berate my boss until they give in (they usually do, eventually) or I'll find a free alternative.
-
@Lingerance said:
@MasterPlanSoftware said:
static int rnd(int seed) {
Fixed that for you.
return 42; //Determined by fair dice (d%) roll
}Excellent. Much better now.
I wish I could throw some line numbers and a few gotos in there though.
-
@ShaggyB said:
Can you give a general overview of what it is like at a NON-WTF job? What types of processes are in place? What type of structure does the code take on?
A friend of mine once coined what I call "Phil's Law", which is "Any sufficiently large software system becomes Mach". The least WTF systems I've worked on were heavily geared toward putting systems in separate conceptual spaces and using messages to convey work. Ideally, for a medium sized application, you'll wind up with a system that has what amounts to a central bus, and various ways to tap commands and messages from the bus, with each subsystem essentially operating independently from everyone else. In the most elaborate case, we represented the overall application state with a state machine object, and in debug mode, sent verify commands to subparts to trigger state switching assertions. Since the application was user interface oriented, this worked well, because we knew right away when some part of the internal messaging protocol wasn't being respected by a component.
We modified a typical malloc to do object tracking by size (and wrote new and delete overrides) and exposed the results to the QA person. He was merciless about memory leakage (*any* leak, even 4k per week was considered important), and we responded by increasing our discipline about using dynamic heap. We spent a weekend either removing or justifying every 'new' invocation in the app and documenting each with exactly one corresponding delete. In the process, we realized that we could use STL containers much more than we were doing, and also were able to delete some ad-hoc container code. When we were done, we even realized a performance gain by eliminating some heap traffic.
The best work environment I've been in had 3 engineers and was on a project that lasted about 18 months. We worked in a single large room with no walls, and our desks facing, and had good communication. We considered no code sacred and did group refactoring on a projector whenever we collectively felt that a system had been problematic once too often. We had a meeting every morning to take bugs and often took each other's easy bugs just to change things up and learn more about the system as a whole.
The boss in that place is a veteran and knew what he was doing. While he didn't keep perfectly up to speed with the code in our app, he knew the smell of good or bad design and strove for quality, even if it occasionally meant pointing out a feature that had had more than one bug in recent memory and saying 'you guys gang up on this and straighten it out'. We never went forward with features when the app had critical known bugs. Sometimes this meant we stayed late or came in on weekends, but that was very much the exception. If there were few important bugs, the boss would frequently shoo everyone out of the office at 5.
We had a QA person who was meticulous about regression testing and brutal about network testing, often coming up with unlikely scenarios that confounded us for a few day. Even if a scenario was unlikely, it'd be logged as a bug and dealt with seriously if it caused a crash.
-
@jetcitywoman said:
Isn't *anybody* actually using the proper methodologies and procedures?
I have a theory that only those organisation that absolutely have to - because the highly critical nature of their work - do it. For example, those wo write software that controls airplanes or ATMs.
In general, the hypothesis goes like that: "In every organisation, methodologies and procedures are just as bad as the organisation might eventually get away with".
-
@ammoQ said:
For example, those wo write software that controls airplanes or ATMs.
Have you SEEN half the wtfs here? I would say ATMs can be stricken from that list.
-
@MasterPlanSoftware said:
Have you SEEN half the wtfs here? I would say ATMs can be stricken from that list.
I've programmed them, and I agree. In fact, the first big WTF-plagued company I mentioned above was an ATM maker. The basic architecture was questionable, the development process was barely existent, and the management did nothing to improve this. The biggest WTF was probably the issue with one quite large and central in-house API library that was a core part of the ATM software. There were two sub-divisions of development, one for cash ATMs and one for non-cash machines (statement printers, terminals for doing money transfers and the like). At one point the development leaders for the two divisions disagreed intensely on new features for this API library. Management let them get away with forking the library and doing further development of it separately. Imagine the fun when a few years later banks started to merge the cash and non-cash functionalities into one machine...
I'd be careful about judging the ATM screenshots though. Especially the one which showed the debug option. If it were taken on a development/test machine, that would not constitute a WTF. In fact, I could have taken all kinds of wild ATM screenshots when I worked there - too bad I didn't know about this site back then. An ATM running Doom, now that would have been something...
