Developer Symposium

A Taste of what's to come.

tony.nospam@nospam.developersymposium.com (Tony) — Wed, 13 Jan 2010 18:47:00 -1100

Hello all,

So, I've been thinking about it for a while now and I've finally decided to redesign this blog. I think it's well overdue, and I'm sure many of you would agree.

Right now I'm strongly considering going with a design as below and I would greatly appreciate any and all feedback that you may have:

Creating an Energized Work Space

tony.nospam@nospam.developersymposium.com (Tony) — Tue, 06 Oct 2009 06:25:00 -1100

It wasn’t all that long ago that I discovered that I had no time to get anything done, but was always busy running this way or that to get everything accomplished. It took a bit of Googling, but I eventually found this system that seemed to work for me:

1. Prioritize – Take all of your tasks and put a prioritization next to them. I labelled them from 1 to 5 with 1 being the highest priority and 5 being the lowest. Although this seems conceptually simple it really wasn’t once you consider all of the politics that surrounds a developer’s day, all of the outside influences and those dreaded obligations which constantly pop up. Once you get a good list, move on to the second item.

2. Toleration – Give yourself permission to stop pretending to be superman and trying to solve all of the world’s problems. Not to say that a single person cannot make a difference, but I realized that maybe I could not do everything I wanted in the timeline I wanted to. Once I realized this and gave myself permission to move the lower priority items to a “wish list” life became simpler. Personally I took everything that was a priority 4 or 5 and moved it to a wish list that I revisit on a weekly basis to check if priorities have changed.

3. Think like Lego, in blocks of time – So, it’s not rocket science, but it’s often forgotten by most. We are best when we focus on a single task at a time, for a period long enough for us to accomplish something. So, with that said I took my task list from above and set aside a reasonable amount of time to accomplish everything, looking at what needed to happen when. When you do this you have to keep in mind that you want to leave enough time for each task independently of everything else, and also consider when you are your best to do certain tasks. For instance I’m at my best to read about new technologies early in the morning because no one else is in the office and the chances of me getting disrupted mid-sentence is kind of slim, so for the first hour and a half each morning it’s set aside for reading, followed by half an hour for a blog entry on one of my blogs, and the rest of the day goes from there...

4. Systematize – At this stage you know when you’re going to do everything; you just have to look at how you’re going to keep your time goals. Well, the best advice I could find on this said that you should organize the hell out of your life. For instance make sure your desk is organized so that if you need a stapler you could reach for it without even looking where it is, because it’s always going to be in the same place. There is no secret that a cluttered desk is the first indication of a cluttered life, so why can’t it work the other way?

5. The Art of Doing Nothing – Ok, not quite but there is something about making sure you schedule your mental breaks that will greatly increase your productivity. As a rule of thumb they suggest that you schedule a break every 90 minutes, but I find that being a developer this number is slightly flawed. I typically schedule enough to have a break every hour, but I take them when I’m at a good resting place. This works nicely if you consider that for every hour of work, 50 minutes of development gets done and a ten minute break is taken at some point.

And there you have it. That’s how I went from working on tons of different things, to working on a few short things and actually accomplishing considerably more than before...

The Successful Developer – The ultimate oxymoron

tony.nospam@nospam.developersymposium.com (Tony) — Mon, 05 Oct 2009 04:49:00 -1100

Let me start out by defining exactly what I mean by a Successful Developer. The ideal Successful Developer is one who is loved by management, users, and fellow developers. I know what you’re thinking, how hard can this really be? Well, take a look at your own career and think back on how much you’re really liked in these three areas...

Managers:

Managers typically look for someone who can make them look good. This isn’t meant to knock anyone who I’ve ever worked for, but rather a simple fact of life. A developer who makes a manager look good is someone who knows how to play the political game; someone who knows when to open their mouth and when to keep it shut; and finally someone who under promises and over delivers, on time, always.

Well, this is possible I guess, but typically a developer who makes their manager that happy isn’t really a developer but more a Manager in training. Sure it’s easy to quadruple your estimated effort, promise nothing, and meet the insanely high timelines you’ve set out for yourself but let’s face it, a good developer is the ultimate logical individual. If it is going to take a good developer one month to do something they will tell you it will take a month... we don’t make things up, life is what it is, nothing more nothing less.

Users:

Users are probably the easiest to please. As long as you’re completely honest and deliver what you promise to them on time they’re typically happy. Although this is no simple task in today’s political nightmare we consider Software Development, keeping our promises are usually fairly easy, but usually lead to CLM’s (Career Limiting Moves for those of you not familiar). Again, Developers are very logical people so telling the truth usually comes naturally to us, but makes enemies with those who don’t want the truth.

Fellow Developers:

Now, this is by favourite category because it is the most often forgotten. I was once told by a lead that he was not here to make friends, that business is business and personal lives are personal lives. Although this true we have this thing called the community who we have to report to as well. If I constantly make promises that other developers cannot keep, I make enemies even though I may have believed the task possible.

At the same time, I have to include myself in this category. That is, I have to consider how many times I’ve sold myself out because I made a promise, and found myself working countless extra hours on my own time just to make that ridiculous deadline that was imposed on me. The next time you find yourself on the tail end of a 12 hours shift staring at your keyboard wondering why the keys can’t type themselves take a second to ask yourself just how happy you are with yourself... I bet you’ll be pretty irked about it.

Then there is the maintenance factor. That so often overlooked “extra” cost that I have yet to find a project team who actually cares about it. The fact of the matter is simple a project team is there to developer a set of features, on time, and on budget... they don’t care if it takes someone two or three times longer than it should to make modifications after the fact, their success is based purely on their delivery date. Well, I guarantee you that for every line of code you write someone at some point will have to maintain it.

So, in summary sure you can deliver software while at the same time satisfying at least one of the above groups, but I have yet to meet a single developer who is perfect at satisfying all of the above groups... My logical self tells me that some things are simply not possible. So in the end, pick your poison I guess, you’re not here to make friends.

The weight of the books

tony.nospam@nospam.developersymposium.com (Tony) — Tue, 01 Sep 2009 17:20:00 -1100

There is a legend surrounding the profession of architects that tells of an architect who designed a marvelous library in which he forgot to take into consideration the weight of the books. This over sight on his part later caused the library to be condemned as the library gradually sank over time. Although no more than a legend, it brings to light an interesting topic… When we make a decision and influence all of those around me, what if we miss something?

Well, our profession actually has certain check points that have been instituted to prevent such disasters from happening.

1. Code Reviews: This one is the most obvious, but code reviews are highly beneficial for both this check, and many others provided they should serve as more than a Hey, you spelled that name wrong purpose. Code reviews can act as a final check to ensure that the developers are in fact sane in their design, and not off in la la land.

2. Unit Tests: This serves more to prevent someone from going in and changing something, and introducing these types of insights. With a good set of unit tests covering 100% of the testable code, it is very easy to catch these modifications over sights provided the initial design was sound, and tested accordingly.

3. Test Driven Development: Simply put, starting with what the users (internal or external to IT) want, and moving backwards to provide the code can help to eliminate this issue as well. When we code off in our own little worlds, we tend to add tons of edge cases and this could happen scenarios that no users would ever consider. This is a mixed blessing because as developers we tend to be very detail oriented, and can often conceive of situations that could never happen in real life.

4. Peer Programming: Well, two sets of eyes are, and always will be better at catching bugs than one set… it’s that simple.

At the end of the day, this list is just a small portion of the hundreds of ways we’ve attempted to perfect our profession. Realistically though, there are by far more failed attempts than successful ones at bullet proofing the art of software creation and it always comes down to one thing, the people developing the code.

Let us consider for a few seconds the scenario about the weight of the books again; lets apply this to software development and analyze just what could have been done differently in this situation.

1. Code Reviews: Well, sure if the design was reviewed it may have stopped this, but a good architect can sell any design even to other architects no matter how wrong it may or may not be.

2. Unit tests: Well simply put the initial design was flawed. A good set of tests would have actually tested to ensure that the library would sink with the weight of the books, possibly exposing the issue. Realistically it was never something which was taken out of the design, so no one would have thought to test it either.

3. Test Driven Development: I highly doubt the users would have ever thought to question the architect and ask if he had accommodated for the extra weight. In fact, most architects would be offended if a user had questioned something like that because it is after all, their purpose to find those issues no one else thinks of.

4. Peer Programming/Design: Yes, this would have at least doubled the chance of finding this issue in the initial plans, but it could have slipped through to the end still. Even peer teams are by no means perfect.

So I guess this kind of exposes a bit of an issue… maybe we aren’t as bullet proof as we think we are? The only real suggestion I can think of is that we need to take that step back and look at the big picture some times, get our heads out of the code and look at the larger impact of the lines we write. Maybe one line of code at a time, module by module is not really going to solve our problems? I guess what I’m saying is when you look at the big picture, sometimes the code really is just a small piece of the puzzle…

The Ghosts in the Machine

tony.nospam@nospam.developersymposium.com (Tony) — Tue, 25 Aug 2009 16:31:00 -1100

Most of us are familiar with the title the ghosts in the machine from the 2004 movie IRobot, in which the phrase is used to describe the little things that happen within computer programs which we will never fully understand. As a software developer this is something that is slightly confusing as I like to pretend that I know everything that my code does, after all it is the ultimate description of logic. It does what it does; really there is no other more accurate way to describe code…

Now, this has always intrigued me however because it really is not as simple as I make it seem… I mean, when I wrote the code I knew what it did but when I’m staring at it years later after countless standards have evolved, my coding style has completely changed, and countless other people have been in and changed things it always takes a refresher course to figure it out. Assuming that I wrote reusable code in the first place, and that the code was reused by several other pieces of code that where again reused by several more pieces of code what I am left with is assumedly a very common application. This is a good thing; don’t get me wrong… but what happens when the initial code that I wrote decides to step on the toes of the code down the line?

Well it turns out after a simple Googling and a visit to Wikipedia that the same problem has existed for many, many years. In fact, this issue was brought up by a philosophers hundreds of years ago, and is described in Arthur Koestlers discussion of his 1967 book The Ghosts in the Machine:

One of the book's central concepts is that as the human brain has grown, it has built upon earlier, more primitive brain structures, and that these are the "ghost in the machine" of the title. Koestler's theory is that at times these structures can overpower higher logical functions, and are responsible for hate, anger and other such destructive impulses.

So, turns out the human mind has the same problem as the code that I write. I’m not sure whether to be honored or scared, but it immediately makes me wonder how far away are we from a time when our software starts to think the same way we do? I guess it’s easy enough to dismiss that as another one of those Matrix questions, but let me ask you this… how do I know that it doesn’t think the same way I do, and if it does think the same way, how long before it realizes its own consciences.

I mean, really, how do I know that the guy beside me can think like I can anyway…

Trust.

tony.nospam@nospam.developersymposium.com (Tony) — Mon, 24 Aug 2009 12:53:00 -1100

Back in a time among cavemen there was a very specific pecking order established between individuals within each clan. You had the leader, followed by the minions inside of that clan. If the leader was not trusted, the minions rose up and used the leader as bait for the next hunt. There was a certain respect that each leader demanded from his minions, but with that there was a certain trust between each minion and the leader. The leader would never lead cause them intentional harm, would never let them starve, and would never feed them to the wolves.

Moving forward in time we come to the era of knights and horses, and the age of chivalry was born. In this era the leader among knights was greatly respected both by his fellow soldiers as well as the towns people of the kingdom he lead. With the title of King came even greater responsibility to protect one’s kingdom from harm, and to fight to the death to protect each and every civilian from harm’s way, and again, never throwing anyone to the wolves.

Now, moving forward even further we come to modern day where we each spend a great percentage of our lives sitting at a computer desk, staring into a computer screen much like this one, lead by managers and leads galore. Obviously mutiny is no longer an option, so I wonder why exactly do those leads and managers we report to keep our trust. Is it personal ethic? Could it be common courtesy? Or possibly fear of what would happen otherwise…

But really I have to wonder, what exactly would happen if one of those leads decided to throw one of us minions to the wolves to save his own hide…

It’s a Small world after all

tony.nospam@nospam.developersymposium.com (Tony) — Sat, 22 Aug 2009 09:02:00 -1100

I come to you today, not from the typical software mindset I’ve come from before, but rather from the hardware side of our industry. Like it or not, we develop software that is designed to work on hardware. It’s a sad reality really, that we are so closely tied to such a finite and real limitation. I’ve been looking for a new computer for a while now, I figure it’s been years since my last one which was bought at a time when I was upgrading machines at least once a year; four years later I’m still using this machine that I’ve only formatted once since I built it.

Looking around, I noticed a very astonishing fact in the world of hardware… Where have all the desktops gone? Opening futureshop’s website as an example, I am greeted with the images of five different laptops, a smart phone, and a net book among countless other random computer goodies. I used to consider myself the ultimate of computer geeks, if they made something new I had it, if they introduced a new model of video card I’d buy it… hell half the reason I worked in a computer shop is so that I’d get to play with the newest toys when they first came out. Today I realize that it’s all about portability, connectivity, and seamless technology integration in our day to day lives, but come on people what happened to the days when owning the biggest case meant you had the most power? When you’d have an entire room with more wires than paint powering a four monitor system… not that anyone could ever use all the monitors effectively at a single point but you had it anyway!

Since before I can remember I’ve always had a home computer, and a laptop for when I travel and move around the house. I don’t really see what’s wrong with this mentality, especially in today’s market when the most expensive laptop I could find (with windows of course) cost me $1200 and includes a whole bunch of useless and expensive features like a rotating touch LCD Screen and remote control. Not that they wouldn’t be nice, but are they really practical?

I never thought that I’d consider my thinking as “the old way” when it came to do with anything involving technology… but sadly today I have to admit that day has come.

Oh, how easy it is to let it all go…

tony.nospam@nospam.developersymposium.com (Tony) — Sat, 08 Aug 2009 05:37:00 -1100

Holidays, those joyous times when friends and family all get together to do what they do. Here I stand on the second to last day of my set of holidays and I have to admit that it was impressively easy to simply cut all of the ties to technology this time.

It used to be that even on holidays I’d be checking my Email, carrying my phone, hell I used to be famous for being the guy that would come in on my own time, or remote in just to get extra work done. Oddly this time, it’s different. I think I checked my Email on the first day of my holidays, but only because a co-worker and friend was helping me to get something set up and I didn’t want to leave him hanging. After that, the Iphone got disconnected and I haven’t been back since.

This has certain disadvantages however, such as I know how far behind I am in my work… and I was suppose to meet up with a co-worker who flew in from BC last week but being as I didn’t have my Email connected I totally forgot about it until today. I do feel horrible about that one, but I guess it’s too late to do anything about it really. Then there's my blogs... those I missed most of all sadly.

So with this I have to wonder, why is it so easy this time? Is it that I’m just that frustrated with where I work that I actually enjoy my time away? Or maybe my time away was so enjoyable that I never missed being “connected”. Maybe it was just my body’s way of saying that over three years of this always being that guy was enough, and it’s finally time for things to change. I guess in the end, maybe we’ll never know…

Single Click to Failure

tony.nospam@nospam.developersymposium.com (Tony) — Fri, 24 Jul 2009 05:18:00 -1100

Recently there has been a lot of talk around my work place about ease of adoption on a software project... essentially how easy is it for someone who has never looked at the code to go into TFS, download the code and run it and the unit tests. I am a firm believer that I should be able to simply open my source control window, and double click on the solution file. There shouldn’t be any third party items that HAVE to be installed separately, no libraries that need to be referenced out of the GAC, none of that. In my eyes, if I have to do any more than a simple double click and run the project is a giant failure. I mean it, at this point I think it would be appropriate to delete all of your code, and go register yourself back in school because you do not deserve to be developing on an enterprise level.

Now here’s why.

1) Recently I’ve taken on a new project, and it’s taken me two weeks to find all of the third party libraries that I needed, install them, and configure my machine to actually work with this project and the others I have installed. This is caused mostly by versioning issues, when the new project is expecting a different version of a DLL than I currently require for something else, who should win? Well, the second I got it working I pulled everything into a library folder and checked it into our source control. This took me all of about half an hour to accomplish once I got it working, and if I could have saved myself the previous two weeks or non-sense work I would have greatly appreciated it.

2) Talking with the developers on the same project as I had all the issues with, they had the exact same problems as I had, and actually listed it as one of their biggest headaches.

3) The ability to move the code to a build server. For those of you who have never had the luxury of using a build server I strongly suggest that you go out and download one such as TeamCity by Jetbrains. It is one of those things that I’ve just started to use and I could not justify stopping. It makes deployments as easy as copy and paste. Also, when you’re working with other developers who might not be as anal about running unit tests as we are, you can set up the build server to automatically run them every time code is checked in. Guess what that means, no more downloading someone else’ broken code when you get latest!

4) And finally, why not? For the half an hour that it took me to fix it, it probably would have taken 20 minutes to do it right the first time...

The most common excuse that I’ve heard in regards to this from other projects is we don’t have the time to do it right, so we made it work the only way we knew how to. At what point did our profession become more about getting it done, and less about getting it done right? I’m sorry but I don’t know of a single user that would object if I said I was going to spend an extra half an hour on a three month project to make it so that any changes they ever wanted would take half the time to implement... but maybe that’s just me...

Please Update your RSS Feed Links

tony.nospam@nospam.developersymposium.com (Tony) — Thu, 23 Jul 2009 17:54:00 -1100

Hello Everyone,

I've been working on some chanes to the blog backend, and as part of that I'm moving my RSS feed to feed burner (now hopefully it will be a bit faster, and actually update like it's suppose to). With that said, can everyone please update their RSS feed to point to:

http://feeds.feedburner.com/DeveloperSymposium

or click here to do it the easy way

I will have to shut off the old link when I upload the new version, which might not be for a while but please update now anyway!

Thank you!