The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Suggested practices for individual developer

I am an independent developer. I face problems while designing and testing solutions. Most of the time, code is not of good quality when there is pressure from the client. I want to know what practices I can follow to deliver good quality product and how to test the application alone when I cannot hire testers.
RP
Friday, September 26, 2008
 
 
version control, automated builds, unit tests, etc

Perhaps taking a look at Code Complete would be helpful.
Andrew Austin Send private email
Friday, September 26, 2008
 
 
Peter Send private email
Friday, September 26, 2008
 
 
Do not forget to use any of the version control system (I use subversion) for individual development.

Once you accidently delete some file or do some stupid coding, you will realise its importance.
I have reverted to previous versions of files many times!
Smart Components Send private email
Sunday, September 28, 2008
 
 
In practical terms, keep control of your update process. This is usually where things go wrong...


I keep a folder for updates, in there I put sql patches, release notes, configuration updates. I just toss them in as I work on the next release. I keep a simple word document in there to track all the things that were changed.

I work on the code, and make changes to database and stored procedures.

I never use table editors to apply the changes. I instead save the changes as a script. Then I run that script against my dev database. If it works, I save it in my sql updates directory. Any adjustment to the database I am careful to put aside as a script.

Once I am satisfied with the testing I have done in my app, I prepare the patch script. The patch script has logic in it to restrict that it can only be run against a database with a particular version. Each patch is designed to bring the application up to the next version. I may create a rollup once in a while, but only if there were a number of subsequent patches. I think I have only ever done it twice, usually it is patch by patch.

I assemble all the little scripts I added into a single update script. I collect all the notes for any manual config operations needed (add a section to the config file, etc...) all the executable files, dll's.

Then I test my deployment.

I have a separate machine I use as a deployment testing server. Ideally, I get a backup of the client's database, config and executables. I copy them onto my test server.

If there are a number of sql updates, I really want to try running them on a backup copy first.

I then simulate the application of the patch to their live system.

Even if it is only client application changes, I need to do some quick regressing testing to see if I broke anything with my updates.

In case of a large update I will run a db comparison of the schema of my dev databse and the client database, just to confirm the structure is similar.

I have custom scripts that sanity check 'config' tables like error codes, status values, etc... to see if there are any discrepancies.

I use source control Visual Source Safe... (don't laugh!) Despite it's bad rap, it has never failed me, then again, I don't do any 'merges' it is check out, edit, test, build, check in. My check in and checkout is manual as I develop in Delphi and it is not integrated. I put all my sql patches in there too.

I back up my source safe data and put a copy offsite in case my house burns down.

So.. this process allows me to test the application, as if I were the customer, with the customer's data, as if I had just been patched.

It is usually in the updates that we bork up something. A connection string that points to your localhost, a local path, a missed column addition, a forgotten script to set values for the new column for historical records, an old version of a sproc...

It is hard enough to make changes to code successfully with a good process, if you suffer from too many 'Oops!' mistakes that just multiplies your chances of failure exponentially.


A few guidelines for the solo developer... I've done it for years and made plenty of mistakes!

Don't try to deliver huge updates. Small pieces at a time. Keep control of deployment - use an update process that will help you catch 'Oops!' mistakes.

Keep focused on the bugs your need to fix, it is easy to get sidetracked on a good idea or enhancement... that winds up taking up time or creating new bugs! Mark it down in your list of future enhancements. Usually we are fixing bugs or adding functionality. New features are like saving for a rainy day -  we need to save up for when our clients don't need any updates for a while. *wink*
Jason T
Friday, October 03, 2008
 
 
One other piece of advice.

If you cannot hire a tester, if you can convince your customer to have a test server you can deploy your application there and 'force' them to approve updates.

In my day job, I call this UAT - User Acceptance Testing.

Two kinds of testing:

1) Focus testing - whatever you made a change to Ex: 'Invoicing module - credit enhancements'. Suggest a series of tests that they need to run to certify it is safe for production. Ie the focus of the patch.

2) Regression testing - they should run through a battery of tests to ensure that the fixes didn't break anything

If any bugs are found in this phase - KEEP YOUR UPDATE DISCIPLINE! Hotfixes have a way of falling in the cracks and then we have the same bug in production we found in testing.. this is BAD!
Jason T
Friday, October 03, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz