Wrapping up software

[pigeonrandle]

Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.

All comments welcomed and appreciated in advance, so ... thanks!
James Randle.

[ssamuel]

James,

A few of the things that I've found useful in releasing software to end
users:

1. Go through every line and look at the exception list in the
framework docs for any methods you call. Understand when each is
thrown, and catch every (and only) exception that you can do something
with. Assume anything not caught will give the user a nasty error.
Catching SecurityException on a disk write is more important than
FileNotFoundException: good users tend to know where their files are
more often then they know that they don't have write permissions to the
department share.

2. Any time anything goes wrong, do the following: show the user a
polite message asking them to change their input (like sales, the
customer is always right; your software made the error, not them), and
write extensive debugging information some place where they'll be able
to get it to you.

3. Document everything public. If you're releasing a library, use the
built-in XML documentation that plugs into Intellisense. If you're
releasing non-library software, document from turning on the computer
through all normal tasks as bulleted how-to guides. Include a glossary
and screen shots. Don't bother writing mission statements and such
because no one reads them. Searchable online troubleshooting guides
have always seemed to be the most useful for my users.

4. Write and work around test cases that includes inane things, like
people unplugging USB drives in the middle of saving and the disk
filling up. Someone will be missing installation files, configuration,
proper access to the thing you assume everyone has access to, etc.

5. Don't wait for people to save configuration and don't make them load
it. Give them options like starting where they left off.

I'm sure there's more but that'll take you a long way.

I'm not sure about the usefulness of obfuscation: it's been proven
extensively that there is almost no security in obfuscation. Those who
want to reverse engineer always find a way. I prefer to patent and be
ready to defend my claim. Also, know your rights as a copyright holder;
anything original you do is copyrighted by you whether you explicitly
claim it or not.
HTH!
Stephan
pigeonrandle wrote:

Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.

All comments welcomed and appreciated in advance, so ... thanks!
James Randle.

[pigeonrandle]

Stephan,
Thanks for your reply. I already have a big list of things i still need
to do, and it seems to be getting bigger and BIGGER!

Thanks again,
James.

ssamuel wrote:

James,

A few of the things that I've found useful in releasing software to end
users:

1. Go through every line and look at the exception list in the
framework docs for any methods you call. Understand when each is
thrown, and catch every (and only) exception that you can do something
with. Assume anything not caught will give the user a nasty error.
Catching SecurityException on a disk write is more important than
FileNotFoundException: good users tend to know where their files are
more often then they know that they don't have write permissions to the
department share.

2. Any time anything goes wrong, do the following: show the user a
polite message asking them to change their input (like sales, the
customer is always right; your software made the error, not them), and
write extensive debugging information some place where they'll be able
to get it to you.

3. Document everything public. If you're releasing a library, use the
built-in XML documentation that plugs into Intellisense. If you're
releasing non-library software, document from turning on the computer
through all normal tasks as bulleted how-to guides. Include a glossary
and screen shots. Don't bother writing mission statements and such
because no one reads them. Searchable online troubleshooting guides
have always seemed to be the most useful for my users.

4. Write and work around test cases that includes inane things, like
people unplugging USB drives in the middle of saving and the disk
filling up. Someone will be missing installation files, configuration,
proper access to the thing you assume everyone has access to, etc.

5. Don't wait for people to save configuration and don't make them load
it. Give them options like starting where they left off.

I'm sure there's more but that'll take you a long way.

I'm not sure about the usefulness of obfuscation: it's been proven
extensively that there is almost no security in obfuscation. Those who
want to reverse engineer always find a way. I prefer to patent and be
ready to defend my claim. Also, know your rights as a copyright holder;
anything original you do is copyrighted by you whether you explicitly
claim it or not.
HTH!
Stephan
pigeonrandle wrote:

Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.

All comments welcomed and appreciated in advance, so ... thanks!
James Randle.

[Michael Nemtsev]

Hello pigeonrandle,

Testin, testing and testing one more time :)
Unit-, component-, system-, integration-, stress-, whitebox- testings, codecoverage.
But this doesnt help you on 100%, ask users go give u feedback and for example
present the free version of your app to the 20 most active users who have
found the bugs

pHi,
pI have written several pieces of software and would like to hear any
pthoughts anyone has on what measures i should take to ensure(!) its
pstability and security at the hands of the *users*. I have obviously
pput error handling in :O) but have heard of loads of other things i
pcould do like obfuscation and assembly signing.
pAll comments welcomed and appreciated in advance, so ... thanks!
pJames Randle.
p>
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[ssamuel]

James,

Seems like that's always the case. Just remember that all-nighters
become 5% less productive per year of coder's age past age 23. :)
Stephan

pigeonrandle wrote:

Stephan,
Thanks for your reply. I already have a big list of things i still need
to do, and it seems to be getting bigger and BIGGER!

Thanks again,
James.

ssamuel wrote:

James,

A few of the things that I've found useful in releasing software to end
users:

1. Go through every line and look at the exception list in the
framework docs for any methods you call. Understand when each is
thrown, and catch every (and only) exception that you can do something
with. Assume anything not caught will give the user a nasty error.
Catching SecurityException on a disk write is more important than
FileNotFoundException: good users tend to know where their files are
more often then they know that they don't have write permissions to the
department share.

2. Any time anything goes wrong, do the following: show the user a
polite message asking them to change their input (like sales, the
customer is always right; your software made the error, not them), and
write extensive debugging information some place where they'll be able
to get it to you.

3. Document everything public. If you're releasing a library, use the
built-in XML documentation that plugs into Intellisense. If you're
releasing non-library software, document from turning on the computer
through all normal tasks as bulleted how-to guides. Include a glossary
and screen shots. Don't bother writing mission statements and such
because no one reads them. Searchable online troubleshooting guides
have always seemed to be the most useful for my users.

4. Write and work around test cases that includes inane things, like
people unplugging USB drives in the middle of saving and the disk
filling up. Someone will be missing installation files, configuration,
proper access to the thing you assume everyone has access to, etc.

5. Don't wait for people to save configuration and don't make them load
it. Give them options like starting where they left off.

I'm sure there's more but that'll take you a long way.

I'm not sure about the usefulness of obfuscation: it's been proven
extensively that there is almost no security in obfuscation. Those who
want to reverse engineer always find a way. I prefer to patent and be
ready to defend my claim. Also, know your rights as a copyright holder;
anything original you do is copyrighted by you whether you explicitly
claim it or not.
HTH!
Stephan
pigeonrandle wrote:

Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.
>
All comments welcomed and appreciated in advance, so ... thanks!
James Randle.

[PS]

"ssamuel" <ss*****@gmail.comwrote in message
news:11*********************@e64g2000cwd.googlegro ups.com...

James,

Seems like that's always the case. Just remember that all-nighters
become 5% less productive per year of coder's age past age 23. :)

Also remember that 82.7% of all statistics are made up on the spot.

PS

>

Stephan

pigeonrandle wrote:

>Stephan,
Thanks for your reply. I already have a big list of things i still need
to do, and it seems to be getting bigger and BIGGER!

Thanks again,
James.

ssamuel wrote:

James,

A few of the things that I've found useful in releasing software to end
users:

1. Go through every line and look at the exception list in the
framework docs for any methods you call. Understand when each is
thrown, and catch every (and only) exception that you can do something
with. Assume anything not caught will give the user a nasty error.
Catching SecurityException on a disk write is more important than
FileNotFoundException: good users tend to know where their files are
more often then they know that they don't have write permissions to the
department share.

2. Any time anything goes wrong, do the following: show the user a
polite message asking them to change their input (like sales, the
customer is always right; your software made the error, not them), and
write extensive debugging information some place where they'll be able
to get it to you.

3. Document everything public. If you're releasing a library, use the
built-in XML documentation that plugs into Intellisense. If you're
releasing non-library software, document from turning on the computer
through all normal tasks as bulleted how-to guides. Include a glossary
and screen shots. Don't bother writing mission statements and such
because no one reads them. Searchable online troubleshooting guides
have always seemed to be the most useful for my users.

4. Write and work around test cases that includes inane things, like
people unplugging USB drives in the middle of saving and the disk
filling up. Someone will be missing installation files, configuration,
proper access to the thing you assume everyone has access to, etc.

5. Don't wait for people to save configuration and don't make them load
it. Give them options like starting where they left off.

I'm sure there's more but that'll take you a long way.

I'm not sure about the usefulness of obfuscation: it's been proven
extensively that there is almost no security in obfuscation. Those who
want to reverse engineer always find a way. I prefer to patent and be
ready to defend my claim. Also, know your rights as a copyright holder;
anything original you do is copyrighted by you whether you explicitly
claim it or not.
HTH!
Stephan
pigeonrandle wrote:
Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.

All comments welcomed and appreciated in advance, so ... thanks!
James Randle.

[pigeonrandle]

I'd heard it was closer to 85.7%.

And is that a compound percentage, or will i be brain dead at, errrr,
53?

Cheers for your replies,
James.

On Oct 30, 5:47 pm, "PS" <[e-mail]:

"ssamuel" <[e-mail] in messagenews:11*********************@e64g2000cwd.go oglegroups.com...

James,

Seems like that's always the case. Just remember that all-nighters
become 5% less productive per year of coder's age past age 23. :)Also remember that 82.7% of all statistics are made up on the spot.

PS

Stephan

pigeonrandle wrote:

Stephan,
Thanks for your reply. I already have a big list of things i still need
to do, and it seems to be getting bigger and BIGGER!

Thanks again,
James.

ssamuel wrote:
James,

A few of the things that I've found useful in releasing software to end
users:

1. Go through every line and look at the exception list in the
framework docs for any methods you call. Understand when each is
thrown, and catch every (and only) exception that you can do something
with. Assume anything not caught will give the user a nasty error.
Catching SecurityException on a disk write is more important than
FileNotFoundException: good users tend to know where their files are
more often then they know that they don't have write permissions to the
department share.

2. Any time anything goes wrong, do the following: show the user a
polite message asking them to change their input (like sales, the
customer is always right; your software made the error, not them), and
write extensive debugging information some place where they'll be able
to get it to you.

3. Document everything public. If you're releasing a library, use the
built-in XML documentation that plugs into Intellisense. If you're
releasing non-library software, document from turning on the computer
through all normal tasks as bulleted how-to guides. Include a glossary
and screen shots. Don't bother writing mission statements and such
because no one reads them. Searchable online troubleshooting guides
have always seemed to be the most useful for my users.

4. Write and work around test cases that includes inane things, like
people unplugging USB drives in the middle of saving and the disk
filling up. Someone will be missing installation files, configuration,
proper access to the thing you assume everyone has access to, etc.

5. Don't wait for people to save configuration and don't make them load
it. Give them options like starting where they left off.

I'm sure there's more but that'll take you a long way.

I'm not sure about the usefulness of obfuscation: it's been proven
extensively that there is almost no security in obfuscation. Those who
want to reverse engineer always find a way. I prefer to patent and be
ready to defend my claim. Also, know your rights as a copyright holder;
anything original you do is copyrighted by you whether you explicitly
claim it or not.

HTH!

Stephan

pigeonrandle wrote:
Hi,
I have written several pieces of software and would like to hear any
thoughts anyone has on what measures i should take to ensure(!) its
stability and security at the hands of the *users*. I have obviously
put error handling in :O) but have heard of loads of other things i
could do like obfuscation and assembly signing.

All comments welcomed and appreciated in advance, so ... thanks!
James Randle.- Hide quoted text -- Show quoted text -