On a recent project I investigated using the ASP.Wizard control to manage a simple page flow scenario. The site needed to comply with local government web guidelines and so the extensive use of tables and nested tables would have been an issue. So I experimented with how difficult it would be to write a CSS Adapter to output <div> tags instead.

After googling for a while it was apparent that a few people were asking about it but I couldn't find an example of anyone who had fully nailed it.

By default the wizard control renders to something like this.

<table cellspacing="0" cellpadding="0" border="0" id="Table1" style="border-collapse: collapse;">

    <tr>

        <td style="height: 100%;">

            <table id="Table2" cellspacing="0" border="0" style="border-collapse: collapse;">

                <tr>

                    <td><a id="A1" href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl00$SideBarButton','')">Start Here</a></td>

                </tr>

                <tr>

                    <td style="font-weight: bold;"><a id="A2" href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl01$SideBarButton','')">Step 1</a></td>

                </tr>

                <tr>

                    <td><a id="A3" href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl02$SideBarButton','')">Step 2</a></td>

                </tr>

                <tr>

                    <td><a id="planWizard_SideBarContainer_SideBarList_ctl03_SideBarButton" href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl03$SideBarButton','')">The End</a></td>

                </tr>

            </table>

        </td>

        <td style="height: 100%;">

            <table cellspacing="0" cellpadding="0" border="0" style="height: 100%; width: 100%; border-collapse: collapse;">

                <tr>

                    <td>

                        Wizard Header

                    </td>

                </tr>

                <tr style="height: 100%;">

                    <td>

                        <h1>

                            Step 1</h1>

                    </td>

                </tr>

                <tr>

                    <td align="right">

                        <table cellspacing="5" cellpadding="5" border="0">

                            <tr>

                                <td align="right">

                                    <input type="submit" name="planWizard$StepNavigationTemplateContainerID$StepPreviousButton"

                                        value="Previous" id="planWizard_StepNavigationTemplateContainerID_StepPreviousButton" />

                                </td>

                                <td align="right">

                                    <input type="submit" name="planWizard$StepNavigationTemplateContainerID$StepNextButton"

                                        value="Next" id="planWizard_StepNavigationTemplateContainerID_StepNextButton" />

                                </td>

                                <td align="right">

                                    <input type="submit" name="planWizard$StepNavigationTemplateContainerID$CancelButton"

                                        value="Cancel" id="planWizard_StepNavigationTemplateContainerID_CancelButton" />

                                </td>

                            </tr>

                        </table>

                    </td>

                </tr>

            </table>

        </td>

    </tr>

</table>

What I wanted was something like this.

<div class="wizard" id="planWizard">

    <div class="sidebar" id="planWizard">

        <a href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl00$SideBarButton','')" id="planWizard_SideBarContainer_SideBarList_ctl00_SideBarButton">Start Here</a>

        <a class="active" href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl01$SideBarButton','')" id="planWizard_SideBarContainer_SideBarList_ctl01_SideBarButton">Step 1</a>

        <a href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl02$SideBarButton','')" id="planWizard_SideBarContainer_SideBarList_ctl02_SideBarButton">Step 2</a>

        <a href="javascript:__doPostBack('planWizard$SideBarContainer$SideBarList$ctl03$SideBarButton','')" id="planWizard_SideBarContainer_SideBarList_ctl03_SideBarButton">The End</a>

    </div>

    <div class="header" id="planWizard">

        Wizard Header

    </div>

    <div class="step" id="planWizard">

        </h1>Step 1</h1>            

    </div>

    <div class="nav" id="planWizard">

        <input type="submit" value="Previous" id="planWizard_StepNavigationTemplateContainerID_StepPreviousButton" name="planWizard$StepNavigationTemplateContainerID$StepPreviousButton" />

        <input type="submit" value="Next" id="planWizard_StepNavigationTemplateContainerID_StepNextButton" name="planWizard$StepNavigationTemplateContainerID$StepNextButton" />

        <input type="submit" value="Cancel" id="planWizard_StepNavigationTemplateContainerID_CancelButton" name="planWizard$StepNavigationTemplateContainerID$CancelButton" />

    </div>

</div>

And that's exactly what my adapter does.

Then using only CSS styling you can control its layout and styles.

You'll need to download the CSS Friendly Control Adapters project from CodePlex first. Then download this zip file. It contains the class, WizardAdapter.cs and an example stylesheet, styles.css, that gives you an idea of the way in which you can style your wizard control using CSS.

Note that the adapter ignores all style information you might add to the control - this is deliberate and an attempt to ensure users make use of CSS for this purpose rather than the embedded styles favoured by the ASP.NET controls.

It was interesting listening to David Laribee, Jeremy D. Miller, and Chad Myers on the recent podcast on Continuous Improvement and as a Development Manager I thought I'd respond to a comment about the Management Crisis.

Not sure which of the panel used this expression but they were referring to their perception that a lot of managers are not interested in maintainability or quality and are prepared to have to re-write software every three years if required. My gut feeling to this comment was,

The crisis is not with management but with those trying to convince them there is a better way

Now before you get the flame-throwers out let me explain.

Both Managers and ALT.NET'ers share a common goal (surprise!)- to (continually) improve the way we deliver software. That's right! The problem is that each has their own ideas about what constitutes good delivery.

You can see the trend, Managers are motivated by the here and now while a great deal of the practices and patterns of the ALT.NET movement are designed, in part, for the future - build it well now and you'll have a more maintainable, supportable product going forward.

And that is the fundamental challenge to convincing your managers that there may be a better way.

You can measure the cost of writing additional code (unit tests, mocking objects, layers of abstraction...) but you can not easily measure the predicted benefits (improved maintainability, consistency, supportability, robustness...)

And that's why managers will say "no".

So what do you do? I think the secret is to use stealth!

Most managers (but not me!) have no idea what goes in to creating software and the complexities and challenges you face day to day. It's all a black box to them - and what's more they think it's all pretty easy. There's a reason people call us code monkeys. Further, if you ask most managers - "can I spend extra time writing and maintaining a suite of unit tests because in the long run it will save us time..." - they will say no. There is a deadline looming and you don't have any extra time buddy. So my advice (and don't tell my boss) - don't tell your manager or project manager. Just do it. If you're so convinced it is going to make things better - and by better I mean, you'll still make your deadlines but you'll have a better solution at the end of it - then go for it. After a few months of gradually introducing better development practices into the team there should be some tangible improvements in the project successes. If not, then you need to revisit whether the practices you are employing are really making a difference.

So that's my advice - don't make a song and dance about changing the way we write software. Managers didn't know how you were writing software before and they're not going to know if you do it differently now. What's important is that you, your manager and the client are all happy with the results.

Good news though - there is a work-around... read on.

A great new feature in 7.1 was the ability to add formatted text to the notes of diagrams and other elements.

However, I noticed that when you generate RTF documentation for the diagram the formatting appeared in the document but when you examined the diagram properties again you lost the formatting.

Very irritating!

But fear not, there is a work around!

Before you generate the RTF documentation close all diagram windows and your formatting will be preserved!

I reported the bug to Sparx Systems so hopefully we'll see a patch for it soon.

Yesterday I woke up with a great idea. Hey, why don't I write some code to automatically populate my Blogroll from my subscriptions in Google Reader. It was a pain keeping them in synch and my blog quickly became out of date as I updated by Google Reader subscriptions.

So I googled for "Google Reader API", found this in CodePlex and thought, great away we go. Sure, I'd have to integrate some code into my SubText blog but it was all do-able. The only real issue was that the code needed to know my Google username/password to access my subscriptions. This clearly wasn't ideal and it got me thinking there must be a better way.

Any so we come to the moral of this story.

If you wake up with a great idea remember someone else probably had it months ago and has already solved it.

And so it was. Near the end of last year Google addressed this very requirement. It was all possible without me having to write a single line of code. All I had to do was add some javascript to one of my web pages. Nice.

Browse to Google Reader and select "Manage Subscriptions". Add each subscription that you want to appear on your blog to a single folder (for example, PublicBlogRoll, in my case)

Now, there is a bit of confusion within Google Reader as to what the difference between a Tag and a Folder is. Officially you Tag posts and you group subscriptions into Folders. Having said this, you will still see you Folders appear under the Tag tab.

And check it out - you get to a link to add a blogroll to your site. The link will take you to another page that shows you the javascript you can add to your site.

For SubText users - you can add this to the PageTemplate.ascx file of your skin.

If you read my recent post that asked the question, Do You Really Want to Be a Development Team Leader and weren't completely put off by the idea then this post is for you.

As Development Manager to a team of incredibly motivated and talented individuals I often have conversations that begin,

Hey Tokes, I really want to move my career to the next step and want to know what I can do to become a Development Team Leader.

My response,

Act like one!

That's right, it's that simple. Wherever possible take it upon yourself to assume some of the tasks that would normally be expected of a DTL. The more DTL skills you display the more likely others will see you in that light and give you the opportunity to perform the role for real. Whatever you do, don't sit quietly behind your desk with the headphones on and expect someone to recognise your leadership potential and tap you on the shoulder - it won't happen. Similarly don't assume that because you're a technical genius that becoming a DTL is the natural next step in your career or something you deserve in recognition of your talents. The skills of a DTL go beyond the technical and require you to have other skills like great communication, the ability to delegate, confidence, being level headed, acting in a professionalism manner...

So what can you do I hear you ask? You're only a developer, right? Wrong, the act of developing is only part of what you have to offer.

Let it Be Known - it seems obvious but you should let your manager/PM/peers or anyone else who will listen that you want to become a DTL. Don't be a nag about it but just plant the seed in people's minds.

Understand the Big Picture - one of the big differences between a good developer and a great one is their ability (or interest) to understand the big picture. They understand the business goals and pain points the system is addressing. They understand the entire solution, not just their part of it. They understand how the code they are writing benefits the client and the solution as a whole. They understand the client and what is important to them. They understand that the code is a means to an end and that project success will be primarily measured by client satisfaction.

Ask Questions - I love working with people who ask questions. It shows you are attempting to understand things thoroughly. It shows you're not afraid to question why something is being done in a certain way. It show's, that as a DTL, I'm not the only one thinking things through and that there's more chance the team is on the right track. Understanding the Big Picture is crucial to being able to ask the right questions.

Don't Wait to Be Asked - while you should always be on top of the tasks delegated to you, don't stop there. Be hungry like a wolf, hunting out ways in which you can add value, help others and identify issues. Do not wait for your own DTL to ask you to do something, try and always be one step ahead without, of course, second guessing their authority.

Be Approachable - DTL's are often the go-to guys (or gals) but they're also pulled away from the team to attend meetings etc. Be approachable (i.e. take off the headphones now and then!) and aim to be the one people seek out when the DTL's away - this is a great sign that you have the respect of the team. If you're doing the things above this will be a natural consequence and shouldn't require you to do anything specific.

Stay Calm - what was it that Mr Kipling said? "If you can keep your head when all about you Are losing theirs... you'll be a DTL my son!". Software development can be a stressful business. Look around at DTL's you respect - guaranteed they will be the level headed ones, the ones that don't let the pressure get the better of them (or at least are good at hiding it!)

So there you have it. It's not a recipe, and there are no guarantees, but start acting like a DTL now you'll be well on your way to becoming one.

At the first ever New Zealand Enterprise Architect User Group Ken Harkin (Business Development Manaqer for Sparx Systems in Australia) announced the establishment of Sparx Systems New Zealand.

Good news for anyone using EA wanting some local support or information. For more information check this out.

Ask any up and coming developer what they would like to do in the next year or so and you'll invariably hear,

I'd like to become a Development Team Leader

Hopefully most will have actually considered the change of role and be looking for new challenges and ways to contribute more to their chosen profession. However, for some this is an automatic response to a question that is particularly difficult to answer in an industry with no clear career path. For others it's simply a way to move up the pay scale.

Before you start talking to your manager or applying for your next job it's worth considering what you're getting yourself into. Depending on where you work there will be different definitions of a Development Team Leader (DTL). To put this post in perspective this is my interpretation,

A Development Team Leader is someone who owns the technical delivery of a solution. They need to understand the business drivers behind the project and be able to lead a team of Developers to realise these drivers in working software.They are (IMHO) the central player in a project team and need to maintain excellent communication with all members of the team from Client to Developers and everyone in between.

I tend to distinguish between what I call a Senior Developer (SD) and a DTL. A SD is someone who still does the tasks of a developer but does them really well and has lots of experience. They don't tend to have the added responsibilities of a DTL. DTL's often (but not necessarily) have a SD background.

Assuming you're a developer this is what I reckon your job entails.

Let's face it the life of your average developer is focused around cutting code. Sure you might have daily Scrums or other team meetings to attend but your main focus is writing software. And you love it!

When you become a DTL you work balance is up for a bit of a change.

Other than the coding slice don't place to much attention on the relative weights of the pie slices - suffice to say you won't be zoning out for 8 hours a day to your favourite tunes - you're the one that gets interrupted, you're the one putting out the fires and making sure the wheels are oiled. Your head is on the line if the solution doesn't meet expectations or is delivered late. You have some responsibilities and influence now.

• Coding - don't worry, you still get to practice your craft but just not as much as you used to. There are now lots of other things that you need to be involved in too.
• Documentation - even with the increasing popularity of Agile methodologies and a move away from excessive documentation there are still times when (technical) documentation is necessary - and guess what? You will be first in line to do it.
• Meetings - if you thought you were in lots of meetings as a developer then you ain't seen nothing yet. Depending on the size of the project you are involved in you will be the main participant in a wide variety of meetings. Whether it's a meeting with the client, the delivery team, the PM, you are the one with the most knowledge of both the requirements and the implementation of the solution.
• Communications - beyond official meetings you will also be heavily involved with communicating to others via emails, issue tracking software, the phone and face to face catch ups on progress. It's a bit of a cliche but good communication skills really are the key to succeeding in many professions - and for any leadership role it's essential.
• Delegation - because of your other duties it's an essential part of your role to be able to delegate work to others. Someone once told me that the job of the DTL is to make themselves redundant - an apparent contradiction to your pivotal role on the project but one that sums up the responsibility you have to ensure the project moves forward even when you can't personally be there to solve an issue. The more you delegate responsibility to others in your team the more involved and productive they become. Don't try and do everything yourself.
• Mentoring - part of reason for delegating tasks to others is to provide them with opportunities for personal growth and development. Mentoring carries this idea further and is a key part of your role. No-one is an island and you must be prepared to share your knowledge with others. As an aside you should also be prepared to learn from your team - DTL's who think they know it all are usually wrong and always disruptive to the morale and effectiveness of the team.

The point I'm trying to make is that if you love sitting in front of a computer coding up a storm with your headphones on then becoming a DTL may not be where you want to go. However, if you're someone who loves being involved in the entire SDLC, has strong communication skills and enjoys the responsibility of owning the delivery of a solution then sign up now.

While at Intergen I have had the opportunity to interview a lot of prospective developers. In that time I have come to understand more clearly what it is that impresses me most. And it might not be what you expect. 

Things that never impress me

• Being Late - just don't do it
• A Poor CV - you'd think that people would at least put the spell-checker on, or read over it and pick out the glaring grammatical errors. If I get a poor CV on my desk, you'll be lucky to even get an interview and that's regardless of how smart you are or what your experience is. In this industry an eye for detail is everything; and most good developers have it. A poor CV is a neon sign to your ambivalence and lack of attention to detail.
• Not Answering the Question - there is nothing worse than asking a direct question and getting the answer to a different question coming back. If you don't know the answer to something don't fake it! Instead, you could say something like, "I don't know the specific answer to that but this is the approach I would take to solve the problem..." or "I don't know now sorry, but give me 5 minutes in front of Google and I would find out...". If the question isn't clear then ask for clarification. To show that you're willing and eager to learn you should always ask what the answer is - the ability to ask questions as well as answer them is a key skill.

Things that don't automatically impress me

• Computer Degree - some of the most successful people I know do not have any official qualifications in their field of experience. Don't let this put you off a career in IT. Experience quickly supercedes the impact of qualifications. Note that if you have no experience and want to enter the industry then qualifications will of course be helpful.
• Straight A's - it may be a sign that your a smart cookie but on its own it doesn't necessarily translate into a great developer. I don't know about anyone else but I've noticed a lot of straight A CV's over the last few years - I'm sure it wasn't that easy when I was at university! Maybe I'm just making excuses for my hard fought B+ grades.
• Microsoft Certification - I run the risk of pissing off both my employer and Microsoft in one fell swoop here - but here goes. Microsoft Certifications tell me nothing about who you actually are and what you know. They tell me (at best) that you have a good memory for facts gleaned from appropriate swat books or (at worst) you're a great cheat and know how to use the various sites out there that will give you the answers to any questions you're likely to be asked. I sometimes get the feeling that someone with lots of certifications feels the need to prove themselves and doesn't think their experience and knowledge is enough. This is not to say that getting certifications is always a bad idea - if you are just starting out and don't have lots of experience then they can set you apart from the rest. Also, if you are learning a new technology they can help you get up to speed more quickly.

Things that will always impress me 

• Passion - we're pretty lucky in the IT industry, there are so many people who have a passion for computers outside work and can bring that same passion to their work. This is exactly the sort of thing that makes coming to work so enjoyable; sharing a common interest, ideas and enthusiasm. 
• Interests Outside of Work - this is a great indication of someone's initiative. To make the effort to get involved in something without being told to is awesome. In particular, if you're doing something IT related this is a great sign. Examples include, writing your own blog, being involved in user groups, selling your own software, being involved in open source projects. If you can bring in something to your interview that's excellent - perhaps it's an example of something you've written or an application you've built.
• Confidence without Arrogance - it's sometimes a fine line but one that is crucial to being a great developer. You've got to believe in yourself enough to be respected by others but also know your weaknesses and when to ask for help. You don't have to do a car salesman's routine to sell yourself but if you don't believe in your own abilities then neither will other people.
• Being Articulate - thankfully the stereotype of the geek with no social or communication skills is less common than it used to be. As more people enter the profession so do the variety of individuals you come across. However, those who can clearly articulate ideas and thoughts are going to be far more successful than those who prefer the company of play stations to people

So there you have it - a window onto the mind of one person's mind during an interview.

Catch are hosting the first ever New Zealand Enterprise Architect User Group. It always amazes me how many people are actually using EA out there and it's great to see a user group being formed. Will be interesting to see who else is using it and for what.

Follow this link for more information and registration details.

It's a fact of life when working for a service based software company that clients want to know how much something will cost. As an estimator there are a number of other unfortunate realities.

• You will rarely have all the information you need to make an accurate estimate
• Your will often asked to provide "realistic estimations" however these estimates will be judged against a randomly invented figure (often dreamt up by a BDM or similarly unqualified person based on what they think the client will pay)
• You will often be asked for a ballpark figure - then held to ransom by it 2 months later

There are only 7 things you need to remember.

1. Know What You're Estimating (and what you're not) - perhaps the most common mistake in all estimates is the assumption that someone else has covered the areas you haven't. I can't state enough the importance of communication. Talk to the person you are providing the estimate for. Talk to others providing estimates for the same work. Don't assume anyone else knows what they are doing. Find out whether you are only estimating implementation effort? Who is going to include estimates for analysis, design, meetings, testing, deployment, support, project management, documentation, licensing, hosting. Talk, talk, ask, ask, talk some more...
2. Break it Down - it's impossible to estimate or justify an estimate without breaking it down into meaningful chunks. And it is crucial you can justify your estimates; you can't simply say "well I think the whole project will take 20 days" without saying why. Where possible the way you break up the estimate should be as meaningful to your client as possible (while you may not show the details to all clients, if asked for a full justification clients will better understand your estimates if they are broken down in a language they comprehend). Every estimation is different, but here are some common ways to break down implementation effort.
   • By End User Elements - for example, providing costs for each user interface, report, web service interface...
   • By Use Cases - breaking estimates down by use case is especially useful for producing high level estimates. You will probably have sub-estimates under each one to provide more details
   • By Functional Areas - similar to above but not everyone uses use cases
   • Horizontally Across Tiers - I'm not a big fan of doing this but some projects lend themselves to breaking the work down by layers. For example. data layer, business layer, services, user interfaces etc. This is sometimes easier to estimate especially if different people are going to be involved at different layers. However, the main reason I don't like this is because it is generally meaningless to your clients. They have no way of knowing how much a particular business feature will cost. This is particularly important when you are working through the estimates with a client and negotiating scope.
3. Nothing Takes Less Than Half a Day - for anything but the most trivial of estimates nothing should be estimated at less than half a day. If you find yourself at this level of detail then consider combining items into a single, larger, estimate.
4. State Your Assumptions - it sounds obvious but it is often forgotten. This is particularly important when you have limited information but still need to provide an estimate. In my experience, assuming the best but expecting the worst is a good approach. Primarily because, if you assume the best, your estimates will be lower and more attractive to your clients. If things change and get more complicated you have covered yourself and can explain this to your client.
5. Estimate for the Masses - unless you know you are going to do the work you should estimate the effort based on how long an intermediate level resource would take. This is especially true if you are a super-star - the person doing the work may not be so don't set them up to fail.
6. The Law of Optimism - this law states there is an inverse relationship between the experience of an estimator and their level of optimism. Typically more junior estimators will be overly optimistic - they can be cocky or simply haven't experienced enough "estimations gone bad" to know that things invariably don't go as planned. More experienced developers know to expected the unexpected. As such they are more likely to provide conservative estimates.   
7. Compare - comparing your estimates against other similar projects is essential. This is particularly relevant when you look at your estimate as a whole. When you last implemented MCRM and a public web site, how much did it cost - are you in the right ballpark.

So that's it - some commonsense tips for estimating.