I recently posted about Hiring Internally and it turned out to be about the failure in leadership that I had on a project.  I’m fine with that.  For those of you that don’t know, I fail.  I do so spectacularly (sometimes) and regularly.  Welcome to my realm.  What I do, however, that may (or may not) separate me, is spend considerable time thinking about the reasons for, actions taken during and result of those failures.

In the spirit of Scott C. Reynolds’ recently started series baring all for critcism, I’m going to do the same.  I’m going to openly document my failures.  I’ll do my best to make them detailed and comprehensive, but I will invariably miss something.  Please offer your thoughts and criticism.  I’m a big boy and I can take them.  Hopefully you can take something from one of these and learn from it.  If not, unleash your hounds and tell me how I did it wrong and why you would have done it differently.  I need to learn too after all.

I’ll keep updating this post with links to all of the posts in the series.  I’m not sure how long this will be or what content it will cover.  When I get bored with it I’ll probably stop.  When I think of something I’ll probably write.  Either of those might be my first failure in this series.

Hiring Internally
Interviewing for a position
Napkins and a completed project are not good enough
Establishing Flow

In our Brownfield Application Development book, and in previous posts on this blog, Kyle and I have talked about the different personalities that you can encounter while working on a development project.  Unfortunately many of the types we listed, and that you see and remember, are negative.  Because development is such a social task (whether you like it or not) conflicts in personalities, styles and objectives are easily surfaced.  Add on a heavy dose of introversion and natural social ineptness and you have a cauldron of simmering conflict just waiting to bubble over.

During the hiring process HR and dev teams do their best to eliminate candidates that are obviously going to bring these types of issues with them.  Sometimes it works, occasionally they slip through and you have to deal with them.  Unfortunately, it’s very rare to see the same diligence applied to the transfer of people from one internal team to another.  The results can be disastrous.  About a year ago this happened to my team (I say my because I was the tech lead for the project).

We, as a cohesive and very productive team, were ticking along meeting deadlines, turning out high quality code and generally getting praise from the clients for these things.  Management decided that we had more work that we were going to take on and decided to transfer another of the already on-staff developers to our project to assist with the new work load.  Don’t start thinking the Mythical Man Month and adding resources to an already late project.  We weren’t late.  In fact we were ahead of project schedule at that time.  On top of that the work being assigned to the new team member was isolated in it’s own branch with a thought of it being included in a future release, not the one we were currently working to finish.

Knowing that this developer would be working in isolation I decided that the impact to the team was minimal and shed any worries I had at the time.  Things moved ahead for a few weeks before they came to a crashing halt.  I won’t get into details about what happened but the underlying problem was that the developer recently assigned to our team didn’t have the same beliefs or culture as the rest of the team did.  The result was a series of very animated and heated conversations that led to a requirement for serious and significant policing of the development actions of this person.  In the end the original team had to declare to management (above the project management level) that having this individual working on the project was adding significant risk to the current release and had already jeopardized the following release.  The result was that the offending developer was removed from the project and a 100% re-write of his code (four months effort) was required to bring it to the project’s quality standard.

The lesson that I wanted to convey from this incident was that you have to be diligent in the screening of any person joining your team, regardless of if they are an external or internal hire. Blindly accepting a new resource since they are already within the organization doesn’t preclude them from introducing risk and conflict to the project.  If you are a team/technical lead, architect or manager for a team, you have a responsibility to protect your team from distractions, morale killers and risks.  In this case flags should have been raised months before this individual joined the team, but trained with it.  The statement “It doesn’t matter what the client wants, I’ll give them what I think they need” was boldly stated and I failed to remember that when the speaker was pushed onto our team.  I failed my team by not filtering based on this past interaction.  Don’t let internal recruitment cause you to fail yours.

I recently got an email that had no fewer than eight significant topics in it. Yes, it was a long email. As a result of this email I was unable to remember and act on all the different topics.  Sound like a big messy class/method to you?  Sure it does. 

I propose that people now send emails as they would write code: singly responsible. I don’t care if I get eight emails instead of one, it didn’t cost me anything. I can, however flag for follow up, organize or delete each as I see fit.  Like a good method name the subject line should reveal the entire intent of the email.  Like a method name, the urge to put “and”, “or”, and “plus” in the subject line should be a smell indicating that you have too many topics.

If your emails come in with more than one topic in them I’m likely to miss one item. Heck, I’m likely to delete the email when I’ve acted only on part of what you need me to. In that case, it’s tough shit on you I’m afraid. While it’s convenient for you to type it all up in one window, it’s easier for me to do the job you require of me if I have the separate.

With that, I’m going to start working on an intelligent Outlook filter for this problem.

I’ve been playing around with Microsoft’s new, yet to be released, search engine (bing.com) for the last couple of days.  Miguel Carrasco has done a pretty detailed review of it’s capabilities here.  I don’t see the point in me re-hashing his findings so I’m going to point out some things that I’ve noticed and liked.

Image Search Paging

The best thing about the paging model on image searches is that there isn’t any.  Yah, no longer do you have to click through the page numbers or “Next” button/links on the bottom of the current page.  Instead, with Bing you just scroll down and it will fill in the next set of images for you. Scroll down some more and it will fill in the next batch for you again.  Personally, I think this is a fantastic way to navigate through results.

Web Search Paging

Unfortunately, the people responsible for the web search results didn’t work closely enough with the image search people to get the same paging model implemented.  You still have to click “Next” or a page number to see more result.  This is a fail in my mind.  So close to success, but a usability miss.

Content Preview

Hovering over a search result allows you to move to the far right of it and expand out a preview of the content in the web page that contains the term you’re searching for.  Too often I search for stuff and find that the previews provided in search results don’t let me understand the context of the terms use.  This looks like it could help with that

Grouping of Information

If you look at this search for Ferrari you see that there are groupings for content such as “Cars”, “For Sale”, “Dealers” and more.  The more that I use the search engine, the more I wish that this would be expanded to other search terms. For example, searching for “NHibernate WCF” doesn’t bring back results that are grouped.  Why not have them grouped under headings like “Blog”, “Magazine”, “Provider Content”, etc?  I think this would help people to better decide what trust level to assign certain content.  I know it would certainly help me to focus on the areas that I think provided better content value.

Overall

It’ll be really interesting to see how Bing turns on.  Maybe Google’s search really isn’t all that.  Maybe it was just the best that we had, but it could be improved a lot.  Maybe Bing does this.  Time will tell.

As part of my recent changes to the WCF-NHibernate code I have, I declared that there wasn’t going to be a way to handle automatic transaction rollbacks when WCF faults were going to be raised.  I wasn’t even sure that I wanted them in tool.  Andreas Öhlund pointed out that rollback could be handled quite nicely using the IErrorHandler interface within WCF.  After some toying around with the idea and some proof-of-concept implementations, I decided to add this ability in.

Currently you identify a WCF service as using the NHibernate code by adding a [NHibernateContext] attribute to the *.svc.cs file.  I wanted to keep that syntax, and the rollback capability, as clean as possible.  Rather than adding another attribute, I parameterized the existing one.  Now you can indicate that the service should automatically rollback the NHibernate transaction when WCF Faults are being raised simply by attributing the *.svc.cs file with [NHibernateContext(Rollback.Automatically)].  The default [NHibernateContext] requires manual rollbacks and exists as such for backwards compatibility.

More information can be found over on the wiki (http://www.igloocoder.net/wiki) and the code can be grabbed from the svn trunk (https://igloocoder.net:8443/svn/IglooCommons/trunk).

Wrapping up our first pass at Development Project Archetypes we look at a common culprit on brownfield teams.

During your first week on the project you’re assigned to have a mentor who has written a large portion of the existing application. While working on your first serious defect in the system, you ask the Possessive Developer about an existing piece of code and suggest refactoring. She looks back at you and states “There’s no reason to change that code. It works just as I want it to.” After explaining its deficiencies, the Possessive Developer is sullen and in a less-than-cordial mood. At the end of the conversation she has neither agreed nor disagreed with the suggested changes, but there is tension in the air.

The following morning the Possessive Developer corners you at the water cooler and lashes into a list of reasons that there should be no changes to the code discussed the previous day. At the end of the one-way conversation she walks away with confidence in her stride. You now know. It is her code, her creation and her domain. Only the Possessive Developer can state when her code is to be changed.

Like the “Oooo…Shiny!” Developer, code reviews with peers can be useful. In a more neutral forum, it’s much harder to argue against the majority. But don’t ignore The Possessive Developer. It doesn’t take long to turn her into a Skeptic or a Hero.

For the final few posts in the Development Project Archetypes we'll focus on developers.

An incestuous cousin to the Front of the Magazine Architect, this developer is easily distracted by any new technology. Not only will he want to talk about it endlessly, the ‘Oooo…Shiny!’ Developer will simply add the technology to the project without telling anyone. You will find, scattered through the code base, a number of different techniques, tools or frameworks that are used one time and then abandoned. While adding to your technical debt, the ‘Oooo…Shiny!’ Developer is working feverishly to keep adding new entries to the “Experience Using” section of his resume.

Sometimes it is easy enough to counter his predilection for new and shiny simply by placing a pretty glass bead on their keyboard every morning. When that fails, it’s time to up the priority of the code reviews for The “Oooo…Shiny!” Developer. And be merciless.

Still avoiding developers, we continue talking about archetypes...

Usually found in the confines of an organization that has heavily silo’d roles and responsibilities, the Enhancing Tester will be assigned responsibility for ensuring the product quality. She believes it is her personal responsibility to question and alter any specifications that were used in creating the software. Since she wasn’t involved at the start of the development cycle, the Enhancing Tester will question the design and requirements only after the development team has passed them on for test. The proposed ‘enhancements’ are usually obscure and with far reaching architectural ramifications. For example, “this really should be an MDI application.”

Since she understands the original requirements, but not the overall business, the Enhancing Tester has no choice but to log these as software bugs so that they will get the attention of the team. After working with her for a few months you will wake up in a cold sweat yelling “It’s not a bug, it’s a feature change!”

Usually, you can counter this by assigning cost estimates to the “bug fixes”. It helps to do so in front of the client.

Deviating from the developer sphere, we continue the Development Project Archetypes...

A good many application require access to a database. If you’re lucky, you’ll have free rein over the database to make whatever changes you deem necessary. If you’re unlucky, you’ll need to make those changes through an Over-Protective DBA.

The Over-Protective DBA protects his database with an iron fist. Requests for changes to a stored procedure go through several iterations to ensure they include the standard corporate header and naming conventions. He also challenges every single piece of code in the procedure to see whether you really need it. Only when satisfied that the application can’t be deployed without it will he grace the database with your changes. In the development environment, at least…

If you really want a battle on your hands, suggest to an Over-Protective DBA that you should switch to an object-relational mapper. Be prepared to launch into a prolonged debate on the performance of stored procedures vs. dynamic SQL, the dangers of SQL injection, and the “importance” of being able to deploy changes to business logic without re-compiling the application.

The Over-Protective DBA often has company policy on his side so he will be a challenge. Don’t spend a lot of time confronting him head-to-head. Your database is an important part of your application, it behoves you to get along with him. Instead, arm yourself with knowledge and talk to him in common terms. In our experience, DBAs can often be negotiated with for certain things, such as an automated database deployment.

Another in the Archetypes series...

Everyone loves a hero. The PM, the architects and the client relish the long hours he puts into delivering results. When the client is told we don’t have the budget or manpower to add a feature, the hero’s cubicle is his first stop after the meeting. “Old man Baley says we can’t have this. But we NEED it.” The Hero hums and haws and complains how badly the project is being managed, then with a sigh says, “I’ll put it in. But this is the LAST TIME.”

The Hero then proceeds to circumvent your entire development architecture wedging the feature in because he doesn’t understand terms like “budget” and “resources”. All he cares about is getting his ego stroked and being the martyr that saved the project. The long hours he puts in are heralded by the PM and the client who don’t realize his effort is not directly correlated to the value he is delivering.

Project Managers and Clients will scoff at you when you make claims against their Hero. In their mind, he is a cornerstone in the project and whose absence will wreak havoc on the success of the project. Regardless of their actual ability, Heroes are often more trouble than they’re worth.

A while back I posted about a small framework that I wrote to make handling of nHibernate Sessions easier in a WCF world.  There were a couple of problems with it and I've spent some time fixing it recently.  The entries on the wiki have been updated to fix problems in the documentation as well.

The big changes in the framework were a bug fix that was preventing the commit from being run, moving to the latest version of nHibernate, and making better use of nHibernate transactions.  The svn source code repository is available here.  If you get it and run the b.bat at the root of the trunk you will be able to grab the latest artifacts from the release folder that is created in the trunk.

The next post in the Software Development Archetypes series...

Every project needs experienced people to improve the odds of succeeding. Skilled developer resources are hard to come by so you’re really excited to be joining a team that has some “Experienced” Developers. But it doesn’t take long on any project to realize that experience is a relative term. When asking for help, the “Experienced” Developer’s questions are often at the same level as some of the junior developers on the team. When he does propose a solution, and has it turned down, he immediately plays the “I have 12 years of experience in this industry. I think I know what I’m doing" card. As a result, he will be a ferocious, if not weakly armed, foe when arguing the merits of a situation.

On his own, the “Experienced” Developer is usually an easy person to handle. A simple “show me” is enough to counter him. Eventually, he will stop playing his “number of years in the industry” card and come around.

Another post in the Development Project Archetypes series...

Every time that the team attempts to implement a technique, process or technology that will address a project problem and better the team’s ability to deliver to the client, the Skeptic will interject. If it’s unknown to the Skeptic, then he must speak out about his doubt. Often the doubts are small and founded in his complete lack of knowledge. Regardless, he will stand by them vigorously until the project has discussed (at least three times) the situation.

The discussion will not, however, satisfy the Skeptic. If he does agree to move forward, it will be under very vocal protest. He will end his part of the discussion by stating that he “still isn’t sure that [he’s] fully convinced of any benefit”. Regardless of how the project moves forward, the Skeptic will always be the first person to point out any small flaw in something that he opposed. He was, after all, trying to warn the team of the potential problems ahead of time. And now it’s your fault for not listening back then.

If you’re lucky, The Skeptic can be ignored. But if he has some political clout, you may need some allies in the form of other developers. Focus on convincing the other developers that what you are doing is correct.

IMPORTANT NOTE: Just like you are not always right, The Skeptic is not always wrong. Don’t discount his arguments just because you always have before.

Transitioning into the realm of developers, we continue the Development Project Archetypes series...

Though you will usually see the Disinterested Developer working diligently whenever you walk by, you also notice she has a well-known social networking site constantly minimized on his desktop. Over time, you see a pattern: social networking tools when no one is thought to be around, development tools when there is. During meetings the Disinterested Developer is looking out the window or checking her mobile phone. She doesn’t engage the rest of the team on a technical level. She answers only when required and delivers the minimal amount of work necessary to keep the project manager happy. Her heart either isn’t in software development or she’s bored with the project.

The Disinterested Developer isn’t necessarily a bad person. Not everyone is as keen on software as you are (right?). But care should be taken to ensure she carries her weight. The last thing you need on a brownfield project is a team revolt because she is perceived as getting special treatment. Your best bet is a heart-to-heart with the developer to see if there is a reason behind her ennui. Give her every chance to turn things around. It may sound mercenary, but if there is no improvement, don’t discount removing her from the project as an alternative.

Resuming the Development Project Archetypes series...

Monday morning and the Ex-Tech PM appears on the edge of the status meeting as an observer to the team’s daily ritual. One by one the developers tell of their current work and its state. As one developer mentions that there will be some design work in his day ahead, the Ex-Tech PM interjects with “We used to do <something> when I was an RPG developer. You should look into doing that too.” The team continues through the standup and when completed the Ex-Tech PM corners the developer to provide more details about his idea.

Over the next few days the developers come up with a solution (different from the PM’s, naturally) and it is mentioned at the morning status meeting. On hearing this, the Ex-Tech PM becomes adamant that the team didn’t put enough consideration into his idea and the results of his project five years ago justify the same solution be used here and now.

Luckily, the Ex-Teach PM is easily appeased. A simple “yes, you’re right, dear” will keep him at bay until he has long forgotten the issue.

The next post in the archetypes series...

Once a month, every month, she visits the team and blurts out “We should use/do/implement <insert technology of the month here>.” The monthly rhythm of the visits is tied directly to the delivery of the Front of the Magazine Architect’s magazine subscriptions and RSS feed. Anything that is boldly emblazoned across the cover of an IT related periodical becomes that month’s flavour.

The Front of the Magazine Architect is another easy one. While they are annoying distractions, her visits will be infrequent and short lived. As quickly as the idea enters her head, it will leave and you won’t hear from her until the next month. If the same technology is mentioned two months in a row, it’s probably time for you to contact the magazine editor and request that they do a better job covering new technologies.

Another in the archetypes series...

This person is one of the most feared by developers around the world. While the team is working to deliver software, he is asking them to write action reports and detailed impact analysis documents and any number of other reports he needs to grease his process and document pacifier. Though able to bend Outlook and Microsoft Project to his will, the simplest of changes, like re-scheduling a recurring meeting, will throw the Process-Heavy PM into a fetal position. It will take him days to recover from the disruption to his carefully scripted master plan for the project. Suggest that there is no need to type up the minutes for a meeting and watch the blood drain from his face as if you have just sounded the project’s death knell.

While the Process-Heavy PM can be (in our twisted minds) the most fun person on a project to toy with, he will be the one that will, more often than not, have you writing summary documents after your call to order pizza for the team. To counter him, be sure you account for every single second you spend on his process when you fill out the intricately-detailed timesheet he has requested from you.

Continuing the series on archetypes...

Beaten down by months of missed deadlines, misunderstood requirements and repeated defects, the Disenfranchised Client has lost all faith in the team’s ability to deliver and is merely going through the motions until the next budget cycle. Because of this and because she pays the bills, she is one of the most dangerous archetypes. To counter her, you’ll need strong social skills to assure her that her needs are being met, though it may be weeks until you see any progress.

The best way to deal with a disenfranchised client? Give her working software and give it to her often, dammit!

The next instalment in the archetypes series...

When the project starts the Absentee Client engages the team just long enough to build up some velocity. As soon as he perceives some progress being made, the project is quickly re-prioritized to a much lower level in his calendar. The team will wait days or weeks to hear back from The Absentee Client about the simplest of clarifications. Important meetings will be rescheduled numerous times at his request and when he does attend they will have to be cut short due something else important having come up.

One way to get the Absentee Client’s attention is to outline how significantly the lack of engagement is increasing the timeline and the risk to the project. Your best bet is to put the effects of The Absentee Client’s actions into terms of cost. Unfortunately, and this should not be undertaken lightly, sometimes the only way to do this is to address the Absentee Client’s superior.

This is a commonly known archetype in the development world.  Since it's commonly known I figure it's a great place to start this series of posts.

Sporadically swooping into meetings with the rest of the team from his namesake home, the Ivory Tower Architect loves to show his mastery of software design. Whether it works in practice or not matters not to him. The rest of the development team is left to implement the grandiose plans handed down from on high, but the Ivory Tower Architect will never work directly on the code himself. Often the designs are overly complex and time consuming to implement, but he will not change them. To do so undermines his very existence.

Dealing with the Ivory Tower Architect requires a strong will, the willingness to have long winded and abstract design debates, and an almost fanatical adherence to the KISS (Keep It Simple Stupid) principle. Lucky for you the Ivory Tower Architect will only rarely grace mortal developers with his presence.

As part of writing our book, Kyle and I have spent some time coming up with archetypes that exist on many of the software projects that we've been on.  Our goal is just to describe what we've seen so that people can better identify them in their journeys.  Of course this had to be written in a dry, sarcastic manner.  I'm going to keep updating this post with the links for the new archetypes as I post the series.

1. Ivory Tower Architect
2. The Absentee Client
3. The Disenfranchised Client
4. The Process-Heavy PM
5. The Front of the Magazine Architect
6. The Ex-Tech Project Manager
7. The Disinterested Developer
8. The Skeptic
9. The "Experienced" Developer
10. The Hero Developer
11. The Over Protective DBA
12. The Enhancing Tester/QA
13. The ‘Oooo…Shiney!’ Developer
14. The Possessive Developer

If you're getting:

HTTP Error 404.3 - Not Found

The page you are requesting cannot be served because of the extension configuration.  If the page is a script, add a handler.  If the file should be downloaded, add a MIME map.

This is because IIS7 isn't setup to serve out WCF svc files by default.  Quick fix is this:

%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -r -y

Thank god for the internet and David Sandor.

Over the last few months people have been asking about training on the fundamental practices that I use when doing software development.  In combination with the soon to be pending (honest, it's almost done) release of the Brownfield book , I'm going to offer a four day training course on those practices and how they relate to development work in existing code bases.  Due to the levels of interest, I'm going to offering the course in Winnipeg from April 27th to the 30th.  More information about the course can be found at the registration site and by downloading this pdf.  If you have any questions about it or the location, send an email to training@igloocoder.com.

The Iron Triangle is a common way to refer to the different aspects of a software development project.  In his great article, The "Broken Iron Triangle" Software Development Anti-Pattern, Scott Ambler states that "...something has to give, whether you want it to or not". We all know this is true.  If you have fixed schedule and fixed budget, the scope of the project has to be flexible for the other two criteria to be met and the project to have any chance at succeeding.  The one thing that Scott's article doesn't discuss in any great detail is the Quality aspect.

The longer I practice in this profession, the more that I think about the long term quality of the application's code base.  In my mind quality comes in two forms.  The first is the quality that the client defines as a non-functional requirement.  For example, there must be no reported and outstanding defects for the application to be released to production.  Usually the client will define quality in a way that is based on acceptance of the applications functionality in a working state.  The most common measure of that is defects.  The second type of quality is the the one I mentioned at the start of this paragraph; long term quality.  Rarely does the client explicitly define this type of quality.  It will include things like the maintainability of the code base, the ability for new feature to be added, existing ones to be altered.  Really this is all about '-abilities'...maintainability, reversibility, replaceability, repeatability, etc.

If you look at the Iron Triangle the Quality portion of the project is, if included, usually placed in the center of the triangle.  It doesn't really fit into the analogy all that well.  Today Kyle and I were hashing out what the Iron Triangle meant to us in terms of software development.  Neither of us could rationalize the exclusion of both written and visual representations of quality.  After a long IM chat that went in circles, triangles and at one point a dodecahedron (don't ask).  Our final point in the conversation ended not on a shape, but instead on a balance scale.

The point we ended on is that there are four components and 2 reside on each side of the scale.  On one side are Schedule and Budget.  On the other side are Scope and Quality.  We always want our project scale to remain balance and to do that it's all about give and take. Think of each of the four items as weights on the balance trays.  With that in mind, here are some of the common scenarios.

The client increases the Scope of the project. 

To keep maintain the balance you can have four options:

1. Increase the Schedule
2. Increase the Budget
3. Increase both the Schedule and the Budget
4. Reduce the Quality

The client reduces the Schedule.

1. Decrease the Scope
2. Decrease the Quality
3. Decrease both the Scope and the Quality
4. Increase the Budget

The client decreases the Budget.

1. Decrease the Scope
2. Decrease the Quality
3. Decrease both the Scope and the Quality
4. Increase the Schedule

There are ways to make this pattern break.  For example, increasing Budget often equates to adding developers.  As is stated in the Mythical Man Month, this is not practical without incurring a decrease in productivity.  Also, not all developers are created equal.  Adding a poor developer, even early in a project, can often be more of a impediment to than benefit.  As a result our conversation decided that, while important and facts of life, the simplicity of any model (including ours or the Iron Triangle) requires that all needed to be qualified with the statement "...all things being equal".

Thoughts?

As always the Victoria Code Camp was a great success and loads of fun.  The biggest disappointment was that the weather back here in Alberta wasn't worse, thus making Victoria's temperate days more appealing.

In a small scheduling conflict my presentations there's a chance that some of the attendees didn't see that my sessions were being run in a non-standard room.  For those that missed, my apologies.

Here are links to my session materials.  Note that you will have to download PostSharp and install it to make that portion of the code samples work.  There is no installation required to work with the Castle Windsor interceptors.

Aspect Oriented Programming slides (pdf)

Aspect Oriented Programming code (zip)

Refactoring to Logical Layers slides (pdf)