The inverse law of urgency
-
The more urgent a feature is, the more useless, hours long, meetings a day you shall have! :omg: :rolleyes: :((
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Also, the feature is really not that important and gets in the way of one that is... :(
-
The more urgent a feature is, the more useless, hours long, meetings a day you shall have! :omg: :rolleyes: :((
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
And it gets cancelled next week.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
The more urgent a feature is, the more useless, hours long, meetings a day you shall have! :omg: :rolleyes: :((
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Some years back, I did a project for a company whose weekly schedule went something like this: Monday: 8:30-12:00 - Weekly MMM (Monday Morning Meeting) to assign and prioritize tasks to be accomplished this week. Everyone's presence required! Monday: 1:00PM-3:30 - Sales goals and prioritization for this week. All department heads, technical and support people required to attend. Tuesday: 8:00AM - Emergency meeting to analyze customer's problem reported Monday. All departments heads, technical and support people must attend to determine who will fix problem. Tuesday: 1:00PM - "Hot" sales call pre-call meeting to plan sales call meeting. All Dept. heads, technical and support people required. Wednesday: 7:30AM - Emergency meeting to provide sale call support. All Dept heads..... Wednesday: 1:00PM - "Quick" meeting to check on week's progress. All Dept..... Wednesday: 4:00PM - "Who's available for overtime" meeting. All..... Thursday: 7:15AM - "Why isn't anything getting done" meeting. All.... Thursday: 12:00PM - Team building luncheon. Meal and drinks provided by company. EVERYBODY requi..... Friday: 7:00AM - "What can we do to improve productivity meeting?" All... Friday: 1:00PM - Emergency meeting to determine who will be working this weekend to catch up. All...... Friday: 3:00PM - "So-and-so's going away party." Must attend! I might be exaggerating a touch, but some days I spent as much as 7-8 hours in meetings which had little or no bearing on my assignment. Typical week averaged about 20-25 hours in meetings, usually during prime productive time. Their idea was that "inclusion" was important and "everybody's ideas" were welcome (but they didn't really want to hear them.)
-
The more urgent a feature is, the more useless, hours long, meetings a day you shall have! :omg: :rolleyes: :((
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Could be worse. Meetings halt progress but don't bear anti-progress. Doing something exactly the way the customer (in my case, the product management department in the same company) wants only to find that I have to redo the whole backend because they didn't tell me of a "tiny" feature they totally need in advance, that's anti-progress. I'd rather sit in countless useless meetings than either create a patchwork solution I don't understand myself or redo the thing from scratch time upon time.
-
Some years back, I did a project for a company whose weekly schedule went something like this: Monday: 8:30-12:00 - Weekly MMM (Monday Morning Meeting) to assign and prioritize tasks to be accomplished this week. Everyone's presence required! Monday: 1:00PM-3:30 - Sales goals and prioritization for this week. All department heads, technical and support people required to attend. Tuesday: 8:00AM - Emergency meeting to analyze customer's problem reported Monday. All departments heads, technical and support people must attend to determine who will fix problem. Tuesday: 1:00PM - "Hot" sales call pre-call meeting to plan sales call meeting. All Dept. heads, technical and support people required. Wednesday: 7:30AM - Emergency meeting to provide sale call support. All Dept heads..... Wednesday: 1:00PM - "Quick" meeting to check on week's progress. All Dept..... Wednesday: 4:00PM - "Who's available for overtime" meeting. All..... Thursday: 7:15AM - "Why isn't anything getting done" meeting. All.... Thursday: 12:00PM - Team building luncheon. Meal and drinks provided by company. EVERYBODY requi..... Friday: 7:00AM - "What can we do to improve productivity meeting?" All... Friday: 1:00PM - Emergency meeting to determine who will be working this weekend to catch up. All...... Friday: 3:00PM - "So-and-so's going away party." Must attend! I might be exaggerating a touch, but some days I spent as much as 7-8 hours in meetings which had little or no bearing on my assignment. Typical week averaged about 20-25 hours in meetings, usually during prime productive time. Their idea was that "inclusion" was important and "everybody's ideas" were welcome (but they didn't really want to hear them.)
Wow... That is just like my previous company.
-
Could be worse. Meetings halt progress but don't bear anti-progress. Doing something exactly the way the customer (in my case, the product management department in the same company) wants only to find that I have to redo the whole backend because they didn't tell me of a "tiny" feature they totally need in advance, that's anti-progress. I'd rather sit in countless useless meetings than either create a patchwork solution I don't understand myself or redo the thing from scratch time upon time.
Your reply touched a nerve for me too. I am tired of hearing "Well, I believe that everyone should expect that if I said I wanted "Feature A", that it also meant I wanted "Feature B". When I ask for specific written instructions I get "Well, I can't do that!" I am a single programmer working in a small company, directly for the owner of said company. :sigh:
It would be so much easier if they knew, or at least thought about what they asked for up front.
-
Your reply touched a nerve for me too. I am tired of hearing "Well, I believe that everyone should expect that if I said I wanted "Feature A", that it also meant I wanted "Feature B". When I ask for specific written instructions I get "Well, I can't do that!" I am a single programmer working in a small company, directly for the owner of said company. :sigh:
It would be so much easier if they knew, or at least thought about what they asked for up front.
I take it upon myself to ask those detailed questions up front - and keep asking them until I get an answer in writing. Then I at least have CYA'd myself. It also helps if the developer knows the industry really well, because then you can tell the customer that they didn't think of this feature or that consequence. I understand that not all developers have the luxury of being experts in some random other field, but it does help. Bond Keep all things a simple as possible, but no simpler. -said someone, somewhere
-
Your reply touched a nerve for me too. I am tired of hearing "Well, I believe that everyone should expect that if I said I wanted "Feature A", that it also meant I wanted "Feature B". When I ask for specific written instructions I get "Well, I can't do that!" I am a single programmer working in a small company, directly for the owner of said company. :sigh:
It would be so much easier if they knew, or at least thought about what they asked for up front.
Hey, thanks, you actually help me feeling better about this nonsense, I'm not a lone! :) Did you also have situations where you get a "spec" which is a prosaic description of what they want to be able to do, reply with a stiff spec of what you're going to build, they say "Yup, that's exactly what I want", you build it and back comes "but I can't do X" with X being explicitly forbidden by the spec they agreed to?
-
Hey, thanks, you actually help me feeling better about this nonsense, I'm not a lone! :) Did you also have situations where you get a "spec" which is a prosaic description of what they want to be able to do, reply with a stiff spec of what you're going to build, they say "Yup, that's exactly what I want", you build it and back comes "but I can't do X" with X being explicitly forbidden by the spec they agreed to?
Yes. Repeatedly since 1978 when I first started working professionally. I believe that most users do not have a clue of what they want until they see part of it.
Ours is not the reason why, ours is but to do and die...
-
Yes. Repeatedly since 1978 when I first started working professionally. I believe that most users do not have a clue of what they want until they see part of it.
Ours is not the reason why, ours is but to do and die...
Yeah... I just wish they were honest for once. Instead of an "Yup, that's how I want it" and a "No, redo it" afterwards, an "I am not sure if that's exactly it, points 1 and 2 I like, the rest no idea" would have spared me countless wasted hours. That, and I think it's a linguistical issue at times. I had repeated cases of someone agreeing to me suggesting handling certain stuff implicitly while describing how they want it to be done in a rather explicit way. Literally "Yes, that's exactly how I want it. Also, add X" with X meaning the exact opposite of what I just said. I wonder if it's really people understanding words differently or just not thinking in the ifrst place.
