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.