1995 again...

What is the hardest part of software development? 

The process of developing software is actually a pretty linear path, and the only branches depend on success or fails - successes mean you move on in the process, and fails can either mean you try, try again, or simply quit the project.

Is the hardest part coming up with a problem to solve?  No.  Everyone can do this, as long as you notice the needs of the people around you, or even better, yourself.  In the professional world, it's even easier - you will get a requirements document, and hooray!  You don't even have to think about the problem.

Is the hardest part actually coding the problem?  Possible, and it depends if you're working outside your "comfort" language.  Is it solving problems along the way?  No, not really.  In a team, if you put your mind together, you can solve anything.  On your singular, Google can solve anything.  If you hammer enough nails, eventually at least one will stick.  If you fail at a problem, you can keep repeating solutions until you get it right.

Is the hardest part releasing and getting publicity for the application?  You're thinking too far.  The hardest part of software development is actually a subset of this node.  It's that dirty little D word - documentation.

Writing documentation is the hardest part of software development.  Good documentation makes a program so much better.  Bad documentation makes software a pain to use. 

When it comes to writing Documentation, I often put doing it off, which is bad.  Bad documentation is better than no documentation at all, but it's always better to have good documentation.  What is good documentation?

Good documentation should break things down simple enough for the lowest common denominator of users to understand it, but not simple enough to insult them.

Good documentation should be easy to read, and explain all factors of installation, using the product, and possible troubleshooting.  If there's a common bug you notice, add it to the Readme.

Bad documentation is hard to read, or makes the user not want to read it.  It also can be too simple it's insulting to the user.  No matter how jaded your view of computer users, the wide variety of people understand how to use the right mouse button, and do simple tasks such as shutting down a computer, or maximizing a window.

Bad documentation also hides information, or makes things impossible to find.  Here's an example of what I mean.

Yesterday, I put on my system administrator hat, and tried to install a local copy of Kuali onto my local machine for testing reasons.  Looking at the documentation (and the fact I couldn't find any little bit of troubleshooting information on Google), I knew that I was in trouble when I couldn't even build the schema correctly.  I wasn't even installing the software, but I was following the software step by step and had trouble importing a database schema using their own software.

A coworker and I put our heads together, and we decided it was because Apache Torque wasn't installed. This was one of the reasons we were getting errors, as it said that org.apache.tasks.TorqueTask (or something like that) wasn't found.  Nowhere in the documentation does it mention Apache Torque is required for use.  I've ran many applications using Tomcat (which is the default web server/servlet that Kuali uses), and I never actually had to use Apache Torque.

After installing Torque, it still doesn't work, because in our installation of Torque, there isn't a org.apache.tasks class path, even after checking out the jar file.  Yeesh.  Nowhere in the Kuali documentation does it mention what to do in this case.

This made me not want to use Kuali, even if Linux.com hailed it as an opponent for "the last bastion of propietary software".   No one is going to use your software if it has crappy documentation! 

I do think the best way to get documentation is to show a third party (possibly a journalist or someone with a degree in English), how to use the software, and have them translate your ramblings to wonderful, good documentation.  By removing yourself from the documenting process, you don't run the risk of removing details because "the user will figure it out by yourself" or "because I know that's how it works".  You also don't run the risk of making things overly complicated.

Now, if you excuse me, I'm going to eat my own words and work on the WELSH documentation.