Thread: What do you think is the most difficult part of programming?

Hi,
I voted for [The initial engineering of the program's architecture]
What do you think?

Theory - flow control.

Thinking about how to start at point A and end at Z is most def the hardest part.

Not to mention what algorithms will be used in order to accomplish the tasks-at-hand.

I voted for The initial engineering of the program's architecture. Part of this is figuring out the customers problem.

As a professional programmer developing in house apps, the hardest part is getting the client to tell you want it is they want. If you ask the same person twice you will get two different answers.

Other:

* People, especially people with no knowledge about the industry can be hard to communicate with. There are exceptions of course.

..the "computer stuff" is easy.

I voted for 'others'. The options given are things which can be done in an orderly and deterministic manner. Also, they can be learned by reading some literature or taking some tuition.

What I find really challenging is designing the user's paradigm (which forms the basis for the documentation and the UI).

Originally Posted by DrMega

the hardest part is getting the client to tell you want it is they want.

Originally Posted by verb3k

The initial engineering of the program's architecture

I agree that these are the two main factors, and I want to add that both of these problems can be simplified greatly by agile methods like rapid prototyping, testing and a lot of communication with the client.

The problem with communication is that, while everyone agrees that it is the bottleneck in software engineering, no one really wants to do it:

• Developers do not want to talk to the client. They often suck with people skills, and they do not like to babysit the client. They want to write software and they think they know already what the important tasks are.
  
• Management and sales do not want developers to talk with the client. They have spent much time in making the company and the product look professional and extraordinary and perfect, and they fear that programmers will be realistic and negative and honest with the client.
  
• The client representatives does not want to talk to the developers because it eats time and IT people make them feel stupid. They would have to make a lot of decisions about something they do not really understand or imagine at the moment.
  

The result of this are often regular iterative meetings with a lot of useless talking and no content. Oh, and an awful product in the end. Maybe that is an advantage of FOSS development: You cannot hide your ugly code and your ugly processes anyway, you are forced to talk with strangers all the time. And the only users that give feedback are the ones that actually care about the product.

You probably include this in the 'engineering' part, but I think it needs its own 'title' because for me there are two parts of engineering the project.

The toughest part is needs analysis. The interaction with the customer to really nail down the features they - need : want : care less about - is critical before I get to the technical part of planning a design.

I voted for "Initial engineering / architecture". If you have trouble with any of the other points then you probably screwed up your design...


Now since you mentioned agile development, here's my stance on it:

Originally Posted by a9bejo

Developers do not want to talk to the client. They often suck with people skills, and they do not like to babysit the client. They want to write software and they think they know already what the important tasks are.

Whenever I'm bored (as in: trying to postpone some grunt work I am reluctant to do) my reflex is to call the client that wants that feature, and discuss with him. Am I an alien?

Originally Posted by a9bejo

Management and sales do not want developers to talk with the client. They have spent much time in making the company and the product look professional and extraordinary and perfect, and they fear that programmers will be realistic and negative and honest with the client.

I indeed tend to be honest and realistic with the client (never negative though). But as a matter of fact I do half of the sales people work, so they'd better not get in my way...

Originally Posted by a9bejo

The client representatives does not want to talk to the developers because it eats time and IT people make them feel stupid. They would have to make a lot of decisions about something they do not really understand or imagine at the moment.

They actually thank us for being so attentive with them. Our competitors didn't get that yet, so they're gradually loosing ground.

Originally Posted by a9bejo

Maybe that is an advantage of FOSS development: You cannot hide your ugly code and your ugly processes anyway, you are forced to talk with strangers all the time. And the only users that give feedback are the ones that actually care about the product.

Even with closed source products, the so called "agile" development methodologies (especially IMHO the incremental development, fast release cycle, and close communication with the customers) yield more or less the same benefits as FLOSS processes. Unfortunately when it comes to code review this is not true anymore but hopefully this doesn't matter much on the product's quality from the customer POV (not from a purely technical POV, mind you).


(Many of our customers have several competing products. We made about 15 minor releases in the last 6 months, while our main competitor made... none, another one made only one update. Guess who the customers trust the most? )

I voted other:

I have problems with time-management and <evil>procrastination</evil>

I know I can solve technical problems if I just devote my time to it, but sometimes I just don't want to.