The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Should I contine working at a "push-driven" company?

I'm running into what I consider a possible conflict of interest.

I'm currently a full time (15-17 hours) college student, and have been working for one of my old professors part-time. We're doing development for a data acquisition project, involving collecting a lot of data from hardware and then analyzing it.

The only other programmer (and the only full-time employee) is a programmer from the C era that programs in functional programming.

We recently received all new hardware for our systems, and thus I have to modify his old programs to work with it. Our boss seems to think that it's perfectly normal to make a push this weekend of working 10-16 hour days to get things working, and then do the same the next weekend, and repeat. We're shipping this completely untested hardware out in about a month.

Personally I believe he doesn't understand how software development should work. He's expecting us to get things working, and then ship the system to the customer, defect-ridden or not. The two previous systems before I started worked the same way: They were shipped a week after becoming operational (and were bug-ridden when they arrived).

Is this release-and-fix-afterwards design plausable or should I just run away from the job and attempt to find something a bit more sane? I just get the feeling he's expecting me to be a full-time employee when I was hired as part time.
Josh McFarlane Send private email
Thursday, February 09, 2006
Sounds like you work for a lousy company.  It's getting harder and harder to attract good people to companies that operate this way.
Sassy Send private email
Thursday, February 09, 2006
Hi Josh,
Many developers these days find themselves in similar situations. You just have to answer one question: do the cost out-weigh the bennifits? It sounds to me like you're busting your ass over something you don't think you're going to feel proud of at release time, so the satisfaction bennifit is gone. Do you get paid enough for the hours you're expected to put in? Does this job help your schooling? Do you have other options for work?

The very fact that you're asking if you should leave tells me that you've already come to your conclusion. I'd say put your resume out there and see what bites. If nothing else, an offer from annother company can give you great leverage in changing the things you don't like about your current job.

Also keep in mind, it's not uncommon for companys to take advantage of young developers who don't really know what they're worth yet. When I first started my carreer, they paid me less than half of what indicated I should be making. I had to threaten my company with quitting in order to get the raise I deserved.

-Bryan Crow
Bryan Crow Send private email
Thursday, February 09, 2006
You have two problem, "death march" and "ship-then-fix".

A death march is when you work yourself to death in order to hit a deadline. They are not /always/ a bad sign, but if they happen too often then they tend to point to a problem in the process.

In other words, sometimes life just comes along and sets you back and your forced to go on a death march in order to meet a critical deadline. But if you run into this problem all the time then it means you're not planning you development cycle properly. This is what it sounds like is happening here.

The "ship-then-fix" problem isn't a problem itself unless, like you have happening here, it is tied to a continuous death march. Every software has bugs and if you don't ship until they are all gone then you'll simply never ship. What you have to do is get a feel for what issues must be fixed, what issues should be fixed, and what issues can wait until you have time. This is more art than science.

It looks to me (given, I'm only hearing your side here) that your boss is poorly scheduling the project and your paying the price in both stress on your and the number of issues in the shipping code base.
NotTelling Send private email
Thursday, February 09, 2006

I originally took this job as a foot-in for programming. I'd had very little experience prior to this (mainly VBA in Access) and this has been a good experience to learn the new language.

I just cannot develop fully-featured reliable systems on a 1-2 month development time for the 5-6 different acquisition programs we have. I end up putting in 10-15 hour days, after going to school for 5-6 hours, and then making a bunch of stupid mistakes that cost me more time the next day when I haven't worked as long.

I would expect something like this to get down to crunch time right before release, or in game development, but even they have a huge lead time on initial development to production. Here it seems like "crunch time" working is the entire development time, due to the small-lead times we have.

The money aspect has never really bothered me as long as I'm learning. I've got college fully funded from scholarships. I think I will wave my resume around a few places and see if I get any bites.
Josh McFarlane Send private email
Thursday, February 09, 2006
40+ hours a week wont do wonders at all, especially if you want to be agile.
If you work overtime a week, then the next week should make up for the overtime.
In all, it should be 80 hours in 2 weeks. So if you put in 80 in the first week itself, you know the chap has no idea of software development. It's same story in every mis-managed place and it's resume time.
Vineet Reynolds Send private email
Thursday, February 09, 2006
Academia does not consider this "work" per se, but as hobby style research and development. Err... to put it another way, my artificial intelligence professor back in college would regularly put in 80 hours a week because he was genuinely interested in his project, not for a paycheck.

So the fact that the professor is a little out of touch with "real life" expectations is not surprising.

In his defense, academia usually has an entirely different set of priorities when it comes to producing a final product; they're concerned with whether X proves (or demonstrates) Y as opposed to concepts like market share and profit margin.

I would stay just long enough to get a passing grade, and then leave - it's obvious your interests don't match his.
Thursday, February 09, 2006
Given that he is a professor, he shouldn't dump this sort of load on you knowing you are a full time student. Working for a professor usually means low pay in return for a job that respects your in-school status - so you don't have to work during finals and there's no hard deadlines. Walk away and find a better job. You can find ones with that schedule that pay $100,000. If he's paying you only $25/hr, it's just not worth it.
Art Wilkins
Thursday, February 09, 2006
push harder. stop complaining. good businesses are understaffed, ship then fix, abandon and upgrade.
Anon and anon
Thursday, February 09, 2006
"good businesses are understaffed"

Actually, it is businesses on the verge of failure that are understaffed. Successful businesses make enough money to hire enough staff for the work available.
Art Wilkins
Thursday, February 09, 2006
+1 for Art's point about college jobs.  I had a job in college that didn't pay great (actually it paid hourly), but the hours were incredibly flexible so I could make school my priority.
Thursday, February 09, 2006
I got lucky in college and my part-time gig even had a very good health insurance plan.
Cory R. King
Thursday, February 09, 2006
Your professor is running his business like it's a university research program, where you tinker in the lab 60 hours a week and then write the paper on the plane on the way to the conference based on what you've got so far, no matter what it is.

That's all he knows; you'll never be able to change the process.

The only question is:  do you have better opportunities?  If yes, take them, if no, suck it up and keep working on creating better opportunities.  If that means focusing on schoolwork and giving up the side job, so be it.

Thursday, February 09, 2006
Your focus is school, not the part time job.  If this job impacts your studies quit without hesitation.
Bill Rushmore Send private email
Thursday, February 09, 2006
A Time Management Seminar for Professors, perhaps? Hehe. After the 'How to make sure my shoes match before leaing the house' Seminar.
nananon Send private email
Thursday, February 09, 2006
"from the C era"

did anyone else find this funny?
Shane Harter Send private email
Thursday, February 09, 2006
> A death march is when you work yourself to death in
> order to hit a deadline.
> -- NotTelling

I thought a "death march" was a project that [some of the project workers realized] was invariably headed to its own doom; be it cancellation due to excessive project defects, customer dissatisfaction, budget, deadline, mismanagement, politics, etc. ?
Ian Johns
Thursday, February 09, 2006
My personal experience (though very short) says everyone / company would push you to work hard and long hours. Part time is just an excuse to pay lesser. When some give you the work, i don't think they distribute the work keeping your pay in mind. Practically now very feasible too. So i find it best to negotiate per hour fee when not joining as full time employee anywhere.
Abhishek Goyal Send private email
Thursday, February 09, 2006

From your description of the company, owner plus one full time developer and one part timer, the routine you are in is almost inevitable. It is very hard on the developers and doesn't make the customers very happy either.

I have been at a number of such companies, and this is always what happens when there isn't enough money to have a QA function.

I assume the owner bangs on the programs a bit before they go out, and that's the QA?
dot for this one
Thursday, February 09, 2006

Edward Yourdon, who wrote the book "Death March", defines a death march project as, "one for which an unbiased, objective risk assessment ... determines that the likelihood of failure is >= 50 percent." So it is possible for one to succeed.

He goes on to identify four possible types, based on the degree of happiness and chance of success:
 - Mission Impossible: happy, some chance of success
 - Kamikaze: happy, high chance of failure
 - Ugly: unhappy, some chance of success
 - Suicide: unhappy, high chance of failure
EKB Send private email
Thursday, February 09, 2006
And Shane, yes, I thought it was funny. But I'm used to feeling like I'm from another era.
EKB Send private email
Thursday, February 09, 2006
I am not that old, but I sometimes feel like I am from the C era.

I am not sure this type of job is good for you, even from an experience standpoint.  You are getting experience in just how not to do software development.  If you use this as a learning experience and never get yourself into that position when you are out of college, then maybe at least you will have helped yourself avoid that future. 

I would say that you should at least have a talk with the guy and let him know that this is interrupting your studies.  Maybe he will let you scale back the insanity, and/or get another programmer. 

Also, for this kind of commitment you should be getting very good money, or a significant share of the company.  Get paid your worth, not your wage.
Josh Volz Send private email
Friday, February 10, 2006
you're a college student, so it is probably okay to continue to work here. You don't have to work here after you graduate. But, be warned - a lot of places operate in this code-and-fix environment
Patrick from an IBank Send private email
Friday, February 10, 2006
"from the C era"
"did anyone else find this funny? "

Having lived through the C era, yeah it was definitely funny.
Crazy Old Guy
Friday, February 10, 2006
I wouldn't work for any company that was headed by a professor if the vast majority of his life was spent working in academia.

Most academics make very, very poor CTOs.  Big on ideas and advice but short on actual understanding of how complex development works.  They seem to be stuck with a mindset that says software can be written easily if you follow "rules".

I've worked with academics who lecture on concepts such as usability, reliability, availablity and performance, and they don't understand how complex it is to actually implement these (obvious) requirements successfully.  I've also worked with a number of PhDs who know all the concepts and algorithms but can't code them.
Sunday, February 12, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz