Are these signs of a bad developer? [closed]

Question

I used to blame changing specifications from clients for code rot, not realising that business models do change and it's my job to develop in an adaptable way. I now see that as a sign of a bad developer (I've changed!).

But now I see other 'whinges' in myself. A few times recently I've found myself saying 'it's like trying to fit a square peg in a round hole', and also I find myself blaming client indecision for a project not progressing.

Are there signs I should look out for where I should change my attitude? Is the client always right, or am I sometimes justified in getting frustrated?

Answer 1

I wouldn't say you are bad developer. Being aware of the issues already moves you beyond this definition.

Requirements change. That is a given. A good developer need to take this into account. Many modern programming techniques help coping with that.

Staying true to original spec is not realistic. Also not realistic is changing the requirements all the time.

The client is definitely not always right. It is 'right' more often than we want him/her to be, though (as in, try to accommodate him if he isn't totally off). But when you see him driving the project in the wrong direction, try to advocate for the things you think are right.

There are no hard rules on these things, and even good and experienced developers haven't achieved the perfect 'Zen'. The only wrong approach is not trying to improve on these.

Answer 2

There are cases where it IS the client. But that's your problem, too

There are cases where it is the developer, and there are cases, where it is the customer. But, usually they're both your problem, so an attitude of blaming oneself tends to be more successful, because it errs on the side of problem solving instead of helpless finger pointing. Therefore, you'll often find it in more experienced developers.

An even better attitude is IMHO to look at it without blame: "it's the customers fault I have lousy code, because he always changes requirements" then becomes "this customer is figuring out what he wants, so feedback, rapid prototyping and flexibility is more important than completeness, robustness and speed".

Kind of a Zen-mind: don't judge it, just see it like it is.

Answer 3

First, a client does not know what they want until they see it. That's part of the appeal of the Agile paradigm's small iterations with heavy client involvement. Second, don't expect a product to be "complete" when you are code complete.

Microsoft employs a product called 'Watson' (the send feedback message you get when windows blows up) in order to trace problems directly back to a client. Traceability is a good way to track issues back to the users that experience them. You can get traceability by asking. Or, if you have the resources, integrate the functionality into the product(s). The key is tracking the issues/improvements so they can be addressed.

Finally, sure client's can be fickle. In such cases, I try to focus on the iceberg secret.

Answer 4

Changing requirements are a tough fact of life; but code rot is not caused by that.

Code rot happens when there's some parts of your code that you don't exercise frequently; so when you do some changes that "shouldn't affect anything else", you might introduce bugs. In other words, code that doesn't see daylight slowly decompose and you can't say when it stopped working.

Yes, it's your fault and not your user's.

The real solution? test all your code frequently. Of course, the best way is to have automated tests with good coverage.

Answer 5

Client indecision can be a big problem and if you're not the one who's in charge of managing the client relationship than it may be very difficult to deal with. You could talk to the person who deals with the client and explain calmly that progress cannot happen until the client makes a decision. If you are in charge of the client relationship, you have to tell the client that they need to make a decision before the project can continue. It may not be that your attitude needs an overhaul, just a minute of meditation to calm down. ;)

Answer 6

Javier makes a good point that changing requirements are a tough fact of life. I too get frustrated by these situations as too often I find myself working on a product where the developer has to make decisions. My opinion used to be "Why can't management figure this out with the client?", or "Why did we begin this project if the client doesn't know what they wanted?", "It's so much headache when they change so late in the development".

Simple fact: this will always happen, not just in programming / software development but in every walk of life. The world would simply be a very boring and very different place if people never changed their mind, never adapted, never addressed change. People have a tendency to look at what they're given, and improve it. Do you not do the same thing with your code? If I have a block of code which I'm not happy with (it's inefficient, messy), I will improve it. (Does the operating system complain at me? ...sometimes, if I'm using a certain unnamed OS, but generally not)

As programmers we need to grab opportunities to improve things, and not get depressed or annoyed by them. Take the opportunity to talk to people, improve your style, improve your work ethics, approach things with an open mind, push yourself to be better than you were yesterday. Move forward in your career and don't settle too easily.

I understand that not everybody will agree with this answer but I think it's important that the answers to this question cover a wider perspective.

Answer 7

When you're interacting with a client, you're not programming; you're learning and teaching.

Keep the clients informed and educate them about the process. Change is going to happen. Let them know you will try to implement them, but it will cost more. Let them decide.

Don't get into technical detail even when the question they ask is technical in nature. You're tempted because you'll feel a little defensive and will want to take on a challenge/get your geek-on. Don't do it; they don't care about the details and will stop listening after 45 seconds.

If you didn't tell them ahead of time don't expect them to know about industry standards and best practices or any other excuse for doing what you do. I hate it when I don't see a fee until the very end only to have the salesperson tell me it's standard in the industry. I should not be expected to know that. My response is, "Is making me feel like a dumb-ass a standard too?"

When you're with a client, pay more attention to them than anyone or anything else in the room. Domesticated dogs are geniuses at this; especially if you have food.

Answer 8

It's bad requirement management or bad analyzing. Your business analyst (if you have one) or whoever gets the requirements needs to sit with the client and try to get all the requirements, even the ones the client may not think of. Clients usually don't know everything that they want, a great business analyst will help them figure it all out.

Answer 9

This why you should always get a Business Requirement Document setup and signed off on before any application goes beyond the prototyping/research phase.

Now, the idea that this document is actually final is faulty, but this should help you get a better idea of what the customer actually wants. And as long as you write your code with maintainability in mind, you can keep your issues to a minimum.

And if you ever need an excuse to fall back on, you can blame any delays on the BRD, that the client signed off on, not including such and such feature, etc.

(Of course, this is just an excuse in case you need it. You should always plan on them changing something)

Answer 10

In Emerson's quote, "A foolish consistency is the hobgoblin of little minds..." the most often overlooked word is foolish. Consistency is non-negotiable in certain settings, but it all to often substitutes for critical thinking and analysis.

On the one hand, many development models are designed specifically to help in the environment you're describing; so if you find yourself having to violate your model, then either you're not implementing it right in the first place, or you've got the wrong model.

But on the other hand, if you have a well-reasoned and supportable justification for violating your rules, and you can show that your rogue method produces cleaner more maintainable code, then you shouldn't be afraid to take the sensible route.