Developing Better Software -- PLEASE READ!!

  • Thread starter Thread starter Visionary Web Services
  • Start date Start date
V

Visionary Web Services

Greetings,

I am a developer with most of my background being in web development.
I am now moving into the pocket pc platform. I do not have a degree
and all of my knowledge is self-taught, so I am very rough around the
edges. I want to increase my software development professionalism. I
know that alot of what I do could be done alot better and I looking
for a resource either on the web or in a book that could teach my a
better way of doing things.

For instance:
1) What is the best way to comment my code?
2) What are the best tools to use when designing software?
3) Should I use UML?
4) What is the best process, from start to finish, of designing,
developing, testing, debugging and releasing successful software?

I have a good idea of what the answers are but I need that extra bit
of knowledge to allow me to be more successful. I would appreciate any
insight that you could give me.

Thank you for your time and have a great day.

Jason Cochran
Visionary Web Services
 
I will second that response. I am also self-taught and I do not have a
degree. I didn't even finish high school actually. I have a GED. But that
came out to my advantage because it gave me more experience in the real
world sooner than the others who were still in school learning antiquated
techniques from indians in a classroom.

I have seen the work of others and of all the programmers I know, I can
proudly say, I am one of the best. How? Quite simple, READ EVERYTHING YOU
CAN GET YOUR GRUBBY LITTLE HANDS ON! That's right. Reading is the key...
especially the Microsoft guidelines. For example, the .NET SDK comes with a
help file and there is a section called "Design Guidelines for Class Library
Developers". This is definitely a must-read if you intend for others to use
your code.

Nothing gives a bad impression like giving a developer a stream-derived
class named something like "CInputObject". If you read that section you'll
understand what I am talking about. Naming guidelines are just as important,
if not more so, than your internal coding guidelines because they will
ultimately give people first impression of you.

As for learning how to properly architect apps, it can only come from
experience. You'll probably re-write alot of software two or three times
before you get it to a point where you feel its "just right". Take one of
these final projects and reverse engineer it in Visio. Then alot of things
will just "click" and you'll have a pretty good idea of how to architect and
design your next project.

Hope this helps! And if you ever have any questions, I'd be happy to help.
You can get my email address on my web site. (http://www.josheinstein.com)

Josh
 
I agree with the other posts. Also, Microsoft has an MCSD ceritification.
There are predefined courses to help prepare for these exams. You can
usually find training in a city near you, or do self-directed training. The
prerequisites pages will give an idea of what to look at. If interested in
certification, please get experience using all these techniques before
testing! The tests make you actually use the guidelines, not just recite
answers from memory.

http://www.microsoft.com/traincert/mcp/mcsd/default.asp

course: "Microsoft Solutions Framework"
http://www.microsoft.com/traincert/syllabi/1846Afinal.asp

course: "Analyzing Requirements and Defining Microsoft .NET Solution
Architectures"
http://www.microsoft.com/TRAINCERT/SYLLABI/2710bfinal.asp
 
Hi Jason
Make sure you use <summary> and <param> tags at a minimum. Sprinkle in some
<remarks> and <see> tags as you gain confidence. Download and install the
ndoc package - it makes prettier comments than the Visual Studio standard.
Aim your comments at a person that is of similar ability, but new to your
code. Tell them about what you are doing at the business level, not the code
detail level. Make your variable and method names self-describing.
Common sense, and you need access to one or more business "power users" who
know what the final product will be used for. Sorting these key people out
from the morass of managers and analysts that have never worked at the
coal-face is a major challenge. Listen for the expression "it hardly ever
happens". This means "it sometimes happens", and when it does, your code
needs to handle the fallout. Also, many businesses operate using a model
that does not work. Typically they have one or two key people that handle
the exceptions - they are the ones that know the problems, and can often
suggest better ways of working.
Well, after 20 years in IT (the last 5 as an architect), I am not convinced.
It is a great way to document a design, but I'm not sure it is a great tool
to create a design. My opinion might be different if object databases were
mature. Use Cases have their niche in describing concisely how a user is
going to interact with the system - I recommend them for systems where
security and fraud prevention are important. But class diagrams give you
something that is difficult to implement in a relational database.
Personally I use a good database design tool (Power Designer or Erwin) to
design a relational database that supports the business requirements. Get
that correct, and coding is a breeze.

4) What is the best process, from start to finish, of designing,
Documenting the business requirements is probably the most important step.
Often for small programs I write an outline of a user manual rather than an
official requirements document. Getting it down on paper limts "scope
creep", which is a frequent cause of non-delivery. And don't forget
interpersonal skills. If you can maintain a good working relationship with
your boss and with end users, you will end up writing useful code.

Also soak up knowledge - read all you can on design patterns, polymorphism,
encapsulation and other techniques for making software simple and elegant.
We programmers so often re-invent the wheel - borrow and adapt whatever you
(legally) can. Read newsgroups and slashdot.com. Keep an eye on new projects
in sourceforge.org.. No-one can understand in detail the huge volume of info
coming our way, but it pays to at least know what terms mean and where new
ideas fit in the scheme of things.

It is very easy to get into a rut (e.g. "I know Cobol, therefore everything
should be written in Cobol") And don't re-invent things just because there
is a learning curve. (e.g. Writing your own XML reader rather than learning
about .NET or open source DOM classes). Understanding the mainstream is
almost always the right way to go, and looks good on your CV :)

Lastly, do it once and get it right. I have worked with a number of
programmers that said they would "go back and comment/clean up their code".
Either they don't, or they spend an inordinate amount of time supporting a
flaky production system.

Well this rant will probably have the UML police after me, but thats life!

Regards

Ron
 
Ron,

I really appreciate your comments. Living in West Texas does not grant
me the ability to speak with seasoned developers very often.

I was looking at buying "Code Complete". Is it a good book? Are there
any other books on developing solid code (not necessarily on a
particular language) that you recommend?
 
Jason,

I read "Code Complete" some years ago, and I would definitely recommend it
to any programmer. It's not a bad book, however I think that some of the
content is now outdated and - while still conceptually valid - not up to
today's reality. If you have the possibility stop by a book store, and take
a look at its content before you buy it.

Gabriele
 
"Code Complete" is a good book if you want the same level of reliability as
other Microsoft Products which isn't good.

If you look in the Index of this book, Code Complete, there is NO mention of
the word, "Reliability".

That tells me a LOT about why software is so crappy in mission critical
environments or any environment.

If you look at the letter, "Q" for quality, you see very little material as
well....THAT also speaks volumes as well.

~13 pages out of a 900 page book is like 1% of the book that's devoted to
quality.
 
I don't agree with you, but I respect your opinion. What book would you
suggest?
 
Hi Jason

I don't think I've read "Code Complete", so can't comment.

There is a good book in the Microsoft series on "Writing Solid Code" (By
Steve ??? I think) . The examples are in C and C++, but the principles apply
universally.

I went to the New Zealand Tech Ed conference this week. My feeling from the
conference was that "Model Driven Architecture" is the coming design
technique once the hype over Extreme Programming dies away. They were
talking of UML models, but the principles seem to apply equally to starting
with a database model - I have been pushing this technique for years.

Also, don't rely on Microsoft's Visio tools for UML or database model
design. They are sadly underpowered. I was really underwhelmed by the
session on UML with Visio - poor reverse engineering, no round trip
engineering and (quote) "Interfaces really aren't handled all that well"

Regards

Ron
 
Now, that's a tough question.

If you read Code Complete (of which most Microsoft employees do) one could
guess that you might get same quality software...patches...more patches,
patches that break other patches.....Just remember, Microsoft has thousands
and thousands programmers and they are supposed to be the best of the best,
and have years of experience.....

How about other software companies? Well, like I said tough
question....they have just as many patches or bugs...just not trumpeted by
the news as much...

How about looking at the American car companies in the 1970's and compare
that's to the quality of American car companies now? How about looking at
how the Japanese made more reliable cars?

There is really no good book on software development quality.....

IN fact, software companies will tell you that BUGS are a fact of life.

Well, that's what the American Car Companies said in the 1970's and 1980's.

Has the quality and reliability of cars gone up? Yes indeed.

Look at GE....they have a Six Sigma program tailored after Motorola's...
six sigma is a process of improving things....

where 6 sigma is means 3.4 defects per million.

HOWEVER, software companies will tell you that things change and
requirements change so much, it would only stifle new development...yet we
spend a lot of time applying patches and windows updates and fighting
viruses......


NUTSHELL
I don't know what to tell you, but I aiming higher than those who say,
"software bugs are a fact of life".
 
Hi there.

First off, I would recommend reading Code Complete. Fair enough most
of the code examples are out of date, but it's actual theory and
advice that this books gives which I find incredibly useful. It's an
all-rounders book, it tries to cover many facets of being a
programmer, you will become a better developer even if you use only a
fraction of the book's content.

Writing Solid Code by Steve McGuire is a good book, though it's highly
focused on C/C++, so VB'ers out there might not benefit enough to
justify buying a copy. There are many pieces of advice regarding how
to write better code, but check out the book before you buy, if you
can, just in case it might not suite your needs.

Another area that I feel developers should concentrate a lot on is
debugging. I recommend Debugging Windows Applications by John Robbins.
There is a 2nd edition of this book which is updated for .NET. I have
a copy an have found it very handy indeed. There's a lot of good
advice in there. Also check out 'Debugging: The 9 Indispensable Rules
for Finding Even the Most Elusive Software and Hardware Problems' by
David Agans - another excellent book.

As for testing, I read 'The Science of Debugging' by Matthew Telles
and Yuan Hsieh, or 'Software Testing' by Ron Patton. These 2 books are
highly recommended.

More books I recommend:

Programming Windows, 5th Edition by Charles Petzold.
Programming Applications for Microsoft Windows by Jeffrey Richter
Debugging the Development Process by Steve McGuire.
Writing Secure Code by Michael Howard and David LeBlanc.

There are many other books I have read which I have benefitted from,
by I don't want to list too many!

Hope these help.

later.
Jas.
 
nospam said:
If you read Code Complete (of which most Microsoft employees do) one
could guess that you might get same quality software...patches...more
patches, patches that break other patches.....Just remember, Microsoft
has thousands and thousands programmers and they are supposed to be
the best of the best, and have years of experience.....
Click to expand...

Books are one thing, what people do is another :-) Everyone has similar
books on their shelves, yet few follow them in practice. Microsoft has
very good marketing and PR, but I don't think they are particularly
better or worse than other large companies. Their problems are magnified
by the press and the sheer numbers they have. Take a look at some of
their code, such as the shared source C# compiler, written in C++. It's
not bad code, but pick any spot at random and you'll see code that does
NOT follow "best practices", or even the basic C++ advise in Stroustrup's
book. In my experience, this happens everywhere, good books
notwithstanding. So the presence or absense of good books doesn't seem to
be the main problem. We've had good books for decades.
There is really no good book on software development quality.....
Click to expand...

As I said, I think there are, but they are sometimes difficult to apply
in the real world. You inherit some horrible code, you have a deadline,
you have a manager who couldn't care less what those books on your shelf
say. You're writing some code and something is just not working and you
have to come up with some dirty kludge or else. You realize the design is
wrong and needs to be redone, but that would put you behind schedule and
would never be approved. It happens to all of us, so we try to do the
best we can, given our constraints, training, and experience. And the
tools we're using are often broken themselves. All in all, given these
scenarios, I think we do a pretty good job, but I agree that it could be
a lot better, and should be. And I think most of the people here would
agree. We all want to write bug-free code!

That's assuming, of course, that you are otherwise qualified for the job
you're on. I've also seen plenty of cases where people have lied their
way into positions, and are not meeting minimum quality standards at all.
I heard a story from a friend at IBM about some C++ code another IBM
developer has written that was just horrible, shamefully bad. My friend
inherited it. The guy apparently didn't understand C++ 101, yet here he
was with an IBM business card saying he was an software engineer. And
were he to leave IBM, I'm sure that "experience" on his resume would open
new doors quite easily. And this guy's defective code was out there with
customers, as is Microsoft's. MS has the same problems, and if you don't
believe it, cultivate some inside friends and get the real story instead
of the PR. I have, and I've also talked in detail with some managers
there. MS is no different, as the bug reports on these news groups
testify.
IN fact, software companies will tell you that BUGS are a fact of
life.
Click to expand...

IMO, that's just convenient BS people buy into.
NUTSHELL
I don't know what to tell you, but I aiming higher than those who say,
"software bugs are a fact of life".
Click to expand...

If I ran a software company, I'd hire you just on the basis of that one
statement :-)
 
Back
Top