|
Not really being honest about software working
I was handy some unfinished code a few weeks ago written by the company co-founder. At the very most it is 40% finished. What has been done is buggy.
Today during a meeting I said my task was difficult. The company salesman then spoke up and said the backbone of the work had been done and all that was needed was a pretty user interface for it.
I said nothing more. Then they moved on to the next person and task.
What was said was patently untrue? From what I saw many months ago it seems there is an attitutde of either cluelessness or false cluelessness. If software is a mess it is the done thing to play dumb, ignore the problem, don't mention it and just carry on. People just seem to drift away and leave when being involved on software projects.
Should I leave now? Has anybody else come across companies like this?
Savage
Tuesday, May 18, 2004
What you should have done is grown a pair and spoke up instead of letting a salesman speak for you. You're the software engineer correct? There simply are no excuses for you not telling the truth when asked and to let someone else speak for you that's just plain stupdity.
Come on people, when are software engineers gonna stand up for themselves?
Now look at the situation YOU put yourself in. It is your fault. Now you want out? How weak are you? Very Weak. Very Very Weak.
Wake Me Up Inside
Tuesday, May 18, 2004
Why in the world would a salesman speak to the completion of a development project? What kind of meeting was this? This wasn't a sales call, right?
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
Ok here's a similar sitch with a twist, and I'm curious what the community opinion is.
Suppose you're on a project where the development is going great, but it's obvious to you, the developer, that the business case is coming unravelled -- the project has reached burn-rate, and you don't see any way in hell that the software is going to save anybody any money once it's implemented (it's an internal project for internal consumption).
Much like the OP's situation, the decision makers all talk like it's going great. You suspect they can't not realize it's a money pit, but egos are on the line and no one wants to admit it. As the developer, the project is a peach -- it's satisfying, fun to work on and you have equal input and autonomy over the design and implementation.
So do you blow the whistle or keep your damn mouth shut? (I suspect I know the answer :-) )
offMyMeds
Tuesday, May 18, 2004
Depends on your relationship with your manager.
If your manager is capable of being trusted not to fire you for being honest, then I'd be honest with him. What happens after that is really none of your concern, unless it's part of your job title.
Bear in mind that even though it looks like you're going to be over budget and behind schedule, or whatever, that it might still be better than doing nothing, or tossing the existing project in favor of a new one.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, May 18, 2004
You're a cog in the wheel... smile and collect your paycheck.
Been There
Tuesday, May 18, 2004
Why in the world would a salesman speak to the completion of a development project?
Bwahahahahaha...
Because salesmen know *everything* about the product. After all, they're the ones preselling 300 copies with a promised ship date before it will even compile and promising the customer it will make grilled cheese sandwiches with spare CPU cycles. Who better to comment on the fitness of the code?
offMyMeds
Tuesday, May 18, 2004
Who was this meeting with?
Who do you report to?
Do they realize that the project is a money pit?
Would they listen if you told them it was?
Mr. Analogy
Tuesday, May 18, 2004
Savage, you have to sit there and say: "That's crap and you know it," and then back it up.
Of course the salesman won't like you saying that, but who said he has to like you. It's not your job to be liked.
We all know what's next. They will think you're absolutely incompetent because you take so long on a product that's already finished. They will push you so it will be full of bugs. More evidence you're incompetent.
These are the types of wankers who brag to business mags about poor developers and who outsource.
Tuesday, May 18, 2004
Sounds like it may be a power thing and not a balls thing.
You have to be diplomatic and explain why you feel that way. Metrics help. Charts help. Visuals help. Ask questions that make your point.
"I did an analysis of the milestones on panel 2. Do you think we can hit the last five milestones on time based upon this chart?"
dir at badblue com
Tuesday, May 18, 2004
I must say that this is one of the backhanded benefits of doing internal software development: no marketing games. It works or it doesn't work, and if it doesn't, you hear about from the VP in charge and have to fix it. It actually provides some leverage in being able to say "it's not ready yet."
As for OP, you should have contradicted the salesman, and if your manager didn't back you up, you should find yourself another job.
Justin Johnson
Tuesday, May 18, 2004
One more observation for the OP: Your failure to contradict the salesman could be taken as assenting to his claim that "all it needs is a pretty GUI." So, months from now when sales are in the toilet and support costs are spiralling, and the salesman says that you said it was ready, what are you going to say?
Justin Johnson
Tuesday, May 18, 2004
To answer your questions, the meeting was a routine weekly meeting with the whole company (apart from those away on vacation).
I report only to the company co-founder. There are only two software developers in a company of 30 business type/accountancy people. I am one of those two software developers.
The company co-founder wasn't at this meeting. He is away on vacation.
I didn't speak again after the salesman spoke, because I had said my part was difficult. I don't want to call someone a liar or ill informed. I suspect the company co-founder may have been boasting about his work.
If I said something who knows who I would offend.
I am going to have to do something about this. The question is what. I'm tempted just to resign. I hate situations like this. However I know that I won't get another job anytime soon. The situation is still bad and leaving a job you have only been in 8 months will be taken as a bad sign.
I will have to choose my words carefully the next time I speak to the company co-founder.
Savage
Tuesday, May 18, 2004
Savage, they really need to teach software developers how to stand up for themselves.
The reality is that software is hard and will often take longer and cost more than people want. Tough.
Sometimes you have to be not liked. Anyway, I suspect you are not really liked so much as patronised. Like a pet dog. What's the worth in that.
Contradict the salesman. Tell him he's wrong. Stand there and stand up for yourself.
When doctors have bad news, they don't agree with the patient and say: "Yes, you will probably pull through." They tell it like it is. Developers have to do this too.
Try it and see. You won't be disliked at all. They will respect you more.
Tuesday, May 18, 2004
I think you would have been shot on the spot for contradicting the salesman.
Heres the thing no business person wants to hear about problems, they pay to to solve problems.
Here is your chance to be a leader, don't do this during a metting, find a person that is really in charge and :
a) tell them what really has and hasn't been done
b)Find out when things need to be shipped
c)tell them what needs to be done to ship by that date (not always possible but maybe)... you can cut some features, get away with some bugs, make the UI less pretty... (One company I worked for had the philosophy that on ship date they will send something even if its Britney Spears cds with our logo, this was a quote heard first person from our VP engineering, not a rumor).
d) Put the whole thing in a schedule, and update it daily!
The thing you have to remember as a developer is that business people not all of them, but a lot of them have hard jobs too. And if you don't finish the job on time their efforts are wasted, and they don't like that. But if you work with them rather than avoiding the problem you will get a lot of respect..... or get fired
The Artist Formerly Known as Prince
Tuesday, May 18, 2004
Where do you live, Savage? Because I want to apply for your job after you resign; obviously the economy looks a lot better from where you're sitting than it does from where I'm sitting.
offMyMeds's situation interests me. I'd say, if you have a good relationship with your boss, talk it over with him/her to get a second opinion; there could be things you don't know that mean the software really will be profitable. Otherwise, I don't think keeping your mouth shut is dishonest, and I don't think we have to be cynical about it. The firm's finances aren't your area of responsibility. If you turn out crappy software, your head rolls; if they request software they shouldn't have, their heads roll.
Only thing you have to be careful of is if they blame the money-losing problem on the way your software was designed. But of course you designed it exactly according to the requirements and specs, so that shouldn't be a problem.
Kyralessa
Tuesday, May 18, 2004
The artist makes very good points.
To summerize:
1. You're right that you don't know who you'll offend in a big public meeting calling the salesman "a liar".
2. Go to your boss (if he's intellectually honest) and give him CONCRETE tasks that need to be done. Start with the most obviously difficult tasks. Make sure he understands the first three before continuing. Give him a full summary with suppporting details and a TOTAL of the number of hours.
3. Yes, as mentioned above, you do need to stand up and tell them how hard the programming is (or rather, how much work there is to do). You need to go "on the record" if only as CYA. Do it in a memo, etc. to your boss.
However, you do have to be a bit diplomatic. Firm but sweet.
THE OTHER PROGRAMMER?
BTW, where is the other software engineer on all of this? Does he agree with you? Disagree? Is he being polical and trying to appease management?
You and he need to present a united front. Much more credible that way.
Mr. Analogy
Tuesday, May 18, 2004
"Charts help. Visuals help."
Now, now, see, that's what I'm saying. Flip charts. Flip charts.
Ross Perot
Wednesday, May 19, 2004
Thanks to everyone who commented on my post -- all good insights. It's definitely true that I might be overly cynical. The project was never slated to make / save money; its purpose is to bring automation, measurement and reporting to a line of business that is currently operating with no oversight and collecting no measurable data. I see a money pit because after the software rolls out there are seemingly endless recurring expenses. The app uses Tablet PCs and Sprint's wireless "broadband" to report data from the field. So we've got a whole new department that didn't even use PC's before now requring remote support, not to mention the cost of the wireless service and the tablets themselves. And all of this will to a rockin job of getting the data they wanted, but won't do a thing to add a single dollar of revenue.
But I digress. The advice above is all correct, but I forgot to mention the question is more or less rhetorical because our first wave of parallel testers cuts over to production tomorrow. Hahaha. If I had it to do over again, I don't know if I could have blown the whistle or not. I was the new guy then, this is my first project and this is my first (paying) development job. That might have taken just a little more junk than I have.
offMyMeds
Wednesday, May 19, 2004
Separate your pride and ego from your work. Play the game smart. Don't contradict the salesman in front of all the people. Do it where it counts with the right people who actually make the decisions.
In the meeting, say some stuff about "There are a couple of things that need to be ironed out. I am working extra diligently to solve some of the pending issues of the product." Then leave it at that.
If I needed the money from the job (and who doesn't) and had a gut feel that things are not right, I would swallow my pride and take the paycheck. Play the game. If I didn't need the money, well that's another story.
robtwister
Wednesday, May 19, 2004
These companies are rather common, I suspect. Think of people; many live their lives lying to themselves, glossing over problems, blaming others as if that mattered.
Do you want to leave? Well then, what makes you happy? Pursue that thoughtfully.
Tayssir John Gabbour
Wednesday, May 19, 2004
I went through pretty much the same thing. The problem was everyone at the company was unaware how bad things really were. It was the classic boiled frog syndrome. I screamed and shouted all I could about the problems. Only did have come up with the facts in writing did it make a difference. The problem was once the investors got the message they pulled the plug and the company folded.
Bill Rushmore
Wednesday, May 19, 2004
I think you have two problems, 1) The salesman needs to know that there are some problems, it is unfair to let him work on untrue assumptions. 2) You need to tell the co-founder so he is aware also (this should be your top priority as he has probably been telling people his code is nearly finished).
I have found the best way to point out problems in someone elses code is to ask the person who wrote it for help, say "I don't see how x works in this scenario". Don't say that it's buggy or crap, that will automatically put them on the defensive. Ask them to sit down with you for 30 minutes and run through the code. This way you can ask questions that will lead them to realise the code is not as finished as they thought. The important thing is here to make sure they arrive at the conclusion themselves.
Once the co-founder knows then telling the salesman is probably going to be 10x easier.
However you decide to do it, you should tell them. If you have a problem that needs to be highlighted so upper management can deal with it then you should say so. Being agressive about telling people isn't going to get you anywhere. The top management people can sometimes get away with it, programmers can't.
Steven
Wednesday, May 19, 2004
Steven makes excellent points.
Basically, it's far easier to ask "how will we handle situation XYZ" than it is to say "it won't work in XYZ"
"The project was never slated to make / save money; its purpose is to bring automation, measurement and reporting to a line of business that is currently operating with no oversight and collecting no measurable data. "
If you're interested in the business side of things, this is a GREAT chance to kill two birds with one stone. Ask about the business case for the software.
Unless the software saves or makes money for a business, they won't buy it. That's the bottom line.
Now, providing oversight to a line of business may allow them to increase productivity, cut costs, increase recievables, etc. There are lots of ways this MIGHT make/save the company money.
BTW, understanding the business case is how you find out if the product really meets a business' needs. That increases the value you can add to your company. That's always a good thing.
Ross Perot
Wednesday, May 19, 2004
Note that the sales person did not have any problem contradicting you infront of everyone in that meeting.
Sales people usually have keen sense of what is and what isn't allowed at meetings, so if he felt free to contradict you, you can probably go ahead and contradict him.
someone else
Wednesday, May 19, 2004
Or maybe the salesman's keen sense told him it's ok for the salesman to contradict the developer in the meeting but it's not ok for the developer to contradict the salesman.
:)
offMyMeds
Wednesday, May 19, 2004
1. Do you have a spec that you're coding to? How about a project breakdown and a milestone chart? If not, start working on those.
2. You haven't defined "buggy". Does this mean (a) that the code fails testing or (b) that it works but it's kludgy? If (a) then approach the co-founder with the test data. If (b), you're probably stuck working around it - especially if it's a political issue and raising it will just step on toes and make you out as the bad guy.
yet another anon
Wednesday, May 19, 2004
A couple of weeks ago the company co-founder tried to demo the software to me. He couldn't. The software failed. He then said the software does actually work 30% of the time!
I've tested the software myself. Half of the functionality is a complete write-off. It can't even work for simple test cases. The co-founder said himself it is just a prototype and is flaky. I looked at the code and it doesn't work because quite frankly the code isn't there. This is a fairly big task and quite frankly 1 page of code is nowhere near enough for all the cases and possibilities.
The other half of the functionality is buggy and not finished. I used very simple test artifical cases and it works. In real life use, I can't even get it to work properly - not even once.
Savage
Wednesday, May 19, 2004
I know it's not that easy, but try to make an estimate (better, various estimates), in order to have something concrete to say when the problem arises again. This way, you won't be attacking anyone, whereas wishful thinkers will have to openly contradict you. If questioned, don't overreact, just make it clear that your estimate is not infallible, but is nonetheless the result of careful assessing (have some Excel sheet ready, even if nobody bothers to read it).
And as some have said, tell what you can do and when, not what you can't do.
I wish I were always able to follow my own advice.
Pakter
Wednesday, May 19, 2004
There are tactful ways to disagree with someone at a meeting beside calling them a liar. I think you should have at least mentioned that you disagreed with his assesment and that you would dicuss it in private.
I've learned from similar situations that it's better to keep quiet than to go on the attack, but what's still better is to disagree in the most agreeable way possible. Flattery works.
By the way, I wouldn't quit. All companies are screwed up. Just in different ways and different orders of magnitude. This one sounds reasonable normal to me.
MilesArcher
Wednesday, May 19, 2004
You should have spoken up during the meeting. A simple statement along the lines of "There is still significant functionality that has not been implemented" would do. If you get pushback, assert yourself and don't back down.
Now, you have to do damage control, because the perceived reality is that "all that's needed is a pretty user interface". A strongly-worded email that states the facts about what is and is not completed, along with personal conversations with the owners/managers, may be a sufficient wake-up call. If it's not, you're dealing with people who want to be in denial, and that's a whole different ballgame.
Bottom line is you have to make a stand now and state the facts, ugly as they are, or you will pay dearly later when you are behind schedule.
Should be working
Wednesday, May 19, 2004
"These are the types of wankers who brag to business mags about poor developers and who outsource. "
That's what I believe. But believe me savage, you are not alone.
Sounds like you are in an oral history environement. Oh well, I've only been there, is it really different anywhere else?
It sounds like the guy who wrote the code is honest about it. That is a good sign (though saying something works 30% of the time is odd, it works or it doesn't or it does 30% of the things right and 70% hasn't been coded or, worse, has been coded but is duck soup).
Unlike I guess everyone else in the world I've only been on projects that were finished late with maybe a few exceptions. However, the word is that most projects finish late and everyone believes that (except for the programmers and project managers I've met who say they've never had a project run late ... yes, I meet people who say this). I would not worry about being late on delivery.
Were I you I'd focus on how people are going to determine if it works or not. Then make sure you get that done. Honestly, I sometimes let code go out which has things which can break but if the testers or designers don't know about it, and I'm in a rush, I let it go (making sure it does no harm first). It will later come back as a bug I can work into my schedule. On the other hand, if I have time, I'll fix it even though then no one will ever know. Everywhere I've worked bugs are expected. Heck, I even use this operating system called Windows 2000 and I hear they have the smartest people and the most money and you know what, there are bugs in it.
The world is not perfect. Do what you can. Slowly try to improve things, but enjoy life while you are at it.
me
Wednesday, May 19, 2004
 Recent Topics
Fog Creek Home
| 
