*Words of Wisdom From The Elder

The other day I was playing on my aging Powerbook and thought I’d investigate writing applications on Mac OS X using XCode.  I tried several years ago but honestly after reading some documentation on Apple’s web site I wasn’t any better off than when I started.  Instead of going the documentation route which didn’t work I thought I would try a different approach.  Today we have something we didn’t have years ago that is a lot better than documentation and that is called videos.  They say a picture is worth a 1,000 words.  Well a video is worth that times 1,000.  I jumped over to http://www.youtube.com hoping someone had put up a simple tutorial on how to build a sample application using Objective-C/Cocoa and XCode (Apple’s IDE).  My first search hit the jackpot.

The video I found created a sample Mac OS X application with a button on it that when pressed made a noise.  I expected the video to be a few minutes long but it was close to six minutes long.  Hmm, could it take that long to create a button and make the computer beep?   I watched the video and while I was watching it, my jaw was on the floor at the number of steps the developer had to go through for something as simple as creating a form and making the computer beep when the button on the form was pressed.  There were windows here, windows there, jumping around here and then to there, dragging lines from one window to another and more.  No WONDER I couldn’t figure this out by reading documentation!  For the record, XCode is developed by the same company that everyone praises for being the poster child of usability.

After I watched the video I was like, man, this is horrible and I am really glad I don’t write OS X applications.    I also thought to myself that I could do that same tutorial using .Net and Visual Studio and with A LOT less steps.  I decided to put up or shut up so here is what I did.  I created a video that does the same thing the XCode video does and uploaded it to YouTube.  You can watch both videos below.  I’ve been saying for years Apple doesn’t do anything to provide developers, especially those in the enterprise, a rich programming environment and I think the comparison in these videos drives this point home.   Enjoy!

XCode Tutorial

Visual Studio Tutorial

As a team leader, one of my duties is one of the toughest jobs in the software business and that is communicating where a gigantic project is status wise.   There are entire books written on just how to judge where a project is as well as how to do projections and estimations.  Like everyone else I struggle with guesstimating when something is going to be done.  This is what forced me to change my quote for the blog recently to:

Software is ready to be scheduled for production when the last line of code is written.

While somewhat of a play on words and the truth, almost everyone has trouble communicating statuses of their projects to the business.  As you move up the chain of command it gets even harder.   As you move from Engineer->Team Lead->Director->CIO->CEO the less information is needed. 

At work we’ve been working on a major redesign on one of our core systems.  Not that we built it incorrectly when we built it mind you.  The product has just grown and taken on more responsibility.  Before we took on a huge chunk of extra responsibility we knew we were going to need to restructure a lot of things around.  Things were easy when we first built it.  Several years later the system has grown into a really large system with a lot of integration points and moving parts.  With so many parts and integration points how do you calculate the whole project?  Beyond that how do you show someone where you at without them having to read a 10 page report?  I struggled with this for some time and then stepped back and thought about it for a bit.

What I came up with was a simple one page picture that I put together in PowerPoint to represent all the different pieces and the status of each of those.  As each week progresses I can then easily update the PowerPoint with the new percentages of work that was accomplished.  Here is what I came up with.

After a quick glance of the above image we can easily deduct that our largest body of work on this project is the Core in the services tier.  Second is the user interface and then third is the data migration.  It is important to communicate this to the business.  The reason is it helps to set expectations.  If I told someone at work, “Well we are 60% done with our Core service work.”  To them that might sound great.  But in context it is still only about 40% of the overall work for the services tier that needs to get done and then only about 5-10% of the overall project.   I sent this out to a team member who was not involved with the project but asked how things were going.  The first thing they came back with was, “Wow, I didn’t know the project was that big!”.  I think I accomplished my goals of A) showing all the moving parts of the project B) simplifying the complexity of it and C) minimal reading. 

For those that may be interested in trying this approach out I am attaching the PowerPoint I created.  Feel free to download and use it.  Let me know how your mileage varies with it.  I am still “testing” it out myself.

I was catching up on some reading tonight and came across an article about an ex-employee at Google who filed a law suit because he felt he had been dismissed on unfair grounds.  One of the things noted in the evidence of the case was his colleagues referred to him as “old man”, “old guy” and an “old fuddy-duddy”. 

Reading the comments on the article further down a person named johns had this comment.

Applying to IT companies when you are mid 40’s or above is a real crapshoot. Age discrimination is rampant in IT.

That got me to thinking.  Will I be a fuddy-duddy as I age?  What are some things that I can do to not come across as a fuddy-duddy as I get older?  Is my career in IT really limited to a certain age?  If I have a great job today and then because of changes in life I have to leave that job to find another, will I get re-hired?  Or will I be perceived as an old aging dinosaur that has arthritis and can’t type?

One might think that I’d be thought of as a wiser more experienced person and you’d be right to think that.  Of course with more wisdom comes a higher salary and if I am 45-50 years old how many employers are going to be willing to pay me what I am really worth?  Hmmm.  Could this be why most “consultants” are older?  I mean you really don’t see young self-employed consultants.  Sure there are exclusions to this but in general I can’t think of a young consultant that is self employed.  I use to be a consultant but the difference is I didn’t work for myself. 

What about age 60?  Would you hire a 60 year old IT person?  Would you be willing to take a chance on a guy/lady that is only a few years away from retiring?   It is definitely something for us to think about and keep in mind as we get older.

After thinking about this more I think getting older and whether or not someone will hire the ever aging programmer has to do with perception and personality of that programmer.  Not personal perception, but public perception.  In other words how people perceive you to be.  For example, I would like to think I would never wear shorts with blue dress socks and dress shoes in public as I get older.  I mean how hard is to put on tennis shoes and white socks and present yourself in a more friendly manner that doesn’t come across to someone you have a severe lack of ability to put things together that match?    In my mind I think, “well, if he can’t match his clothes, how can I trust him to match the best technology to solve a problem”. 

 Sure one gets cool points for being different but only from people that also have dress socks and dress shoes on.  In other words everyone else is deducting cool points.  My point is the way we are perceived may have a lot to do with finding employment later on.  Here is another example that may help drive the point home.  It is really no different than the punk rock kid coming into an interview for a wall street position.  He looks like he just fell into a tackle box with more metal attached to his bottom lip than what is in the front axle of my truck.  Sure no one is going to say he was discriminated against during the interview but there is a thing I like to label as personal perception discrimination.  It does exist and just remember you read it here first.  If you don’t believe me, watch how many people feel “uncomfortable” around bikers.  A lot of bikers are nice guys and a lot of them are lawyers, doctors, professionals etc.   But, you can clear a bar in 10 seconds if a crew of bikers pull up.  Why?  Perception.  People perceive them as being bad and causing trouble.  Just as if you look old, are grumpy out of date etc., people are going to perceive you as not worth hiring.  At least that is my theory.

I’ve worked with guys that were older in IT and some seemed young for their age while others seemed old.  I’ve even seen guys that were perceived as being fairly young but the first time they opened their mouth they definitely sounded old.  Even if you don’t come across as an old fogy at first glance, your next point of failure may be when you open your mouth.  We’ve all watched the movie Grumpy Old Men and I’m sure no one would want to work with a grumpy old person.  Yet, as we get older, the trend is for us to get more opinionated.  One can definitely come across as a harsh old bastard who likes to sit around and talk about how he got started in the computer industry on a computer with 1K of memory that he built from scratch out of toothpicks and copper wire.  If there is one thing I’ve learned over the years is the way you sound and treat people is very important.    In other words, no one wants to work with grumpy old bastard programmer who calls everyone young whipper-snapper no matter how good he might be. 

I would like to think this will not be a problem in the future but it will definitely be interesting to go back to this article in the year 2022 when I turn 50 and see what the state of affairs for the older generation programmer holds.  Hopefully those who kept their axes sharp and skills up with the current times will be able to find and keep gainful employment just as easy as they did when they were younger.  Time will tell.

I came to a realization this evening when working on a new release of our internal CRM application.  We are in the middle of re-designing our CRM from the ground up with new data structures and tons of new features.  That may sound like a drastic measure but the functionality of it as well as the scope has changed over the years so that’s why we are redesigning it.  As a result we are taking the time to build our middle-tier using Windows Communication Foundation leveraging the Web Services Software Factory for WCF. 

WCF brings a lot to the table for us such as duplex messages, TCP binary messages and so on.  I’m a big fan of multi-tier design and good architecture design.  You know, the typical  UI->Middle Tier->Database approach.  Anyone that has built an application using three tiered design should know the majority of the work is in the middle-tier and about 70% of your effort is focused in this area. 

For our redesign, in the middle-tier we are following good architectural guidance by creating entities, separated business logic, separated data access and so on (WSSF really helps with this).   At times though I wish I could just drag and drop a database table onto a WinForm, create a strong type dataset and bind to a DataGridView control and totally forget the middle tier.  It sure is faster to code everything in the UI and hit the database directly this is no doubt.  In the end there are tons of draw backs though such as deployment, centralizing business rules, etc.  This is the first case in point that good architecture creates more code and ultimately takes more time.

This evening I was playing around with a test WinForm app for a prototype screen and realized since we are returning entities from the services layer we can’t just bind the returned collection of entities to a DataGridView control and get all the sorting / filtering goodness we get with a Dataset.  In the end I had to write more code to be able to achieve this.  Sure it only turned out to be about 500-750 lines of code that will get re-used over and over and over again, but the fact remains that I had to write more code because I followed a good design practice.  This is case in point number two. 

For those that leverage consultants this is the difference in quotes you probably receive from various firms.  Or for those that ask developers how long something will take and he/she tells you two months when you were hoping they would say two weeks.  Sure you can find someone to get it done faster, but did they get it done correctly?  Will the system be easy to maintain?  Scale?   Be easy to extend in the future?  These are the things that developers over time have come to realize when building systems and it is hard to justify sometime to the business or to clients (if you are a consultant).  Sure it may take a developer longer to follow a good three tiered approach, but the business gets a lot of benefit down the road by going with a better architecture.   

Ayende wrote a post about Acropolis as another executable XML language.  Then a few other people chimed in on comments about Acropolis being another example of Microsoft providing tools to turn bad developers into mediocre developers.  I think the point of Acropolis has been totally lost in this conversation so please allow me to weigh in.

To start with WPF is already expressed in XML.  This has been known for awhile and we’ve all seen amazing results of expressing the UI declaratively.  Look at all the eye candy WPF and Silverlight has dazzled us with over the past several months as an example.  Acropolis is simply leveraging the new WPF stack so to call it an executable XML language is a little far fetched.  Of course it is true that XAML generated to display WPF applications is in XML format but it isn’t a language it is merely parsed.  Calling Acropolis an executable XML language is like calling a component or control that ships out the box with the framework a language because that is what Acropolis is, additional controls that are going to be shipping to enhance WPF which in return will help us composite our client applications better.  

Acropolis isn’t a language but merely an extension of controls and patterns to WPF similar to the Smart Client Software Factory and CAB built leveraging the richness of Windows Presentation Foundation.   That is the Forrest Gump definition of how I would explain it.

We’ve already seen and tried to solve a lot of the problems developers face in building rich client applications with SCSF and CAB.  Acropolis is no different in what it is trying to solve just in how it is put together.  Meaning Acropolis is built on the WPF stack rather than built on object oriented design patterns.  Under the hood there are design patterns going on I am sure but they are abstracted to controls. 

To give you an analogy here is how I would think about it.  To me it is no different than Asp.Net 2.0 shipping the Login controls.  This is an example of a common problem web developers face and an abstract way of dealing with that problem.  Acropolis to me is no different in the fact that there are inherent things as client developers we have to do each and every time we start a client application.  Acropolis will hopefully help us solve these problems, but it isn’t a new XML language.  It also has nothing to do making bad developers mediocre developers as one commenter pointed out.  Just as the login control bundled with Asp.Net 2.0 didn’t make bad developers mediocre developers.

The point of Acropolis is to take things that are “common” that client developers have to do and abstract the repetitiveness of building composite applications into something that can be reused in the framework.   As Brad Abrams pointed out in his comment there is still separation of code and business logic. 

I saw at lengthy talk on Acropolis at TechEd done by Kathy Kam and mostly what I saw was a set of new controls that will assist client developers in building out the plumbing of smart client applications faster.  It is still new but the direction it is going will in my opinion solve what it is trying to solve if done correctly.