PDA

View Full Version : What do you think is the most difficult part of programming?



verb3k
February 7th, 2008, 04:44 PM
Hi,
I voted for [The initial engineering of the program's architecture]
What do you think?

misconfiguration
February 7th, 2008, 04:50 PM
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.

skeeterbug
February 7th, 2008, 05:34 PM
I voted for The initial engineering of the program's architecture. Part of this is figuring out the customers problem.

DrMega
February 7th, 2008, 05:36 PM
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.

lnostdal
February 7th, 2008, 06:13 PM
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. :)

popch
February 7th, 2008, 06:32 PM
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).

a9bejo
February 7th, 2008, 07:43 PM
the hardest part is getting the client to tell you want it is they want.


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.

cprofitt
February 7th, 2008, 08:16 PM
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.

aks44
February 7th, 2008, 09:07 PM
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:


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? :p



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...



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.



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? ;))

RIchard James13
February 7th, 2008, 11:54 PM
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.

johnnyb1726
February 8th, 2008, 03:04 AM
I voted for "Initial engineering / architecture". If you have trouble with any of the other points then you probably screwed up your design...

I totally agree that is why I voted for "initial engineering / achitecture".

tosk
February 8th, 2008, 09:58 AM
By and far the hardest for me is debugging. I know how I want something to work and I code it how I want it to work. You'd think that because I coded it the way I wanted it to work that it would work. Perhaps in a perfect world. :P Especially when I've written a large chunk of code without testing it as I go. Then it becomes VERY difficult to go back and find the errors.

Of course, I'm talking about errors that don't return an error message. Mostly these are just me coding improperly. :P

pedro_orange
February 8th, 2008, 01:15 PM
Other.

The hardest part of being a software engineer is a good requirements capture that fulfils everything the customer needs

verb3k
June 6th, 2008, 05:39 AM
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. :)

It isn't easy, especially that there are many, many approaches to solve a problem, each has it's advantages and drawbacks.

Anyway, let's see if this bump reply can revive the discussion :)

lisati
June 6th, 2008, 05:45 AM
Find out what's both wanted and needed is a fine art, which, as has been mentioned, tests your people skills. Getting it wrong sets you up for disaster. Getting it right, however, can simplify refining the overall design.....

I wish to nominate "read the instructions" and "read what's on the screen" as candidates for the list of difficult tasks once the software has been completed.

JupiterV2
June 6th, 2008, 02:49 PM
Initial engineering. I include finding out what it is the client wants as a part of engineering a product. It's not just about how the program will flow from a logistical point of view but how it will flow for the customer. A lot of frustration comes from a design that may make logical sense but doesn't make sense for the customer.

It's our job to find out what the customer WANTS while designing something the customer actually NEEDS.

I consider this a part of the design process.

You can design a masterful piece of digital art but what's the point if it just ends up frustrating the customer because they can't understand it?

Design with the customer in mind. (Oh! Did that rhyme a little?)

verb3k
June 6th, 2008, 04:13 PM
Initial engineering. I include finding out what it is the client wants as a part of engineering a product. It's not just about how the program will flow from a logistical point of view but how it will flow for the customer. A lot of frustration comes from a design that may make logical sense but doesn't make sense for the customer.

It's our job to find out what the customer WANTS while designing something the customer actually NEEDS.

I consider this a part of the design process.

You can design a masterful piece of digital art but what's the point if it just ends up frustrating the customer because they can't understand it?

Design with the customer in mind. (Oh! Did that rhyme a little?)

A lot of people confuse the word "programming" with the word "development". What I actually asked in the poll was about the actual activity of programming itself, not other aspects of software development like documentation, marketing and knowing what the customer needs.

So, suppose you have already ironed out all the features and ideas your customers want. How are you going to realize them in the form of code? what's the most difficult part in this process?

nvteighen
June 6th, 2008, 05:15 PM
With no doubt: initial engineering of architecture. In other words, creating the most simple, but also working design to accomplish the task. If your design is too bloated, it finally collapses under its own weight; if poor, it is useless.

In my experience, the only way to improve this is by coding a lot.

JupiterV2
June 6th, 2008, 06:36 PM
So, suppose you have already ironed out all the features and ideas your customers want. How are you going to realize them in the form of code? what's the most difficult part in this process?

In that case it would still be the same, initial development.

Ironically, hunting down bugs is typically a result (in my case anyway) of bad planning. Not properly analyzing the problems tends to lead to poor implementation, which ultimately, leads to difficult to solve bugs. Often, I'll scrap an idea and "go back to the drawing board" if I can't seem to resolve the issue. This will generally lead to a complete redesign of the function or application. Magically, the bugs suddenly disappear (and not just because I've deleted the nasty code ;) ) because they were a result of my poor/incomplete planning. So, understanding and outlining the issues is #1 on my list.

KingTermite
June 6th, 2008, 07:46 PM
Hi,
I voted for [The initial engineering of the program's architecture]
What do you think?

For me, most code is (not my choice) based off of some previous code. The hardest part to me is reading and understanding somebody else's code/architecture (especially when they don't comment things worth a crap).

verb3k
June 7th, 2008, 12:25 AM
In that case it would still be the same, initial development.

Ironically, hunting down bugs is typically a result (in my case anyway) of bad planning. Not properly analyzing the problems tends to lead to poor implementation, which ultimately, leads to difficult to solve bugs. Often, I'll scrap an idea and "go back to the drawing board" if I can't seem to resolve the issue. This will generally lead to a complete redesign of the function or application. Magically, the bugs suddenly disappear (and not just because I've deleted the nasty code ;) ) because they were a result of my poor/incomplete planning. So, understanding and outlining the issues is #1 on my list.

Yes, I agree. It's really a huge help when you draw the algorithm tree on paper and then try to make code of it. You will later thank God that you did it :)

verb3k
January 1st, 2009, 11:18 PM
Let's get some more people to vote on this.
Reviving thread.

jflaker
January 1st, 2009, 11:20 PM
Getting concrete requirements from the client
Naming of variables and subroutines

lisati
May 26th, 2009, 04:10 AM
Let's get some more people to vote on this.
Reviving thread.

**bump**

fredscripts
May 26th, 2009, 10:49 AM
Designing the proper data structure for the problem to be solved. Designing a recursive (because iterative would be too difficult) algorithm for a problem (such as recognizing some patterns in a graph or an image), then analyzing its correctness and runtime solving the recurrence is far more complicated that all software engineering topics and user interaction.

verb3k
August 3rd, 2009, 10:15 PM
Designing the proper data structure for the problem to be solved. Designing a recursive (because iterative would be too difficult) algorithm for a problem (such as recognizing some patterns in a graph or an image), then analyzing its correctness and runtime solving the recurrence is far more complicated that all software engineering topics and user interaction.

This falls under the optimization category; optimization of algorithms used in the program, and if you mean the "initial design of the algorithm", it falls under the initial engineering of the program/architecture.

wrtpeeps
August 3rd, 2009, 10:36 PM
Getting the first build out the door is the hardest bit. Once you have a build that all you need to do is edit and append it gets easier in my opinion.

jpkotta
August 4th, 2009, 02:42 AM
Initial Planning.

A lot of the code I write is for controlling hardware. I often find myself fixing bugs caused by incorrect assumptions at design time, or completely rewriting something based on incorrect assumptions. It's hard to anticipate how things will actually work before you start working with them, especially bringing smaller pieces (that you've tested separately) together to form the overall project.

Greyed
August 4th, 2009, 05:36 AM
Other... With the advent of Open Source it is finding a project which isn't already in a finished form one apt-get away...

pepperphd
August 4th, 2009, 05:44 AM
Thinking of something to do that hasn't been done by a team of trained professionals.

karlmp
August 4th, 2009, 03:17 PM
what is degugging?

benj1
August 4th, 2009, 04:10 PM
what is degugging?

its the act of removing all spelling mistakes from a poll :D

jero3n
August 5th, 2009, 06:25 PM
The most difficult part, is finding a name for a brand new program. I can spend days in this.

Thankfully this gives me plenty of time to think all other details in subconsciousness. :)

JordyD
August 5th, 2009, 10:35 PM
what is degugging?

:D I didn't even notice that.