Fog Creek Software
Discussion Board

Monumental Incompetency- Part TWO

This was a post that i posted earlier. An understanding of it is not required though

I had a huge fight with my PM wherin i essentially told him he did not know his job. I was given a reasonably simple task.
Dump data from some tables into a view first, read from the view and dump it into another table (Table Y).

What they did not mention at all was that Table Y already existed. I protested saying that i did not know . THey replied back saying that it was "Commonsense" and i should have "asked them" about whether a table already existed.

I finally flipped the lid. I shouted at them and they shouted back at me. Later me and my project manager patched up- sort of.

I do try to be a bit conscentious although my original post did not seem that way,. Here working is proving to be impossible. Every day, some new stupidity comes to light.

Once i implemented a password encryption scheme for my program. After i encrypted my passwords in the database, they tell me that another program ( a big one)was accessing it.
I mean, how can you ask a programmer to encrypt something in the dataabse and not even think about other programmers who may be using it?

These folks are kind and good. But dont know their job.

Monday, June 7, 2004

Sorry . What i meant was i need to create a view reading from a set of tables. of course, views dont exist with data stored in them.

Monday, June 7, 2004

These are only 2 instances. Almost everyday i face the same issue. life is becoming tough.

Monday, June 7, 2004

Reading information from your old post, and your new post, I think I see what the problem is.  Feel free to correct me if I'm wrong.

You're working like you're in school still.  They tell you to do something (homework assignment), you take the assignment at its word and do it.  And you get mad because you did the problem just like they asked, but it didn't solve their problem.

As an aside, If I were asked to take data from a view, and put it into another table, part of solving the problem would be to see if the table existed.  You have to define the bounds of the problem, before you can have a solution.  Now of course all of this depends on how they phrase it to you, but part of solving the problem is investigating it.  Not just jumping into the problem as stated and coding it up.

The password encryption system fits this mold even more.  No database if its attached to a network will go for long with only one program accessing it.  As well, part of writing the encryption scheme should be to figure out who will access it.

Of course, I'm commenting without knowing the full story, and I apologize if important parts were left out that I'm not taking into account.  For instance if they don't give you access to a test database, or other programs.

But I think the point still stands.  In school, most problems have been given before, so the professor knows how to ask them, and even if they ask the wrong problem they can grade it accordingly.

In business, they don't know what they want and they ask you for something else they don't want.  Question everything.

Andrew Hurst
Monday, June 7, 2004

Spot on Andrew!

I think the problem here is as much of management not giving you complete information as it is of you not asking enough questions.

During college, the assignments given are simpler in comparison to the ones given in a professional environment. You do not need to do so much of algorithm generation and impact analysis. And best of all, you do not need to work with someone else's (maybe messed up) code.

However, once you start working, many new issues crop up. Management often does not have enough time to give you all the information that you need (although they should at least give all the information that they have). And face it, if they have to analyze the problem, evaluate how to implement it, its possible impact, points to consider while coding etc etc, then might just as well do it themselves.

So rant about it if you must, but learn a lesson from your experience and stop assuming that the task description that you have been given is complete in itself. Start asking questions; even simple ones like who is going to use the data that I'm dumping into this table, how are they going to access it, why do they need this data, when is the table going to be deleted, will there be updations to the data, is someone going to synchornize this table with the main table etc. Such questions will not only help you in getting a better understanding of the problem, but also might throw up useful information to better implement/tune up your program.

Also, this might help you:

Tuesday, June 8, 2004

Monumental Incompetency

that's Microsoft programmers.

some dude who think MS programmer should be anally fucked if they can't fix their code
Tuesday, June 8, 2004

From reading withheld's first (linked) post, he might have had some trouble finding a table named 646456 that served the purpose.

Almost Anonymous
Tuesday, June 8, 2004

OTOH, if the OP was given a spec it should have been complete and included this info. If he wasn't given a spec then the people concerned should have reviewed the spec that the OP wrote before he did the implementation.

Tuesday, June 8, 2004

I'm bemused as to why MS programmers should be rewarded for writing bad code.

Simon Lucy
Tuesday, June 8, 2004

If you had to give a spec for every silly single task nothing would ever get done.


Simon Lucy
Tuesday, June 8, 2004

"In business, they don't know what they want and they ask you for something else they don't want.  Question everything."

This is so true. Software developement is evolutionary process. You design, implement, review, improve design, implement changes, review once more and so on.

While you are doing it, the customer learns, the developer learns, everybody learns from it. And if there were no boundaries such as deadlines and money, the process would keep going endlessly.

In reality it is seldom possible to give a spec that detailed a developer could write a code blind to the circumstances around the block of code he is writing. So involving people, asking questions and background inf as you go helps tremendously.

And of course, if say customer is is involved at all stages actively, he will have hard time telling afterwards that this is not what he wanted. :)



Tuesday, June 8, 2004

"If you had to give a spec for every silly single task nothing would ever get done."

No. If you had to give a bulletproof spec for all work, project managers might actually have to do some work to justify their vastly overinflated salaries, and clients might actually have to make a decision as to what they want, and stick to it. Both would then no longer be able to blame coders for the dismal failure of their excuses for projects. Poor dears.

Let's be clear - you can only really work one of two ways. Either you specify everything down the nth degree, and the developer follows the spec religiously, or you give guidelines and the developer has to make decisions about the specifics - and have the authority to do so.

Some of my developers are currently working on a project with a constantly changing 'spec', but are not allowed to make any decisions. The database schema is owned by a clueless DBA. And the project is being 'managed' by someone who thinks that one meeting every six weeks is all the management the project needs.

Things like this just make me want to go postal...

Neil Hewitt
Tuesday, June 8, 2004

So you want a written spec to cover appending the content of one table to another?

Perhaps, depends on the context.

I'm unlikely to specify how to empty the bin, make coffee or answer the phone.  However, some people seem have needed this at different times.

Simon Lucy
Tuesday, June 8, 2004

How big is the team that you work in ? How many developers ?

It sounds to me like your PM spends a lot of time supervising your and you spend a lot of time 'educating' your PM. It also sounds like you are a bit inexperienced in working in a large development.

So, someone should be supervising you and helping you to deal with these issues. Some are commonsense, some are your PMs issues, some are training and mentoring issues. you shouldn't have to come here to get those insights. Whoever designed your job - that is the person who is incompetent.

Tuesday, June 8, 2004

Just a couple of things to say:

Impact Analysis
Change Management

Tuesday, June 8, 2004

I ran into similar development scenarios when I started work out of college.  The one thing I did was ask lots of questions though.  The other posters are all correct - you need to really work to define the scope and impact of your programs/jobs/scripts before coding them.

And ask lots of questions.  If you're creating a view to append to a table, why are you creating a view?  Wouldn't a straight query be just as effective (getting the given data from several tables into a given format) without necessitating the creation of a view.  And if they do want a view for reference later, and the tables are large/the joins are expensive/ and the queries occur daily, maybe a materialized view (Oracle) is a better idea.

Your PM might not know all the technology - so things will be described to you using on language and you need to ask questions to clarify and move the request into your language set.

Herewith, the best line you can use when given a spec/request:

"Let me repeat back what I heard so we can see if we're on the same page..."

It works wonders. Good luck.

Tuesday, June 8, 2004

> So you want a written spec to cover appending the content of one table to another

Since it then becomes part of the system, yes I do. Otherwise in five years time someone comes along and says "wtf does this do?"

Tuesday, June 8, 2004

Where do you keep the spec?


Tuesday, June 8, 2004

this whole thread demonstrates why college educated programmers are ALWAYS inferior to self-trained programmers.


muppet is now from
Tuesday, June 8, 2004

You write a spec if the risk level says you need one to mitigate what can happen without it.

Without a spec, folks will spend Y amount of time rewriting the code due to poor specs and/or understanding unspec'd code currently in the system.

With a spec, you spend Z time writing the spec to prevent folks from spending the Y time for not having the spec.

If Z>Y, you don't spec it, otherwise you do spec it.  Either way, you're saving overall effort.

It's all cost-benefit, and/or risk mitigation, depending on how you view it.  I tend to favor specing it because most people vastly underestimate the impact of failing to spec it properly.  People also vastly undersestimate how long code/design will be in use ("Oh, it's just quick and dirty for a demo, we'll rewrite it later").

Chris Kessel
Tuesday, June 8, 2004

get over it!
you have had a bad experience. learn from it.

next time use your brain to challenge what you're asked to do, do not just obey orders, think about what you are doing...
you are the expert you should be aware of the implications of modifying code or data 
a PM is a PM not a developer….

Tuesday, June 8, 2004

"Common sense" is a very, *very* relative term.  Generally people use it to describe anything that's fundamentally obvious to them, but don't take into account that it may not be obvious for someone else.  This is especially problematic in the world of software development, since programmers and "normal" people have very different ways of thinking and varying levels of communication and other soft skills.

In this case, it's going both ways.  You and your PM have mismatched views of the world.  To you, it's common sense that he should provide you with all the details.  To him, it's common sense that you should be able to figure out the details.

The answer here lies in finding a middle ground.  If you try to make him responsible for telling you every little parameter of a project up front, he'll feel like he's babysitting you, which won't put you on his good side.  But if you don't get enough info, you'll inevitabely do something "wrong" because you weren't aware of how it should be done.

I happen to have the distinct pleasure of working directly with my CEO, who happens to know just enough about database-centric app. dev. to be quite dangerous, but not enough to really understand how things work.  My approach with him is to take what he asks me for back to my office, think about it for a while, gather information, then go back and ask him questions to fill in the gaps.  At the same time, as someone above suggested, I read everything back to him to make sure it's what he wanted.  I put emphasis on figuring out as much as I can on my own, and using as little of his time as possible, while still giving him final authority.

Tuesday, June 8, 2004

While reading this discussion I noticed people either said to write a spec for everything, or only the really important stuff.  I think you should have a spec for everything but that previous commenters missed an important point.  Computer Science majors are never taught that they should spend 6 months on every project writing the spec, they are taught that only something like 20% of our time should be spent doing actual coding.  So if you can whip up some code in 20 minutes, then it would be entirely appropriate to spend at least 10 minutes asking questions, 10 minutes designing the thing, 10 writing some documentation, etc and treating the project like its a real job, and not something that you pulled out of your @%#%@.

Tuesday, June 8, 2004

"Either you specify everything down the nth degree"

Isn't that calle a SOFTWARE PROGRAM ?

If you could really spec out a program and toss the spec over the wall to a programmer with no iterative interaction then all programming jobs should and will go to the lowest bidding code monkey (probably in India. No offense to the Indians).

As someone above said: software development is an ITERATIVE PROCESS. In the real world part of the  job is helping to define the problem.

I actually have had the opposite problem: I'll question why something has to be a certain way and an (otherwise competent) boss would get frustrated because I wouldn't just do what he asked.  So I started my own company.

Mr. Analogy
Tuesday, June 8, 2004

dude, I classify things. When I deal with people I classify as customers I treat them as such. When I deal with fellow IT people I tream them as such ... they are cohorts, not customers. I expect them to be up to par. But what you will find is that they are not. You too may not be up to par in some instances. This is why honestly is paramount. One should know where they stand. Unfortunately what I find is that everyone is PC .. all of us are equal, none know more or less than the other unless it's when THERE ARE NO SPECS (which there never are) and then you say "Oh joe KNOWS that cus he is the only one who can work on it because there are no specs and you'd tear your hair out if you had to work on it".  I'm beginning to get this idea ... the smartest people become doctors, lawyers ... then maybe dentists engineers .. then we are talking computer science and the best of these people work for companies that actually produce software for sale, then the others go to work at companies in the IT departments. I always wondered why everything was "outsourced" ... now I know why .. the level of ability to create software is not there in the corporate world but they might know enough to describe what they need and read directions ... and hire consultants to do the work.

Tuesday, June 8, 2004

------"and clients might actually have to make a decision as to what they want, and stick to it. "----


The client shouldn't have to give a monkey's toss about the spec.

The client is conerned with the REQUIREMENTS. What spec you use to fulfill those requirements is not somethng the client should be too concerned with.

Stephen Jones
Tuesday, June 8, 2004

I agree with the "Software development is an iterative process" approach.

Every software product is basically unique.  Unique in its combination of language, customer, specification, list of functionality, developer expertise, management expertise, testing expertise. 

It's not like building bridges, where there are only a few known ways of doing it, the stresses and strains can be carefully calculated ahead of time, and the ultimate purpose is simple.

Wishing (or demanding) that Software Engineering be a more disciplined process misses this key fact.  It is always going to be a process of taking a customer desire, finding out what is implementable, implementing some of it, then educating the customer as to what is possible and desirable, so he can change his expression of what he wants.

What is needed are ways of reconciling this fact with the demands of contracting getting things done.  Those demands have things like predictability, a (more or less) fixed schedule, a (more or less) fixed set of functionality, a price to be paid for same.  So far, our development approaches haven't completely solved this disconnect between contracting and software development.

Demanding that the disconnect does not, or should not, exist does not remove the disconnect.  Unfortunately.

Tuesday, June 8, 2004

>Where do you keep the spec?

You can't beat paper.

Wednesday, June 9, 2004


The client shouldn't have to give a monkey's toss about the spec.

The client is conerned with the REQUIREMENTS. What spec you use to fulfill those requirements is not somethng the client should be too concerned with."

Sorry, but no. I'm talking about a functional specification. The client most certainly should be concerned with that spec, because that's what says what they're actually going to get; requirements only say what they *want*, and the two will seldom, if ever, match up.

I agree that a client should not have to care about the *technical* spec, or the details of how the solution is implemented - although many of them do want to be closely involved here too - but you can't end client involvement after they give you the requirements. These are always open to interpretation, and if you happen to interpret them in a way the client doesn't agree with, you end up re-doing your work because they won't accept the finished product.

This is precisely why it's important that the PM specifies the work to be done properly. Otherwise the developer has to fill in the blanks and, while most of us are perfectly capable of that, the way in which we choose to fill them might not be what the client actually wants (and without a functional spec agreed by the client, neither you nor, in most cases, they know what they want beyond basic needs).

Neil Hewitt
Wednesday, June 9, 2004

The client's invovlement doesn't end with the requiirements, and they will need iroing out and there should be multiple feedback to ensure that the design is fulfilling those.

But no client should ever sign a spec; because then he'll be told "this is what you agreed on" when he won't have been in a position to know if the spec fulfilled his needs or not. If he were he wiuldn't need to hire a developer to write the software in the first place.

Stephen Jones
Wednesday, June 9, 2004

*  Recent Topics

*  Fog Creek Home