Goal Oriented Development
June 11, 2008
Goal Oriented Development
By Adam G. Carstensen
Anyone who has spent a serious amount of
time doing software development knows that there are the same old pitfalls
which almost always keep creeping up.
The project seems to be running along smoothly, but as you reach the end
of your time frame, the development process seems to slow and it appears that
there will not be enough time for everything that was planned. Corners are cut and the final product just
doesn’t measure up to the intent or worst case, the project isn’t completed on
time and you need to explain yourself, while begging for more time or money.
There are a number of factors which lead to
this occurrence, and chances are that if they happen to you once, they’ll
probably happen again because it’s simply too embarrassing to attribute to poor
planning and oftentimes, excuses are found or fabricated for any possible
shortcoming.
Luckily for you and me, this fate doesn’t
have to fall upon us in project after project, and it’s actually very simple.
The most important thing to note is that
some developers are better or worse at certain tasks, some are faster or
slower, and some are burdened with additional work. These things can be accounted for on a case by case basis, but it
doesn’t change the need for good planning.
There are several methods for managing long
running software development projects, but I’m only going to outline what I
find to be the best for my own development style, and I’m sure these easy steps
will help many other managers / developers.
Milestones
and Speed Bumps (Goal Oriented Approach)
Milestones are just imaginary markers along
the road of software development. The
principle is very simple and everyone creates these in their mind when they are
planning anything from getting ready for work to landing a 747.
Speed bumps are problems which can occur during
any portion of development. If you are
writing a section which will utilize a new technology that you’re not familiar
with, or if Holidays is coming, these are speed bumps which MUST be accounted
for, or else you will fall short of your development goals.
Common
Speed Bumps:
Gaining / Loosing Employees
Office Expansion
Upgrade of Software/Hardware Baselines
Pregnancy / Childbirth
Conferences
Holidays
Unknown Technology (New or Old)
Security & Stability Testing
(Penetration Testing / Compatibility Testing)
Client Forest/Domain Configuration Settings
Human beings are goal oriented creatures –
busy work rarely appeals to anyone, but working towards an end allows us to
break almost immeasurable tasks into small pieces that can easily be
consumed. Take advantage of this, and
instead of having everything pile up at the end of a project, ensure that
almost all of your goals are accomplished LONG before the end of your time
table.
An example of one of my development
timetables is added below to show how I separate my projects into
milestones. The project this timetable
was used for was the development of a Help Desk System (Trouble Ticket Issuance
and Configuration Control).
Milestone
1 – Business Analysis
Milestone
2 – Requirements Gathering
2.1
– Scope
2.2
– Specifics
Milestone
3 – Software Planning
3.1
– Platform
3.2
– DB
3.3
– Sketches
3.4
– Workflow
3.5
– Prototype
3.6
– Approval
Milestone
4 – Infrastructure
4.1
– Web Server
4.2
– Admin Console Delivery System
Milestone
5 – Database Design and Development
5.1
– Table Schema
5.2
– General Stored Procedures
5.3
– Code Table Values
Milestone
6 – Web Interface
6.1
– Login Page
6.2
– Home Page
6.2.1
– My Tickets
6.2.2
– New Tickets
6.2.3
– Admin Page
6.2.3.1 – Update Tickets
6.2.3.1.1
– Assign Engineer
6.2.3.1.2
– Assign Priority
6.2.3.1.3
– Assign Status
6.2.3.2 – Automated Status Updates via Email.
6.2.3.3 – Node Coloring.
6.2.3.4 – Categories and Subcategories.
6.3
– All Tickets
6.3.1 – Color Coding
6.3.2 – Categories
Milestone
7 – Refactor and Refine code
Milestone
8 – Replace Placeholder Graphics
Milestone
9 – Internal Testing and Bug Finding
Milestone
10 – Bug Fixing
10.1
– 6.1
10.2
– 6.2
10.3
– 6.3
10.4
– 7.1
10.5
– 7.2
10.6
– 7.3
Milestone
11 – UI Polish
Milestone
12 – Documentation
Throughout the course of development, I
knew that I would run into 2 HUGE speed bumps – Christmas break and AJAX.
I decided to use AJAX because the customer requested
its use and because I wanted to deliver something that would be visually
impressive and extendable. I enjoy a
“hands-on” learning environment, so I was up for a bit of a challenge.
I also know that in the week before
Christmas I get VERY LAZY (It’s the cookies) and no one from my team is
reliable or even present most of the time.
I need better henchmen.
Seriously though, Christmas time isn’t just
a few days off; productivity will grind to a halt almost everywhere a week
before and a week after Christmas. Even
if you are incredibly motivated – most others won’t be. Accept it, and plan for it.
I was given a 2 month development window
for the new Help Desk software, and I decided that in my 8 weeks, 2 of them
were essentially worthless because of Christmas, and that I had to break my 12
Milestones up into 6 weeks time. This
gives me the added benefit of any work done during the break being “gravy” on
top of my time table.
Milestones 1-3 involve Requirement
Gathering and Software Planning – two things that I had under my heel because I
had already contracted for the customer for a number of years and understood
much of what they wanted. Still – I
dedicated a full week to tracking down ALL of the key players, getting their
input, pitching ideas, revising ideas, pitching ideas, revising ideas, ignoring
input, and generally bothering everyone involved until I had a well rounded
view of what my customer (more like 30 customers) wanted.
Our fourth milestone is a tricky one –
and is something that managers will often overlook only to be done in late in
the game: Infrastructure.
If you are being contracted to provide the
entire solution, it may include Servers, but most times the customer will
already have an IT infrastructure in place that you simply need to cut a piece
of.
Regardless of who is providing the hardware
- specific configurations and settings will need to be made by the customer to
allow its entry into the Domain/Forest/Workgroup.
Find out what your server name(s) will be,
how much space you’re allotted, how much bandwidth, blocked ports, network
availability, GPOs that might interfere with your software, policies regarding
third party software, and any other information related to your specific
project. If you run into trouble, the wheels
are already turning very early in the game, and hopefully by the time you get
to deployment, these issues will be resolved.
The amount of time needed for Milestone 5
(Database Design and Development) grows and shrinks directly proportionate to
the complexity of your database needs. “That’s
true of basically everything though!”
Yes - however is doubly true for database development. The time needed to repair one small error,
omitted field, silly use of in-between tables, or any other database design errors
will grow exponentially with the size and complexity of the database schema and
most importantly the stored procedures which are used.
Take extra time when you’re creating your
database to run through EVERY planned function of the application to ensure
that you didn’t miss anything. You will
hate it at the time, but it pays huge dividends in the end when you’re not
hacking up your original DB schema because of poor planning.
I typically plow through the DB development
quickly because I’ve had a lot of experience working with relational databases
(and this project was really quite simple), but dedicate as much time as you
need (within reason) to getting it perfect and then move on.
Fill in your code tables, and make sure
that you include your default values in a clear and concise manner – I always
include „Unknown” and „Other” (if applicable) first to ensure they get primary
keys 1 and 2. If you create and fill
your code tables before you start working on the software, you will be able to immediately
create enumerators and ensure that you don’t run into any data mismatches. Each developer is different but I find this
helps to prevent errors that I might otherwise get if I just slop everything
together.
By the time I got to work on the webpage I
had already gone through the layout and workflow of the site numerous times during
the requirements gathering, software planning, and database development
portions, and I’ve decided to change things a little from my initial plan. I contacted the customer, suggested my
changes, they agreed and I got to work on developing the website.
Don’t get frustrated if you come up with a
great idea and the customer shoots it down.
Chances are, they aren’t as technically minded as you and just don’t
want the plan to change after all of the key players have already agreed. If the development absolutely can’t continue
without change, call another meeting with everyone involved and explain the
problems, how they came to pass, and how they were overlooked originally. If you can provide an adequate explanation,
and take ownership of the problem it will usually reflect well upon you and the
company you represent, instead of screaming incompetence.
At this point I had approximately 4 weeks
left on my development time table (not counting the 2 weeks of worthless
Christmas time), and I’ve only just created the Solution which I will use for
the project.
Now, I knew what pages I would need, the
basic components, the functionality, and I knew that I would spend a decent
amount of time on fluff and filler to make the site feel complete, but I still
had one huge speed bump – I’m an IDIOT!
I don’t know anything about AJAX – I thought it was a cleaning product,
but apparently it’s a content delivery system.
Who knew? So to the internet I
went, I was going to give myself 1 week to learn everything I needed in order
to create my site, so I had to really put my ear to the grinding stone. Fast forward a week, I’m still an idiot, but
I know a little bit more about how to develop a site using AJAX, but not
enough. I don’t like my situation. I couldn’t learn enough to be comfortable
delivering a truly professional site.
Now I’m in an awkward position – my customer wants AJAX, I said I could
probably deliver (never promise anything, you’re not 100% sure about), and now
that it’s coming down to the wire – I’m relatively sure that I can’t.
What to do, what to do. Lie?
Dog ate my laptop? No, that’s not
any good – ask for more time / money to study?
The customer isn’t paying for my education, they pay for a product – a
product they can get elsewhere if they need.
So what can I do? Well I have
two options – I can struggle with the AJAX and try to pull something out of the
magical land in my pants, or I can study some more until I feel well grounded.
Each one of my options has plusses and
minuses. I simply have to weigh my
options to decide which is the best for my situation.
Carry
On:
PRO -
Immediately start developing
CON -
Development will be slowed
PRO - Will
get “hands on learning”
CON -
Code will surely be a mess
CON -
Performance will surely be affected
CON -
Documentation will be lacking - most things aren’t fully understood.
CON - Development
will be interrupted by Christmas break.
Study
More:
CON –
Development will be delayed.
PRO –
Development might be quicker.
CON –
Development might not improve much.
CON – I
might still have many problems after studying more.
PRO – I
should have a decent theoretical knowledge of the software.
PRO –
Documentation will be fuller and more reliable.
PRO –
Performance may increase.
CON –
Performance may also not improve much.
PRO – Development
will not be interrupted by Christmas break.
Well, both of my options look relatively bad, but I do know that I gave myself two weeks of extra time because of Christmas – which is fast approaching now. I won’t get much development done while I’m on vacation, and it’ll take me a while to get back into my code anyways, so I decided to get back to the books.
I took a trip to my local library and picked
up a few books on beginners AJAX, and settled in for my two weeks of relaxation
and light reading.
It so happened that I had a nice “Bones
Moment” with a few days of my vacation (that I mostly spent eating and playing
computer games – I’m so bad) remaining, and things started to just make sense.
Had I not agreed to attempt development
with technology I didn’t know, I would already be mostly done with the site,
but sometimes we need to push ourselves to grow - sometimes we need to fail to
remember that we’re not Superman, and sometimes we have to work extra hours to
make up for playing Super Smash Bros for two weeks straight. It happens.
I got back to work with a real time table
of 4 weeks remaining, and I’m only just starting my development. I have only 6 full milestones remaining, but
one of those is huge – development.
However, when you take a large undertaking and break it into small
pieces, the list may seem endless, but the speed that you’ll start crossing
things off will motivate you to push through, and I find my productivity
increases, because I’m not “all over the place”, but instead my efforts are
focused.
I wasn’t sure how much time I wanted to
allocate to the development of the site, so I broke it down into its individual
parts and assigned timeframes to each small piece. Add them all up, and you should have your total development time
– it won’t be perfect, but it will be more accurate than guessing at the entire
project in one go.
2h Login Page
1h SQL Authentication
1h Roles
15.5h Home Page
4h My Tickets
2h Layout
1h Color
Coding
1h Categories
4h New Tickets
7.5h Admin Page
1.5h Layout
1.5h Update
Tickets
30m Assign
Engineer
30m Assign
Priority
30m Assign
Status
30m Automated
Status Updates via Email.
2h Node
Coloring.
2h Categories
and Subcategories.
1.5h All Tickets
30m Layout (Copy from My Tickets, but
different SP Used)
30m Color Coding
30m Categories
So now after all of my calculations, I
assume everything will take approximately 19 hours or straight hard
programming. I have to calculate in
lunches, meetings, phone calls, emergencies, helping other engineers with their
own problems, and bathroom breaks – and between all of those things I probably
only get 50% of my time at the keyboard. It goes up and down, but that’s pretty much average. So I double my calculation to get a rough estimate
of the real development time – 38 hours – pretty much a full week.
While I put that up on my whiteboard, I
notice I have a lot of work remaining after development, but only three weeks
to do it. It’s probably best if I come
up with a breakdown of my remaining time and hold myself to it.
After development I’ll have the following
milestones remaining:
Milestone
7 – Refactor and Refine code
Milestone
8 – Replace Placeholder Graphics
Milestone
9 – Internal Testing and Bug Finding
Milestone
10 – Bug Fixing
10.1 – 6.1
10.2 – 6.2
10.3 – 6.3
10.4 – 7.1
10.5 – 7.2
10.6 – 7.3
Milestone
11 – UI Polish
Milestone
12 – Documentation
Sadly, I’m not perfect. I make silly mistakes in my development and
write kludgey code when I’m rushed. I
know this, so I can plan for it - I need to dedicate myself at least the first
half of a day to going through my work and polishing up my less impressive
sections. Also this helps to decrease
the amount of time needed for bug fixing.
Normally WAY more than ½ a day will be dedicated to this, but the sample
project I am using was very small.
Milestone
7 – 4 hours (Re-factor and Refine Code)
Placeholder graphics are important to use
when you’re writing code – nothing is more destructive to productivity than
interrupting your coding to go off on a random tangent (making pretty
pictures). According to my sketches, my
project will need 3 images:
Company Logo
Help Icon
Company Security Warning Image
Of these images, I only have to create the
Help Icon (probably just a question mark, or light bulb of some sort), and
something to tie the companies current Security Warning Image to the help desk
– possibly a complete re-creation, but also possibly just a different border /
background.
Luckily I have been making silly drawings
on my computer since I was a kid – so even though I don’t have formal training,
I can whip something up in pretty short order.
Milestone
8 – 4 hours (Replace Placeholder Graphics)
So now I have 14 business days to fit in
internal testing, bug fixing, UI polish, and documentation.
I have a horrible track record of getting
users to come test products, so I don’t even try anymore. My best suggestion is to get another
engineer - one who can be very critical of your work to come test for
bugs. Make sure they understand that
they aren’t looking for design differences or best practices – just bugs. Give them a cookie every time they find one
you didn’t know about, and document it well; steps to recreate it, screenshots
of the error messages, and current user permission levels.
Have them walk through each of your
development milestones, and search for bugs specific for each section. In larger companies, test cases and real
test plans will be used, but still the result should be basically the same.
For projects with development times under a
month, give your tester ½ the time to test your application as it took you to
write it – this general rule of thumb will ensure that they have enough time to
work through all of the workflows and business processes. Obviously, there will always be bugs found
later, but if your tester can work through all of the workflows without having
a deep understanding of the business, then someone with a more refined
understanding of how things should work will be able to reach the same end –
even without technical know-how.
If your projects have development times
longer than a month, giving the tester more time will not necessarily produce
better results, but instead - true test plans with test cases and scenarios
should be developed.
I gave myself 5 days to develop, so testing should take approximately 20 hours.
Milestone
9 – 20 hours (Internal Testing and Bug Finding)
The same amount of time dedicated to
testing should be dedicated to bug fixing – ½ of your original development
time.
Milestone
10 – 20 hours Milestone (Bug Fixing)
The two remaining milestones – 11 (UI
Polish) and 12 (Documentation) should be relatively quick – but at this point
we have 9 days remaining to Polish, Document, ensure that any Infrastructure
problems are resolved, and fix any remaining bugs.
As a general rule, I dedicate ¼ of
development time to UI polish, and ½ of my development time to documentation.
Milestone
11 – 10 hours (UI Polish)
Milestone
12 – 20 hours (Documentation)
I finished with approximately 1.5 weeks
remaining because my bug fixing phase went relatively well and only a few minor
fixes were required.
In the end, I took that extra time to work
on some extra features the customer had indicated they would like, but not need
– and that extra work is always much appreciated. It may not pay directly, but developing a product that’s above
the expectations of your customers will guarantee that they continue to solicit
your services in the future.
If I had not worked up a relatively
accurate time table before I dove into the work, I probably would have still
been able to deliver my product on time, but I can almost guarantee that I
wouldn’t have fit in any extra features, and the polish wouldn’t be nearly as
well done.
This was just one example of using
Milestones to measure and plan your software development. Naturally, larger development teams will
require a more “textbook” development lifecycle, there will be test cases and
scenarios, piles and piles of red tape and lots of disgruntled employees, but
the principle can still be applied – break the project down into it’s base
components, and then complete them one by one until you have a product that’s really
ready to deliver!
