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.

I recently posted on how BA's can use Enterprise Architect to document the requirements of a system. This time round it's the Testers turn. If you're evaluating EA from a Tester's point of view this post contains a few things to consider. I should say from the outset - I am not a Tester. I do know what features are in EA to support the testing process. If I misrepresent you Testers out there - apologies :-)

Compared with how EA supports BA's and Software Architects, I'm afraid the news isn't quite so good for the QA team. If you're expecting functionality along the lines of FogBugz then you're going to be disappointed. 

Traceability

One of the biggest benefits for testers is the ability to trace test cases back to the actual design elements that are being built. In this manner you can verify that you have an appropriate level of test coverage that is difficult if your test cases are in separate documents not linked in any way to the actual requirements of the system.

EA essentially provides a means of managing "things" (actors, use cases, requirements, components, classes...) and the relationships between them (associations, realisations, generalisations...). In UML speak the "things" are referred to as elements. Consider the following diagram which shows the relationships between an Actor and some Use Cases. Relationships are also defined where one Use Case extends another.

Testers can then create Test Cases against any element (although most frequently against Use Cases and Requirements). For example, if you were to select the Close Account use case in the above diagram you would see the following details in the Testing tab (this is taken from the example project that comes with EA 7.1).

You set the description of the test case (which in this case is imported from the scenarios of the use case itself) and report inputs, acceptance criteria and results.

Test Cases come in four flavours,

• Unit - for things that are being built, such as Classes and components
• Integration - to test how components work together
• System - to ensure the system meets business requirements
• Acceptance - to test user satisfaction, and
• Scenario - to test the end-to-end suitability and functionality of the application.

The details for each type of test are almost identical so I'm not quite sure why they separated them out over separate tabs. I would rather have seen the a type field against a generic test case.

At this stage it's pretty clear that if your analysts aren't using EA then you're not going to get much joy out of using it to manage your test cases.

EA is not a stand-alone software testing tool; if your analysts aren't using EA to model Use Cases and Requirements then EA is not the tool for you.

Documentation

As with most other areas of EA you get documentation for free. Simply select to create the Test Report and you get something like this.

More advanced documents can be produced using the RTF documentation features. You can also manage all the test cases in your project from a simple Test Details dialog.

Changes, Issues and Defects

In addition to test cases EA supports elements to identify Changes, Issues and Defects. These elements can have relationships to the elements they refer to in order to track activity around them. To be honest I can't see anyone using these elements to track issues and the like. There are far better products to do this elsewhere. In particular you can't track a history of comments/activity against an Issue (or Defect, or Change). The properties for these elements are fairly sparse.

And that's about it for Testers using Enterprise Architect. I'd be keen to hear from anyone who is using EA in earnest for Testing - is it working for you?

Out here in Blogsville there is almost universal agreement that RFP's are a really flawed process with multiple reasons to be hated and should really be put to rest. And I'm right there behind them, couldn't agree more. But don't be fooled.

The reason for such unusual consensus is primarily because it's only the vendors who have blogs - our blog-phobic clients don't have a voice out here.

We're all preaching to the converted, venting our frustrations and often forget why RFP's actually exist. There's nothing worse than a one sided argument so here's some thoughts from the other side of the fence. For dramatic effect, I'll write this in the first person, putting myself in the client's shoes. Disclaimer: I don't necessary agree with what I am about to say but this is what I believe clients are thinking.

• I Actually Do Know What I Want, Thank You Very Much -  I'm sick of vendors telling me I don't know what I want. Goddamn their arrogance. I know my business and I know what my requirements are. If I hear one more vendor trying to convince me to engage with them with no fixed requirements, no budget, no documentation (I think they called it Agile or something) I'll scream. My RFP describes business requirements that I am asking prospective vendors to help me realise. I don't know what the software solution is but I do know my business.
• All My Requirements Are Important - I sometimes get vendors saying they can't guarantee realising all my requirements for a fixed price - instead they recommend we engage in relationship of trust where we agree to prioritise my requirements and implement as many as possible within a budget (is this that Agile thing again?). Like I said in the point above - I know my business requirements, they are all top priority that's why they are in the RFP. Wake up and smell the coffee guys - there are plenty of other vendors who can guarantee realising all my requirements for a fixed price.
• I Want the Best Price - while price is not everything I certainly don't want to be paying too much. By asking for bids from a number of vendors I can more effectively gauge what the real cost of the project will be. I am also hoping that vendors will be motivated to keep their bids as low as possible to win the work.
• Easier to Compare Bids - when my RFP defines a fixed scope I know I am comparing apples with apples. I can gauge non-price qualities of the vendors separately but at least I can compare how efficient a vendor is in realising my requirements.
• I Love Waterfalls - I often hear vendors talk in condescending tones about the perils of waterfall projects. Well I just don't get it.That's what I love about RFP's. I get to perform a thorough analysis of my business requirements, document them in non-ambiguous terms and ask vendors to estimate the work involved in achieving them. What could be simpler? I'm not specifying how the requirements should be realised - that's the job of the vendor and that's where I am looking for the vendor to add value. I wouldn't go out to tender for a builder without house plans and I'm not doing it for my software projects either.
• I Have A Budget - I have to know the price before I engage a client because I have to work within a budget. I can't expect vendors to give me a fixed price without supplying them with as much detail as possible.

Perhaps it all depends on which side of the fence you sit on.