*Words of Wisdom From The Elder

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. 

I’m sitting in the Asp.Net tips and tricks sessions given by Scott Guthrie at the CodeMash conference.  Below are some of the items Scott covered.

Visual Studio Tips and Tricks

First up is the web site project model and the web application project model.  Essentially there are two types of web solutions.  One is a web site project which is the default in Visual Studio 2005.  It essentially allows you to store your web site in a folder0. For most content driven sites this is fine but this isn’t what we were use to in VS2003.  The other solution type is a download that was provided after VS2005 was launched.  Those of us that were using VS2003 didn’t like the new way with the App_Code folder and so on.  The web application project download provides developers the ability to get back to the way we were used to in VS2003.  Typically enterprise customers building large scale applications will utilize the web application project model and content sites use the built-in web site project.   There are also tools to migrate between the two projects if you decide to change your solution later on.  Here are the main things the web application project provides:

• All files contained within the project are defined within a project file (as well as the assembly references and other project meta-data settings). Files under the web’s file-system root that are not defined in the project file are not considered part of the web project.
• All code files within the project are compiled into a single assembly that is built and persisted in the \bin directory on each compile.
• The compilation system uses a standard MSBuild based compilation process. This can be extended and customized using standard MSBuild extensibility rules. You can control the build through the property pages, for example, name the output assembly or add pre- and post-build actions.

Optimizing VS 2005 Web Site Build Performance

If you’ve had build performance issues with Asp.Net there are some tricks and reasons why sometimes when you make a small change the entire solution rebuilds.  Instead of me getting into this to deep, Scott already has a lengthy blog article with screen shots that outlines what is happening under-the-hood and how to speed up build times.

Default Button

Since I write mostly in Windows Forms within .Net, this is something I knew but just forgot from lack of using it.  There are times when you have a web page that has multiple buttons on it.  By setting the defaultbutton property of the form tag you can declare which button will have its click event when the user presses the enter button.  This enables developers to identify the default button behavior when the enter key is hit.  It is cross browser and works on all modern browsers.  Without this feature you would have to write the JavaScript on your own.  The <asp:panel> control also supports this.  Here is an example:

<form defaultbutton=”button1″ runat=”server>

<asp:button id=”button1″ runat=”server” />

<asp:panel defaultbutton=”button2″ runat=”server>

<asp:button id=”button2″ runat=”server”/>

</asp:panel>

</form>

How to shift focus

You can write java script to shift focus to a certain input control but in .Net 2.0 you don’t have to.  In .Net 2.0 there is an attribute called defaultfocus which you can set on your form control to automatically shift the focus to the input control.  To take this a step further you can also do this in code: Page.SetFocus(control).

Another way shift focus comes into play is on validation errors.  When you are using the validation controls set the property SetFocusOnError=”true”.  By default it is false for backwards compatibility so it is something you have to set.  Setting it to true it will auto shift to the control throwing the error validation.  Very nice!

Using CSS Adapters

In Asp.net 2.0 the Control Adapter API was introduced which provides alternative rendering of controls.  What this gives you is a hook to modify or override a control’s rendering output.  All events and other things stay the same, but the output of HTML can be altered.  The CSS Adapter Toolkit, which can be downloaded from http://www.asp.net, makes this possible.  For example instead of the menu control outputting tables, it can output a div tag with ul and li tags.  This of course allows a designer to then style the menu as they would want. 

I asked the question if this is going to be baked into the next release of Visual Studio and Scott said it would be, but to what extent he wasn’t sure.  It is an interesting problem to discuss because you have an interesting design experience to overcome in Visual Studio.   While they could change the output of the menu control to display div tags by default it wouldn’t render properly without a style sheet.  While it is a little more work, I think the solution would be for the Asp.Net team to provide a configuration wizard to configure the control, or maybe extend the smart tag.  I would like to see the default option that is rendered from the controls to be all compliant HTML and then just simply switch a property to change the style to A, B, C, D, or Custom.  This is just an initial quick thought but hopefully you see where I am going. 

Register User Controls in web.config

 If you use user controls in your pages you typically have to add the user controls in the top of each page.  If you add this following code below into your web.config file, these controls will be automatically loaded for you and save you this step.  And for the record there is no performance penalty in taking this approach.

 Server Side Comments

If you have ever had a time when you wanted to not render a control in a page you may have just done this:

<!–  <asp:Button runat=”server” id=”button1″ /> –>

Taking this approach is still going to render the button and fire events it is just going to be hidden in the browser.  However, if you really want to remove the control from the page see the sample below.  Doing it this way will just skip this button all together. 

 Other Tips and Javascript Intellisense in Next Version of Visual Studio

 Scott also showed a lot of Ajax tips.  The one take away he mentioned that I didn’t know was the javascript debugger trick.  And while I am thinking about it he also noted that in the next version of Visual Studio code named Orcas, we were going to have full blow javascript intellisense and debugging capability.  No other IDE provides this right now (at least that I am aware of) so this is going to great for those doing lots of Ajax.  Folks, this is HUGE!  

About the debugger trick.  Essentially place this line in your javascript:  debugger;

When you do this the Visual Studio debugger will open to allow you to start a new instance of Visual Studio so you can step into the javascript and also view the contents of variables.