The document provides an overview of the basics of software development including understanding users' needs, developing features to meet those needs, using existing packages when possible, and managing schedules and deadlines. It emphasizes investigating users' actual workflows rather than just their requested features, keeping the user interface simple, and balancing new features with elegance and simplicity. Maintaining existing code is noted as often more costly than starting fresh or using open source options. Meeting unrealistic deadlines can compromise quality.

1. Very rough overview
Users need some type of software/you decide to build a piece of software
After they contact you, you investigate what problems they're having and how you can help the
users to solve them
If you develop software for potential users, then you should find them and ask them what
features they need
After getting some ideas of what the users need, you start developing some solution (or provide
an existing package), while periodically checking with the users to ensure that you're on the
right path. Also, you should constantly check with deadlines and if there's not enough time to
complete everything, then you should omit some non-important features to make completing
the really critical ones on time possible
At some point the software will become stable, with no major and few minor bugs, and almost no
features left to implement. Most projects end here.
If you're developing a product, then most likely you'll go back to point 2 to get some new ideas
and missing pieces to develop and continue from there.

2. Basics of Software Development
Users
Development process
Tools
Features
Schedules
Existing packages

3. Users
You are designing for users, so they are the most important factor in software development
Users will tell you what they want, but don't trust their words – investigate how they work, what
are the bottlenecks and what you can automate or improve in their workflow – what they
currently do by hand that can be done by a computer
It's your fault if your software doesn't solve the users problems, not theirs
Users are stupid*, so make your user interface as simple and intuitive as possible
Stupidity doesn't mean mental problems, it means having a lot of (better) things to do than
learning to use your programs, so software that doesn't force you to think is better
Keep the users happy while developing – let them know you care
Let them know you listen to their complaints
Don't talk about technical details, and don't let them. Let them focus on their problems.
If you keep them happy, they will go out of their way to help you
* Stupid is a technical term

4. Tools
Technologies
After understanding what the users need, you'll basically determine what technologies you
will need to use – web technologies are better for multi-user online apps, or
performance-critical apps where computations have to be performed on the server. For
office applications (or specialized tools for daily use, e.g. bookkeeping), desktop apps
are better. But these are general guidelines; you'd better decide what to use based on
the problem description.
No matter what technologies you choose, the user interface should still be familiar to the
user. Sometimes innovation isn't a good thing. That's especially true in user interface.
That being said, we've seen very innovative user interfaces that are easy to use. Being
conservative doesn't mean you mechanically repeat what has been done before – it
means you provide an user interface that is intuitive and usable like it has been
before.
Programming languages
The choice of programming languages has always been debated; choose what absolutely
works for you and what you know well; you can read Joel Spolsky's Blog Entry about this
(though the article is from 2006 and he disses Lisp and Ruby which are completely
working alternatives).
There really are programming languages which take productivity to unseen levels, but you
will really need advanced hackers to write stuff, and for most projects they are an overkill
(simple web-pages are the easiest, cheapest and fastest to do in PHP).

5. Features
Almost all software is judged by its features. Gmail is great because it has the “send email” (and
other) features, Firefox is great because it has the “browse the web” and countless other
features. Users will frequently decide which competing product to buy based on so-called
“feature charts”, which is a side-by-side comparison of numerous products and their features.
You've probably already seen one (example here).
You may find feature charts unusable, but many customers will still ask you questions like “Does
your product have X?” and you may find that having X is almost always easier than explaining
to customers that X is useless to them. Many easiest to implement features are the ones
with most demand. So don't disappoint the users, implement what they are asking for and
keep working on what they truly need.
With the above said, you should try to keep software as simple as possible, and sometimes it
means omitting some features. Some things may seem simple (for example, iPod), but under
the covers there can be a complex infrastructure. It's the designer's job to make the product
seem simple. Software with countless features are sometimes harder to use, harder to
maintain, and called bloatware (full with useless features). Elegance and simplicity are also
features, and very important ones; don't trade them into a horde of other, less important
features. I will also quote Joel Spolsky here.

6. Existing packages
All new code must be written, debugged, tested, shown to users, modified, tested again, and
maintained. So, whenever applicable, it's better to use code written, tested, and maintained
by better developers (e.g. use Wordpress instead of writing your own blogging software).
Maintaining costs are frequently the highest. The original author may have left, the code may be
undocumented, low quality, etc. Maintaining low quality and obscure code may be orders of
magnitudes higher than writing your own, or modifying an existing open-source code base.
Open source projects tend to be high quality, because they are usually reviewed by a number of
developers, so bugs tend to be fixed more quickly.
Also open-source projects tend to have shorter release cycles than their proprietary counterparts,
because the manufacturing costs associated with the latter. That way latest changes and
updates are incorporated more quickly.

7. Schedules
Work takes time; great work takes a lot of time.
Users/customers don't understand that adding new features/fixing bugs takes time
As a result, sometimes when you say “it will take two weeks”, customers ask: “couldn't it be done
in 10 days?” You may think that you'll squeeze the 14-day work in 10 days, but quality may
suffer. Actually, in real world, managers think that they can make employees work faster by
giving them unrealistic schedules. Experienced developers know how to sacrifice quality to
meet short deadlines, but the final product is lacking in testing.