i forgot why i like developing software

it is easy for me to get caught up in the technology wars, chasing after the silver bullet in technology, the negativity that is associated with having to deal with bad software, bad implementation practices, and much more...

... but, i am getting weary lately of getting bent by all these distractions.

Software is what i want it to be. there may be norms, there may be standard practices, there may be accepted and practiced conventions. But there are no rules. There is only your imagination and your ability to break free of so many of the norms that stifle creativity.

i forgot why i like developing software. i actually do this more times than i care to admit. i do all the bad things i mentioned above. i only have myself to blame when i do this.

i like developing software because there really are no limits or boundaries other than your own imagination and ability. i am talking about developing software as a one person shop, where there are no meetings, no deadlines. A world limited only by your own imagination and skill.

i also, far too often, forget the joy of engaging in an activity where you have total freedom, and total control. kind of like the guys on Swamp people, though probably not as cool as being a gator hunter. i suspect i forget this because i have to spend far too much of my time these days developing things i am just not all that interested in.

work really sucks when you are doing things that are not of much interest. when you have a gig that engages you it is not really work at all. But, with time being scarce and at a premium i still need a development fix that interests me.

i have found a new hobby in hydroponic gardening. i am documentating my experiences and learning. i want to put together a website on the subject. Putting two and two together i just do not want to go the drudgery of yet another website (yaw). I want to try a new user experience for delving into information. i have no idea what that new experience looks like at the moment, but that is half the fun ...

and, like i'm sitting on the beach in the keys with a cold one i have no sense of time or urgency to get anything done :-).

When Developers Do Not Work In Production...

...Software suffers.
This will certainly ruffle some feathers. I suspect if I was working in development and did not have any experience with how my stuff worked in production I might take offense.
In defense of developers, it is seldom part of the plan of development leadership to expect their development staff to gain this experience. I am not talking about some afternoon field trip to one of the production customers to be a nuisance looking over their shoulders. I am talking about some real time on the pond. Sitting down with the end-users and asking them what they like and more importantly what they don't like. Getting to know their workflows and how your software facilitates, or more importantly how is impedes their work.
I am not just talking about application development that ends up in the hands of end-users. End consumer of software like Report Writers, Business Rules Engines, BI software also needs some TLC.

For example, years ago I worked with a Report Writer that in the interest of maximal reuse the vendor decoupled the query from the presentation layer. To make matters worse they stored all the queries for every report in a single file. The production systems I deal with can have up to 1500 reports to manage. They might also have as many as 8-10 staff members that write reports. To further compound this the development environment for writing reports is on each report writers individual Windows workstation. The runtime enviroment is on a Posix server. And, workstation and the server had their own, out of sync version, of that one file that held all the queries. Meaning...

• We (actually, us and our customers) had NO means of keeping that query file in-sync between all the different report writers working on different reports and queries.

• Further they had no means of getting the queries in-sync with that single file on the server.

As a remedy, we created a special tool that took the query from the workstation query file and appended the query file on the server. In the next two releases of their product that we upgraded to they changed their underlying metacode and broke our tool.

• This approach made troubleshooting and support very difficult.

For example, if you wanted to share a report, or open a case for a report you were having trouble with here was the process you needed to go through.

1. Send them the report file (which contained the presentation layer)
2. Cut-n-paste the query from the other file to send to them. You also had to send them the name of the query (case-sensitive) so they to add it to their environment.

I could go on and on. Needless to say we got them to add functionality that coupled the query with the report. But, the real point I wish to make is that the developers lack of understanding of what it takes to support multiple employees writing reports in an operational environment contributed to what was one of the biggest software fiacos I have witnessed in my 20 years in this game.
While that example is extreme it serves to satisfy the old cliche that "you will never understand until you walk a mile in their shoes."
The #1 problem with software today is the inability to gather bullet proof requirements and translate them into killer apps. While there are many, many reasons for this, one is... that it is hard to communicate effectively with someone that has no experience with the boots you have to walk in.

I do apologize if this offended anyone. Though, it does not change my perspective on this matter one iota.