The document argues that documentation, though often seen as a waste of time and money, is actually an investment that saves both. Minimal but effective documentation, such as data diagrams, screen flows, and mockups, can significantly reduce development time by clarifying requirements and preventing incorrect assumptions. While creating documentation takes some effort, it ensures the final product meets expectations and avoids costly reworks, making it worthwhile except for the smallest of projects.

1. Documentation? We don't need not stinkin' Documentation!
I hear it all too frequently.
"Documentation takes too long"
"Documentation costs too much money"
"Our project is short, we don't have time for documentation"
"We're not big enough to deal with the overhead of documentation"
First, let's consider one very important thing about documentation: it is an INVESTMENT,
not a cost.
What does that mean? The time you spend on documentation, if spent well, will save
you more time and money than what you spend on creating the documentation.
This is true for all but the very, very small projects. And when I say small, I mean under
about 10 hours.
So in short, if you put together good documentation, you SAVE yourself time and money
AND the end product created is what you were expecting.
First, we need to define what it means to have "good documentation".
* Minimal - Use the smallest amount of pages having a maximal amount of information.
This can be a little tricky and may take some experimentation. What usually turns people
off from documentation is that they think it must be thorough and perfect. It doesn't! It
should be short, sweet and to the point which means you spend less time on it and the
team spends less time looking it over.
* Lots of pictures - As always, a picture paints a thousand words. On top of that, it can
convey that thousand words at a glance. This reduces the amount of time people spend
looking over and understanding what you wrote. And the picture doesn't need to be
pretty, it needs to be simple and to the point.
* Very few words - Words take time to read. We only add text when the picture cannot
quickly and clearly explain the requirements. Then we keep the text very short and
usually add it as notes to the visuals created.
* Doesn't need to be fancy - You can create white board drawings, pencil and paper
sketches or put it into the computer with Gliffy / Visio. We usually start by sketching out
on a white board while discussing the requirements with the client. This speeds up the
discussion (less time spent defining the project) and then just take pictures with our

2. phone. Wow, documentation without having to spend additional time documenting! We
formalize in the computer only when the project is large or we feel it will start saving time
so we don't have to redraw things because of little tweaks.
* Must make sense to a person other than the one who wrote the documentation -
Before unleashing the build team, run the documentation by everyone on the team
including the developer, end user and client. This will help you find flaws in the design
before sinking time and money into building something that won't work. It also helps you
fill in the information you may have forgotten.
* Follow industry standards that the team understands - Use notation, vocabulary,
drawing and symbols that are common place. This will help reduce the time you have to
spend explaining to people what you mean in the documentation. It will also help
everyone speak the same language when communicating about the project which
eliminates confusion.
Good documentation should be something you can put together quickly and easily. It
should be something your team easily understands. And it needs to answer at least 90%
of the questions you typically have during the build of the project.
When building software, the minimum documentation you needs is:
* Data diagram - This is an absolute must for the developer and also helps to ensure a
great firm foundation for your software project. Whether in memory or in a database,
your data is the foundation of your application. Without a firm foundation the software
will fall down like a building built on a sink hole.
* Screen flows - This diagram gives you a full inventory of all screens in your application
and how each one flows into the next. We also like to include brief notes about the
business logic as you go through the system. This reduces how many pages of
documentation you have and increases how much information you can pack into each
page.
* Mock-Ups - Mock-ups show what is on each screen, how it lays out and has brief notes
on what kind of validation and user interaction may occur. Developers often work from
one screen to the next and having the notes right there on the drawing of the screen helps
ensure they don't miss important functionality as they build.
Additional optional documentation:
* Sample data - This is great in spreadsheet format. Sample data quickly shows a
developer what to expect. From user input to data output, having sample data reduces
build time and gives real concrete data for the developer to test with which reduces bugs
and time spent debugging the system.
* Test cases - Test cases lay out what a user with do in the system, what they will enter

3. in and how the system should respond. It includes both normal situations as well as
when the user interacts with the system incorrectly. We have to be careful with this one.
All too often people preparing documentation go a little overboard here and try to add a
test case for everything. You should only supply test cases when there are special
cases a developer and test may not consider or when the functionality of that part of
generaldatabase application development is complex.
* Process flow diagram - Usually your screen flows are enough but sometimes there is
an overall process as duties are handed from one person to the next that are not visually
demonstrated in the screen flows. An addition of a process flow diagram helps
developers and testers see how the system is actually going to be used. We typically
use an industry standard process flow diagram or swim lines.
What documentation buys you:
* Saves you time having to communicate with the team about what you want so you
can hand the work off and get back to your job and not have to micro-manage the project.
* Gives you a visual of what the final application will do. This aids in usability testing
and finding potential problems with how the system flows before you sink a lot of time into
the build of an application that has design flaws. It also illicits better feedback from users
so design changes can be made before development moves in the wrong direction.
* Helps the development team dive in and start coding. The developers spend very
little time scratching their heads and wondering what you meant. The development
moves quickly and smoothly. Without documentation the developers have to spend a lot
of time thinking about what to do or have to frequently stop and ask for clarity which slows
them and the whole project down.
* Increases the success rate by ensuring the application built is what you expected.
* You are not truck sensitive - if someone leaves, you have the knowledge in the
documentation so new team members can get up to speed on the project quickly and
easily which saves you time and money in the long run.
Most people just hate putting together documentation. They find it boring and tedious.
They would instead rather just jump in and start working furiously. It feels like they are
getting things done. In reality they are spending much longer than they should and the
products they deliver are not as accurate to the vision of the client as they could be. This
leads to longer development times and higher costs, whether it’s Java Development or
Web Application Development.
But most people don't see this added cost of time and money. Why not? Because they
don't try it both ways to see what works.
Also, most people think documentation means writing a book. They prefer writing no

4. documentation (one extreme) as opposed to writing 100+ pages of detailed specifications
(the opposite extreme).
What we promote is a healthy balance between these two extremes: writing the least
amount of documentation to convey the greatest amount of information. On small 1 - 2
week projects, the documentation may only take an hour or two to assemble. It isn't hard
to save an hour or two just in not having to shoot emails back and forth and avoid
meetings to clarify what we want. Typically the investment of time in the documentation
is between 2% and 10% of the time of the build. I commonly see this save 25% to 50%
on the build itself. The savings can be very big, even on small projects.
So before you start your next project, ask yourself, do you want to turn your back on
savings? Do you want to take more time getting it done? Do you want the final product
to be less than you were hoping it could be? If so, skip the documentation.
But if you want it done faster, better and at a lower cost, get that simple, minimalist
documentation together.
And if you would like help getting the biggest bang for your buck for Android development
or any development, let us know. We would love to help!