Tag Info

Hot answers tagged

120

But my current company insists on my being there at 8:30. Any deviation from this is a big deal. Is this typical? Yes it is typical. And companies like that tend to have very high turnover with developers. I was chatting with one of the project managers I used to work with (he's now a VP with some other company) and he was describing the policy at the ...


46

I'm stealing this answer from somewhere on SO. I can't seem to find the original author but the answer stuck with me. Pointy Haired Manager: how long will this take? Employee: hard to say, a month? maybe a month and a half? PHM: We need a better estimate E: Look, how long does it take you to drive to work? PHM: Huh? 30 minutes why? E: 30 minutes plus ...


37

Software estimation isn't actually more difficult than estimating other types of work. It just seems so because the CONDITIONS under which it's estimated are more difficult. Say a software company was tasked with something similar to what a car company is tasked with. Build the same thing over and over again, which has existed for decades, and with only ...


37

I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling. That's fixable. Make them involved in scheduling.


25

I'd use a scoring algorithm. Each person starts with a score of zero. Each time they bring croissants, increment their score by 1. The score of all team members who did not bring croissants is decremented by 1/N. Thus a score of 0 means that a team member has neither over or under bought. Without randomness, choose the person with the lowest score out ...


22

Software development isn't a manufacturing type process where people are essentially interchangeable resources. It’s a creative process that works within the collaborate environment of a professional team that takes into account individual abilities and skills. It’s not making widgets, packing boxes or flipping burgers. In fact, these kinds of throwing more ...


20

Joel Spolsky wrote an article on Evidence Based Scheduling that may help you find some arguments. You have to convince your co-workers that better estimation skills can help them produce better software. Here are some points in favor of tracking task time: If you have an arbitrary management-set deadline, good estimations will tell you what you can ...


17

I have never been happy or productive at companies like this. You won't like the code either, because these shops tend not to retain good developers. Get another job where the managers have a clue. There are lots of them.


15

it's because the last 20% of the project usually take 80% of the time. The initial outline is probably because people often base the total time based on the core mechanics, without realizing the finer details of the project. It's less of a programming question and more of a psychological question in my opinion. You ask a person how a helicopter or a lock ...


14

One of the (reasonably legitimate) reasons I haven't seen mentioned yet is that in many/most companies, support issues get escalated to the developers who know their product. To avoid critical production support issues going unanswered, the company expects the developers to be at their desk for the full client business day. In a past company I worked at, it ...


13

It's normal, but it shouldn't be. I am a major advocate of the fact that we as developers should not be treated the same way as other office staff, because the nature of our work is vastly different and is not quantifiable by being at your desk for 8 hours. In fact from my experience, being forced to be at your desk 8 hours a day fosters the desire to ...


13

You really need to talk to your boss about this and set some ground rules: A deadline is not a deadline unless you commit to it. An estimate is not an estimate unless you give it, and then it is an "estimate" not a hard deadline. Robert Martin's Clean Coder has a really good chapter about how to communicate this stuff to your boss. It is not your fault ...


10

You can accomplish this in the standard way - carrots and sticks. The carrot(s) in this case could be "improved future estimation by understanding our current velocity" - but you would have to follow through. Your comment that they are not often involved in project scheduling may make this a tough sell. The most high-functioning among them, particularly ...


10

A while back I worked for a major investment management company. Most people connected to their core business got there no later than 6:00am. Most devs came in no later than 8:00. But I liked to come in at 10:00. (I still got up early, but I like to exercise for a couple hours first. lol.) My boss? He couldn't have cared less. All he cared about was results. ...


10

Have you guys been in similar situations? What has/hasn't worked for you? Mostly what works is speaking truth to power. Gather the facts. Present the facts. Leave the customer to learn (or not learn) at their own pace. My team is blamed, feels discouraged and there's an overall atmosphere of defeat. Why is your team aware of the blame? If the ...


10

The measure of how good scheduler is would be average/total wait. Assume you have a set of jobs J, within these you have job x which is the longest. Let y be any other job. If you put x last, total wait time of the jobs executed before will be total(J)-time(x), while for any other it'll be total(J)-time(y). Thus only putting the longest job last minimizes ...


8

In my experience, the following are the problems with most time tracking software: The developer does not have the ability or authority to break down a task into more easily estimatable subtasks on the fly. There is no good way to account for subtasks you didn't know about until you started working on something, a situation which comes up all the time in ...


7

Because you have potentially infinite variables to estimate against and you have users that don't really know what they want (or can't accurately express what they want). "Design a car for me". You design a car, but they really meant a truck. Well, it DOES have wheels, right... When we estimate we try to get the first estimate within 25% and the second ...


7

I disagree that an Agile project has no upfront plan. My experience is that the business analysts have spent a fair amount of time working in design meetings with customers and developers to come up with a detailed list of achievable requirements that are presented as user stories. These are then broken down into tasks with suitable estimates attached by ...


7

Joel Spolsky says that a software development team is a scheme for converting capital (money) into working software. Honestly, from your question, it sounds like your team is good at that: you're getting decent software for reasonable amounts of money invested. Now, of course the next step is to put the software into service. Until your company chooses to ...


7

What I would do, if I had to pick this, is get a hat, and put everyone's names in the hat once on little pieces of paper. Then each day, I'd draw someone's name from the hat at random, and that's the person who brings the croissants the next day. That paper then gets tacked up on a board, under "BRINGING CROISSANTS TOMORROW". The paper that's currently on ...


6

Run, do not walk, to get Software Estimation: Demystifying the Black Art by Steve McConnell. The first few chapters are full of answers to the exact question that you are asking. If you come away with nothing else, come away with an appreciation of Tom DeMarco's observation that in most organizations the definition of an estimate is, the most optimistic ...


6

Good way Use software, which actually makes that easy and almost transparent, like for example Mylyn. Combine it with tools like for example an hour burn-down chart. Bad way Force them to fill in tedious timesheets, where you have to manually specify project, task, exact dates and times etc.


6

Do you have a shared database? I've done this using a database as the arbiter in the past. Basically, each "job" is represented as a row in the database. You schedule a job by adding a row to the database with the time you want it to run then each server does: SELECT TOP 1 * FROM jobs WHERE state = 'NotRun' ORDER BY run_time ASC That way, they'll all ...


6

Every company I have ever worked for has core hours. Some are more liberal, some are more strict, but the intent is that employees are more productive if they can consult their coworkers about problems. If one developer likes to be in at 5:30am and out at 2pm, and another is in from 10:30 to 7:30 and takes an hour lunch, then there isn't much time to ...


6

Scrum leans towards eliminating slack Yes and No. Scrum forces you to make an intelligent "time for innovation and other good things". "Other good things" are what retrospectives and daily stand ups are for. "innovation" is what technology spikes or spike solutions are for. They don't go away. They aren't buried. They become first-class, ...


6

Algorithm, smalgorithm. Use a DB. create table team_members ( id integer auto_increment, name varchar(255), purchase_count integer, last_purchase_date datetime, present integer, prefers_donuts integer default 0, primary key( id) ) Who buys? select id from team_members where (present = 1) and (prefers_donuts = 0) order by ...


6

You should be using a Priority Queue here. A Priority Queue is a queue in which items added to the queue have a priority, and whenever you get an item, you get the item with the minimum (or maximum, depending on implementation) priority. Priority Queues are generally implemented using a min-heap (or max-heap). It will logically represent the data as a ...


6

In principle, the idea is good, and it solves a real problem: what do you do when the developers of two other programs have chosen priorities 12 and 11 for their processes and you need yours to be in between those two? However, there's two problems: You need to do a topological sort of the priority graph every time a new process is created or its priority ...


5

Building a bridge isn't so precise. In fact, I would bet they usually run over budget as well. I know a planned tunnel b/w NJ and NY just recently got canceled b/c of overruns. And think of all the (American) football stadiums built recently that all go over original estimates. Just grab some of those examples, and drive home that building things we can ...



Only top voted, non community-wiki answers of a minimum length are eligible