Site Sections
Posts
3
Comments
3
Trackbacks
0
Sunday, October 05, 2008
Approaches to making good software and enjoying yourself because of it: PART 1
Foreword

What to blog about, what to blog about... how about the way I look at making good software, with some broad, sweeping statements of truth? Roughly translated, you might say "the way I approach making software," because we all want it to be "good." Working with a team on a software project of any significant magnitude presents choices and situations of enormous complexity, both intellectual and emotional... Perhaps more than we developers give ourselves credit for.

A word of warning: my attention span when writing such things tends to start very focused, but linearly decrease as a function of time, so I'm going to share my thoughts on only some of this stuff in this entry.  My view is that having the right approach to a job like this (software development) not only makes a better product, but turns what might be "just a job" into something genuinely enjoyable.  Most all of these items deserve quite a bit of elaboration, and lots of books have been written on the variants and derivatives of them.

Embrace Testability as Your Preponderant Master

Forsake all others before it.  If the correctness and quality of your software is based solely on good intentions, then there's probably little need to read any further.  The pseudo-paradox and arch enemy of TDD is the unfortunate fact that most all large software projects that were written without TDD still perform the function they're supposed to.  Multinational corporations make billions every year on the backs of software systems that are not test driven, and probably have little (if any) automated tested at all!  Egads! But this is the key to writing "good" software -- it's not that you can't eventually get it to work, it's that human nature strives for something better.  I liken it to living in a cardboard box vs. a soft bed in a quiet, air conditioned bedroom -- your will certainly achieve sleep either way, but given the choice, you're probably going to take the bed.  Testability (which I will write about in the [hopefully] near future) naturally leads to, and requires a measure of good design -- which, generally speaking, should lend itself to something more understandable and more easily manipulated. 

Working with software that can break at a moment's whim, or requires meticulous attention to detail for even marginally complex or simple tasks, then you're probably spending most of the day being frustrated.  I've oft postulated that performing well with such software tasks requires, indeed, more brainpower and determination than working with and creating a well written and executed code base.  The problem is, you're wasting all the brainpower being annoyed, with your sole motivation when sitting in front of monitor being to just get the thing done so I can go home/get a better review.

Eliminating this frustration frees the mind for more constructive purposes, which means the software is going to get better, and the processes will likely start to improve.  Your relationships with your coworkers will likely also become more intimate, perhaps even becoming downright neighborly -- your tie will be forged from a common drive to produce excellence and be excellent in the process, rather than just shared misery.  This is all speaking in absurd hyperbole, of course, but the idea is there somewhere.


Don't Be Afraid to Make Mistakes

There was a time when my primary motivation for the decisions I'd make in programming tasks/design were based solely on one thing: to not leave any room for criticism when the work was viewed by others.  Basically it meant trying not to do the wrong thing, versus trying to do the right thing. I see some of this in others today, and I think it's important to know that it's okay to make mistakes.  In fact, it's probably the best thing you can do!  No matter what your skill level, nobody knows everything, and openly and honestly making the best decisions you know to make and welcoming criticism/discussion by your peers is the best way to grow -- and it helps the quality of the end product at the same time.
posted @ Sunday, October 05, 2008 2:53 PM | Feedback (2)
Tuesday, July 22, 2008
The fundamental importance of unit tests
As a convert to the religion of test-driven development (once an individual who echoed the same kind of thoughts as above), I must confess that the fault of the opposite reasoning lies not on the shoulders of those that walk the path of the lost, but falls squarely on the believers themselves.
posted @ Tuesday, July 22, 2008 3:51 PM | Feedback (1)
Friday, July 11, 2008
Blake Caraway and Duane Derouen Join Headspring Systems
Duane Derouen (blog) and Blake Caraway (blog) have joined the Headspring Systems team.  Welcome guys!  Both bring a lot of valuable experience to the team, and I look forward to working with them in all of our projects to come.
posted @ Friday, July 11, 2008 5:17 AM | Feedback (0)
Archives
Post Categories
other blogs
News