Tuesday, June 24, 2008

Software Development Myth #2: "There are applications that don't need to be modular"

"My application doesn't need to be modular" means several things:

1) My application will never change, or will change so slowly that I will have plenty of time to make any and all changes.

Yeah right. Been coding long? Guess not.

Rapid change is accomodated by modularity - have it and you will be able to handle anything they throw at you.....neglect it, and you'll be neck deep in spaghetti with a red-faced manager screaming at you.

2) My application will never grow

Similar response as to number one - though this may not be quite as obvious to the noob - apps ALWAYS grow. Period. Unless the app just totally bites to begin with - system begets system. Whenever users actually get to use a system, it inspires them to want more system. Don't know how else to say it - but, if you build it, it will grow.

And if you build it monolithically - you're going to have to be reevaluating the entire app everytime you need to grow...not fun, and it definitely doesn't make you look like a rock star.

3) My application will never be maintained by anyone but me

Really? Nice. So you will NEVER leave this job. You will NEVER grow disinterested in maintaining the same code base year after year after year.... I don't know about you - but I'm usually bored immediately after it goes to production.....

The new maintainers will not be happy people if your code is a big monolithic mess.

4) My application will never be used for anything except what it was originally intended for

This one is funny - it's amazing how expectations change over the course of an application's lifetime. I wrote a system once that basically assumed (based on the existing business process) that only one person would be entering information at a time - and that the information would then be sent out and tracked to several hundred people. Unfortunately for the system - the organization grew by leaps and bounds - to the point that the business process started to parallelize - meaning more than one person would be entering information. Uh oh.

Because a user doesn't have your unique vision about the system, they will often use it in ways you never even thought of, let alone intended. If your application is not modular - you won't be able to accomodate this.

Software Development Myth #1: "The right tool for the job"

Us software development types are rigid - we think in black and white, 1's and 0's. This serves us well when we're dealing with a machine...however, we should realize that our machines are only the canvas on which we paint our masterpiece.

We face a plethora of design and platform decisions that really boil down to nothing more than what we feel will be a good fit - and you know what - THERE'S NOTHING WRONG WITH THAT. Soak that in for a sec - it's actually really liberating: We are craftsmen - artists even - we spend our career developing an instinct for designing elegant, well organized systems that efficiently automate life for people. Repeat after me: It is ok to trust my instincts when it comes to design decisions.

Take programming languages as an example - many people feel strongly that C# and .NET are the way to go for enterprise applications - many people feel strongly about Java and JavaEE. Some people (who should be committed) are really excited about RoR. Can we solve pretty much any enterprise automation problem with any of these platforms? Yes. Is there an absolutely Right or Wrong answer as to which should be selected? Not really. A lot of it boils down to the style of the programmers that will be working the system ... there may actually be some benefits and drawbacks to different languages/platforms - but when push comes to shove any of them will work for whatever thing you're trying to build.

So then - knowing that we're computer geeks and we have to have things in 1's and 0's - how do we decide what to choose? Given a new App, what do I do? RoR or PHP? Java or C++ CGI?

I propose you do what the jazz improvisor does when he steps up to take a solo - make it up as you go... do what you feel will make the most organized, elegant work of art out there (elegant is really just a synonym for organized which just means your code is more easily maintained, in case you need to make a business case for this or something) - does RoR get your juices going, does it make you feel like you're putting out a better product? Then use it....

So let's try again.....repeat after me: It is ok to trust my instincts when it comes to design decisions.

So the corollary here, for those of you that don't see it yet - is that, while you are enjoying this profound freedom - let's not selfishly hog it up - pass it on to your co-workers, or any other programmers you come in contact with........in other words - let's practice some people skillz (I know - we're programmers, so we were probably born without that particular gene - but let's work at it) - if you are pumped about programming in Java - don't force it down the throat of your co-worker who is a big Cobol.NET fan - try for common ground as much as possible.......and try to avoid the self-serving urge to claim that your way is the only right way - cause really... it's not.

Friday, June 20, 2008

Party Time

c had a birthday this weekend -- here she is enjoying her party!!!

Art or Science

A fundamental disconnect in the world of software engineering is around the actual nature of the activity that most software developers engage in...

Many assume it is a science - that one can be taught specific rules and then one can program, flawlessly, any new system that is needed.....extending that to think that as soon as compy's are fast enough - they'll be able to develop the software themselves.

Others view it more as an art - that there is a creative, human thing necessary to solve the problems that software systems are targetting to solve.

There is some value to comparing software development to past activities.... Let's say it's a science - let's think about something like simple, simple physics... we observe that something is happening: when we let go of the apple, it drops to the ground.... we hypothesize that it obeys certain rules about acceleration and momentum; we test, etc... following the good ol' scientific method that we know and love... eventually coming to an approximation of what's really going on....

so, if development is science... it might go something like this: we look at the problem and we hypothesize what will fix it... we try it.. it works, we move to the next problem.......

Compared to Art:
with art, we have typically some kind of canvas - whether it is an actual canvas, a piece of paper, a piece of rock or the air around us... and we have a palette....colors, sounds, textures, etc.. and they can be applied to the canvas in any number of ways....the end result being to arouse emotional involvement, and communicate some feeling or idea on a deeply emotional level...

so, if development is art - the computer is the canvas, and the palette is the plethora of programming languages, platforms, tools and frameworks available today... which can be applied in any number of ways - the end result being to arouse emotional involvement, and to communicate some feeling or idea on a deeply emotional level....

So - is either one of these really on the mark.... no... but yes. One of the fundamental reasons science doesn't fit - is that there are a number of ways to do a single thing.......science is about getting as close to the single "right" answer as possible. But there is definitely science in the development process, in terms of testing things and being objective, and making sure that we solve the problem we set out to.............on the flip side - one of the fundamental reasons it's not strictly art is that simply communicating emotion is not the end of software development - though it is necessary - the real end is to enable action on the part of the user (not just inspire to action - even though that is an important thing).

So - I assert(); that system development is a unique hybrid never before seen on the face of the planet... and not yet having come into its own in terms of being commonly understood in society for its unique blend of art and science....