Wednesday, November 26, 2008

The Pyramid of Software Priorities

Ok - so a pyramid is probably the most overused illustration for.....anything...but bear with me...

There are several basic priorities you need to consider when writing software (from a code perspective)... the lower priorities are foundational to the ones above them - if you don't have a priority in place, you have no business even thinking about the next level. Also, I would probably say that the higher up the pyramid you are, the more mature you are as a developer.

So what are they??

Bottom Level: "It Works" - sometimes this is all you need.

One Level Up: "It is Readable" - if your code is to be maintainable - it needs to be readable and quickly the next HUMAN to read it.

Two Levels Up: "It Does Not Inspire Hate" - if that next human not only is able to read your code, but doesn't hate it, you have thrown additional value into the pot -- good job.

Three Levels Up: "It Inspires" - if the next human is able to read, and actually has a positive emotional response to your code - I think you have reached the pinnacle of achievement in software development - you've added the most possible value to those that will follow you, and thus to the software product itself.

So - next time you're building something - consider things from the bottom up....and don't try to skip steps.. the more deliberate and intentional that you are about your coding, the higher up the pyramid you will find yourself.

Monday, October 20, 2008

Cause for Code

So - you get caught up in the day to day, same old routine - things get boring and stale - and sometimes you wonder why it is you do what you do. Coding takes a lot of focus - and like anything else that you have to concentrate on - it can cause you to lose your perspective. So if you're in that place right now - let me remind you why you do what you do......(and it's probably not the millions of dollars, rock-star status, and adoring-obsessive fans).....

This is from "Good To Great" by Jim Collins:

No, those who turn good into great are motivated by a deep creative urge and an inner compulsion for sheer unadulterated excellence for its own sake. Those who build and perpetuate mediocrity, in contrast, are motivated more by the fear of being left behind.

We create - we build... we pull together a myriad of different pieces of technology (most of which are far short of being mature) and piece them into working systems that not only help people accomplish - but often times, inspire and direct that accomplishment.

But take a step back with me....take a deep breath. If you notice in the passage from Collins, he discusses two motivations - which, I believe are both very prevalent in software people - the deep creative urge for excellence, and also a certain level of fear. I think everyone has a measure of both of these drivers threaded through our lives and our work - but the extent to which you can let the drive for excellence defeat fear determines the level of your work, the level of your influence on others, and the level of your own personal enjoyment of your work....(yes, you should enjoy your work - but that's a discussion for another time).

So - hopefully you know about how neat it is to nail the details of a particular system in such a way that you can just look at it and tell that it is solid and well put together. Hopefully, you are hungry for more of that. Hopefully you have that deep creative urge for excellence for its own sake....

Even though you have the hunger for excellence, fear can come into an environment in many ways - and many of us are very familiar with this. It can come from miscommunication with co-workers, being mistreated by a co-worker, or even if you mistreat a co-worker. Though, when you think about things, you can usually trace it back to its origin.

So - what is there to be done? Take responsibility for the situation - make it your mission to remove fear and feed your own hunger for excellence. If there is something that is keeping you from feeling free and empowered to do your work, identify it and deal with it - if it means doing something scary, like confronting someone, or even moreso, finding different working arrangements. Make sure that YOU are putting yourself in an ENVIRONMENT that will allow you to have your hunger for excellence. This is your responsibility - don't pass it off on to someone else.

Friday, August 29, 2008

Software Development Myth #3: My Development Velocity Is Based Solely on Me

One of my managers in the past used to say that every developer has a factor that you multiply his or her development estimates by to get a "more accurate" estimate. Ok, I believe this - some developers tend to be opptimistic in their views of how quickly they can get things done - others tend to be more pessimistic.... I even had a co-worker who thought he gave "more accurate" than other estimates...(yeah, right).... so bottom line is there's a sliding scale that you probably fall on as a developer with regards to how optimistic or pessimistic your estimations are... (I won't try to dive into the psychological reasons for how you arrived there -- anyone else want to take that post? :))

But this manager was only concerned with the developers in his environment (not surprising)... however, there is another factor to enter into the equation - and it relates to the organization - and how a particular developer relates to that organization...... so to simplify - the factor that this manager shared about is not simply to be defined by the estimating practices of the particular developer... but also how the developer works in the larger context of the organization.....

For example - at one job - I thought I had honed my estimation skills - working in a particular environment with small, packaged deliverables, and management focused on keeping hard deadlines... yeah, I could narrow things down to almost every line of code I would have to write to make something happen - not taking into account much back and forth with the folks that were requesting it........definitely easier to estimate, and it definitely pulled me from the "pessimistic" side that I tend to be on........then I worked at another company - where there was a little more back and forth - a little less rigid with regards to my estimates probably bounced a little more toward the pessimistic side, to compensate for that.... and in yet another organization - a massive organization with many, many parties to deal with and negotiate with - I found my estimating to be on the optimistic side....and it shifted to more pessimistic, to compensate for all the challenges bringing pieces together....

I'm sure anyone who's been in the industry for any amount of time has seen similar sort of pattern... but it's something to keep in mind if you have to make a move to another organization....time moves differently in different places..... :) And you don't usually know the arate at which it moves until you have existed in it for a little while..........

Tuesday, August 19, 2008

The .NET Dilemma

So there exists a bit of a dilemma in the .NET world ... having come from the Java world recently, I think I can probably see it a little more clearly than others.... it is this:

you must use only microsoft tooling, even though it is ages behind the rest of the world

Let me give you one of a few real-world examples to kind of explain what I mean -- let's start with the "you must.." part...............I'm currently doing web apps with C#/ASP.NET - and I would have liked to use an MVC framework...HOWEVER, Microsoft's is not done yet - it's on preview 4 or something... so, the other option is to use Spring.NET or another third party MVC framework... the only thing is: I know Microsoft is working on a MVC framework - and when it's done - they'll make sure there are no competitors - that means there's already a ticking clock on the lifetime of Spring.NET and any other third party projects.... so that's the "you must" part - there's really no realistic choice other than to wait for Microsoft's stuff - or just to not worry about your application becoming *legacy* as soon as you write it.....

Ok - next part - ages behind the rest of the world -- that's right - Java (among others) has had MVC frameworks for a number of years now - they're a well understood thing - they're helpful - and darn it they make you more productive..... why is Microsoft JUST now developing something? Who knows - all I know is that it's way behind the times......

Anyway - that's the dilemma in a nutshell - the fact is - the .NET environment works just fine -- but if you want leading edge power and flexibility -- mmm.. I donno... :)

Thursday, August 7, 2008

LINQ to SQL!! Key Conflicts

Ok all - just a cautionary tale... if you see anything similar to the following when working with LINQ to SQL, consider what I'm about to tell you...

"Cannot add an entity with a key that is already in use."
or any other message about conflicts or whatever.....

I've had this problem probably four times, and for some reason, the symptoms still fail to trigger my previous memories.....and btw, there seems to be no tooling around how to figure out what data LINQ is talking about when it makes claims about bad primary keys,etc...(if I'm wrong, please let me know..)

Anyway - I use SQL Server generated identities for rows... and if that is not annotated on the LINQ to SQL generated code, it will not use the generated key - it will assume the key you are giving it is accurate (be it a 0 or null or whatever....)

So just remember this...... it's annoying....and it's probably, overall now, cost me a week of dev time for this project.... BOOOO


Till Next Time...

Thursday, July 17, 2008

Behavior and Rest

So here's an interesting angle (from someone that seems pretty intelligent) concerning one of my main disappointments in the 'rest' approach to web services. That is, the rest approach only encapsulates five possible behaviors (corresponding to the five HTTP verbs). In my mind, any other behavior encapsulation doesn't fit in the rest model. This guy disagrees...and he does so fairly eloquently....

Unfortunately, this doesn't cut it for me - because, you're still not encapsulating any new behavior - your factoring it out into its crud operations, and then doing the behavior in the client code. So - it appears to me that rest is just not really suited to situations where you're actually trying to encapsulate behavior (such as non-trivial business logic)... but it is VERY nice for quickly modeling things that can be thought of as a resource or as a piece of data, that you want to be able to view or modify in a sort of low-level kind of way....this resource-centric approach is probably the best part of rest and would probably fit in well with other modes of web service delivery - but because of this short-coming - probably not a suitable least IMHO. :)

Tuesday, July 15, 2008

We're Not Resources

Why actually blog myself... when everyone else is saying everything.... here's a great post about how insulting and counter-productive it is to manage software engineers as if they were replaceable cogs....let's do like a commentor says, referring to people as "Resources" should be recognized as a bad word in polite, tasteful companies....

Tuesday, July 8, 2008

Code Monkey...

Cute song - definitely got to learn how to play it...

Here are the chords:

Here's a good music video for it:

Thursday, July 3, 2008

Some .NET Hotness: Stack Traces

Check this link out...

Apparently it is possible to programmatically access the various portions of stack traces in C#/.NET -- this is neat, cause in the java world, last time I checked, you had to manually parse the stack trace generated by a Throwable in order to get any kind of an idea where you were in the call stack... so woo hoo -- give it up for MS - this is kinda hot!!

Tuesday, July 1, 2008

Weekly Buzzword: Integration

Ah yes - integration - sounds greek, or latin, or something - sophisticated, no doubt. But what does it really mean?

Well, I would guess it means at least a couple of things.... going back to the theme about how software developers are rigid and talk, think, and dream in 1's and 0's - probably the simple answer would be - integration is just connecting to systems. It's like plugging a plug into a light socket - simple, straight forward - not a lot of room for interpretation.

Ok - let's go back to thinking like human beings again.....the above referenced analogy works.... insofar as you recognize that not only will you be plugging the two things in - you'll be inventing the light socket and the plug from scratch, with less than two napkins worth of drawings to help you along your quest...

So what does this mean in the real world? It means there are shades of grey, dummy. Integration isn't just connecting the two pieces it's fashioning the connectors - if you need to - or maybe reusing partially applicable connectors. At any rate - it's not black and white.

So we have a responsibility here - don't let non-technicals blow it off and say - oh yeah, we're just integrating.... make sure they (or you) think first. Inversely - don't let them say OH MY GOSH WE HAVE TO INTEGRATE - make sure they (or you) think first. After you think - then you have the right to casually blow it off or to get extremely apprehensive - whichever is appropriate.

In FACT - another action item could be taken from this week's buzzword: maybe we should design a few subclasses, revealing a little more information about the actual activity that is taking place in your "integration".

That is all.

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 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 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....

Tuesday, May 6, 2008

LINQ and Other Recent .NET Extensions

I am a recent convert from Java to .NET...(start imperial march music here) ... however, I'm kind of liking it - Microsoft has done some neat things with C# and .NET that have got me really going of the neat things (which has been built on a number of the other neat things) is LINQ...

LINQ (from a Java Programmer's perspective) is a shot at an ORM package that is integrated with the runtime - so no additional packages needed. So that's neat...

But wait, there's more - it also provides a querying syntax / structure that's abstract enough to even be used on standard collections, like arrays, lists, etc.... now that's cool - and it can eliminate a bunch of code when doing simple things like looking for a "User" object with a last name of Smith in a List.....

But one of the coolest features of this thing - is that it is built on all the other neat things that have been released with this environment (see: delegates, lamdas, dynamically typed variables [var], among some other things).... why is this neat - cause if you jump into the LINQ rabbit hole - you will learn a number of other things along the way.....

Here is a GREAT LINQ, er, link.... enjoy:

Weekly Buzzword: MVC

So the software world is filled with buzzwords - that if you don't know them - you are not cool. And thus not a good software developer. Check out this post about MVC - part history lesson, part technical lesson....

Wednesday, April 30, 2008

Buying Real Estate

Ok - so I've gone and sold a house in one state and bought in another - and it's drastically different. Go figure. I don't know if anyone knows about this - but it caught me a little by surprise - fortunately the destination state (Washington) was a bit easier (and more understandable) than the source (New Jersey)...

Monday, April 28, 2008

Half Life of Design Scribbles

So - I believe I've discovered a fundamental law of software design. It will probably take some more laboratory testing, and maybe some peer reviewed research papers....but it goes something like this:

After 1.5 weeks, all design scribbles lose 100% of their meaning.

Corollary 1: if you have any napkins with software design on them for more than 1.5 weeks - you can throw them away.

Corollary 2: you don't have to feel guilty about discarding said scribbles - though if you have a memory file or developer scrap book folder, it might go neatly in there - as it is cool to say, "oh HEY - here is a meaningless drawing from before we even developed this thing".

Friday, April 25, 2008

There's a First For Everything

Let's try this out - what do you say...