Eight Aspects of Software Development http://sjanes71.blogspot.

com

Eight Aspects of Software Development

April 2008

I've been doing software development in one way or another for many years and have explored
lots of different bits of philosophy. Here is a course of practical software development. These are
the things you know, improve and practice.

1. Writing Others have said this as well: the process of writing well is the same skill-set
as programming well. Its a matter of terminology and results. In both cases, you need a
goal [what kind of thing you're making], a plan [how you're going to make it], and
patterns [the types of things you do to make it]. Doodling on a notepad in writing would
be like programming little snippets or prototypes for future reference or idea capture. If
you were writing a short story, your programming may be the implementation of a
function or algorithm. Writing a report or case study could be compared to a library in
programming. Writing a novel may be compared to writing an application. Writing an
office suite or enterprise system could be a multi-volume encyclopedia. Words,
sentences and paragraphs: variables, statements and functions. Design patterns in writing
vs. programming?--that's a whole other post to come. Lets go back to those
fundamentals, where your words, sentences and paragraphs fit: the programming
fundamentals.
2. Programming fundamentals Knowing how to program is all about knowing the
semantics commonly used for programming. Its not the syntax, its what you say. If you
are thinking about getting into programming, you will need if-then, while-loops,
for-loops, functions, methods.
3. Language commitment Choose your specializations and know the language
weaknesses. I like PHP because of its ubiquity everywhere except Windows. If the
servers I worked on were based on Windows [IF... I've never seen a reliable Windows
system, so why make them a server?], I would likely have to accept ASP/VisualBasic as
the language to use in that environment. If I need more "research" style programming,
I'll consider Scheme or Arc.
4. Algorithms and Data fundamentals Knowing how to model data efficiently, or how
to trade memory for speed and vice versa are a must. Start with a bit, add bits and
meaning to store numbers, use numbers to encode symbols, and so on. Knowing what

1
Eight Aspects of Software Development http://sjanes71.blogspot.com

algorithms exist can help you avoid repeating work (think of a catalog of algorithms like
being a free-for-all patent office, someone else has done the hard work and given it to
the world and the patents are all expired.)
5. Test-driven development "Trust, but verify", a signature phrase of Ronald Reagan
was appropriate because of the Russian phrase: Доверяй, но проверяй. (I just like
copying and pasting crazy letters... but that's another story.) Test-driven development
makes your life so much easier--you write your tests to check the operation of your
program, and then you automate the execution of those tests so that you only need to
worry about them when they fail. Run them often, write them continuously. If you are
not writing tests, you are not programming for reliability.
6. Event-driven, Aspect-driven and Concurrent-distributed programming Event
driven programming is a big departure from functional programming, and aspect-driven
programming is kind of like a fusion of functional programming and event-driven
programming. Aspect-oriented programming isn't taught much yet in schools, but I have
found it to be a disturbingly easy way to defer the binding of "what, when and how you
do it" to the run-time systems of aspect-oriented systems. Think of it like event-driving
programming on more steroids than Major League Baseball. It does bring in a new set of
vocabulary terms that will initially confuse you like "advice" and "pointcut", but in the
end they'll help you talk to other programmers about what you're doing. You don't have
to have a compiler to support it, like object-oriented programming in C, you can do it on
your own as well. Concurrent-distributed programming forces you to think about
systems as they work together instead of in singular nodes--these are the exciting bits of
programming because you can to begin thinking of your systems as being cells
cooperating in an organism that comes to life. There are a lot of issues to manage in
distributed systems, you'll spend a lot of time formalizing the interactions. Some would
throw the "Service Oriented Architecture" buzzword about for this kind of
programming.
7. Source control discipline This is where you learn discipline and earn a big assist
from the computer: you're going to let the computer track the changes to your source
code. My personal choice for source control is now Linus Torvald's GIT because of its
supreme awesomeness. The borderline between backup systems and source control is
more and more blurry--in other words, use your source control as your backup system, I
do.
8. Tool commitment Which editor are you using? Have you learned the 20% feature set
of what you'll use it for 80% of the time? Really well? Do it. The better you know your
tools, the easier your work becomes. The less you switch between tools, the less time

2
Eight Aspects of Software Development http://sjanes71.blogspot.com

you'll waste re-learning how to do things. Learn when to use the mouse and when to use
the keyboard. Once a year, if you have time, evaluate all of your tools to see if they
"need sharpening"-- that could mean upgrading or replacing. I'm an vim convert from
emacs after I realized that I wanted hardcore simplicity for text editing. Typing "c4w"
becomes "change the next four words" and I didn't have to use the mouse to select the
text! Get polished with your editor and source editing starts to become a stream of
consciousness or nearly automatic act. I'm not a big fan of IDE frameworks like Aptana
because the tool starts to interfere with the work: especially when updates rearrange your
workspace, not to mention, the time lost when the workspace spontaneously explodes
from "the replacement of a small screwdriver inside." If you must use a complicated
environment like Aptana, back it up with the tool you use in #7: source control--it's not
just for your source code anymore.

Bonus Aspect: User Interfaces

This is the hardest one because as a programmer, you know how the computer works. For the
user, they're essentially clueless and they don't care. They just want to get their work done, they
don't want to know how the computer works behind the curtain--just make it work. So
developing user interfaces is a big deal and hard work.

Did you enjoy this?

Watch for more at http://sjanes71.blogspot.com/ .