Iterate Iterate Iterate!

Adam Fridman writes about the "massive" downside of agile software development for Inc. magazine. He is right to acknowledge the risks involved in any custom software project. Without knowing how software projects of any size can fail, you can't modify scrum well because you don't see the difference between a catastrophic derailing vs an intelligent tweak. The way Adam assumes these risk are fatal flaws to agile seems to be throwing the baby out with the bathwater.
The articles biggest flaw is the way it propagates a Big Software Myth: clients know what they want.

Feedback is an essential part of every software project, and claiming that waterfall provides superior predictability doesn't hold water (see what I did there?) in reality. Waterfall's additional plans and requirements tomes provide the illusion of predictability but in reality are themselves the cause of much waste. The wise executive knows this and sets roadmaps of long and short-term goals, and adapts along the way as milestones are hit. Build something and inspect it. Adapt your plans accordingly. inspect adapt iteratively and you provide the highest value for the lowest cost.

SOLID principles and self reflection on over designing software

Rob Ashton, someone on the internet who codes, has opinions on the SOLID principles that resonate with the kind of decision making we are taught in school but isn't practical for the real world. I'm not debating whether or not there are measurable benefits to these changes, but the complexity added to the code is the unmeasured cost when you design in the ivory tower.

I've definitely made this mistake in over architecting, and so has Rob. He quotes a fictional self that resonates a little too close home:

What if somebody at some point wants to change this so they can have another behaviour for this value, I'd better use the strategy pattern here instead of this switch statement, but oh my word now I've done that what if somebody wants to use this code from some other system than this one, I'd better stick a command system in front of this and use double dispatch for handling them - but wait, what if other code needs to react from this and do something else, I'd better raise a pile of events, but what if those aren't enough I'd better make sure I split all this behaviours out into their own interfaces so they can be overridden and...
http://codeofrob.com/entries/my-relationship-with-solid---the-big-o.html

Everything in there I've done. Not quite in that order (I have a habit of implementing interfaces for everything)  but event handlers, command pattern, it so often ends up useless in typical LOB business software that I've been writing. You figure if it would matter anywhere it would be here, but not the case. Certainly overkill if we worked on one-off customer work. YAGNI and KISS are very applicable in one off projects or services engagements. Even in more recent engagements with software companies, "wiring" and "piping" can be extended after-the-fact to support your nonfunctional requirements (assuming you have decent test suites).

TL;DR: Don't be an architecture astronaut.

Relating to Ninja/Wizard/10x

Best article I’ve read in the Ninja/Wizard/10x discussion in a long while:

I’m more akin to a librarian, scientist, artist, and carpenter.

Unable to Reference classes in App_Code or other folder in Web Application Project

So if you google "unit testing on web application projects" you'll get discussion on using the "web application" project instead of "web site" project type. I won't retread that here, its been done elsewhere:
http://stackoverflow.com/questions/1198555/unit-testing-asp-net-web-site-project-code-stored-in-app-code?rq=1

The other common solution to the problem is changing the project's targeted .NET version.

But if that still doesn't work, it could be the content type on your files. This often happens when you have folders in your project (like App_Code) and add new items to those folders. Right click on those files in your solution explorer and select Properties.. --> change their type from "Content" to "Compile" and your reference should succeed:

Here is a link to more discussion and a post that had the answer I was looking for the whole time:
http://stackoverflow.com/questions/4228992/namespace-not-recognized-even-though-it-is-there

Google books lets you sample pages from any book

In "shouldn't-this-be-illegal?" news, google books lets you browse some limited number of pages of any book it indexes. That includes many technical books making this quite handy!

Here is one sample book, have fun.

Google lawyers have a FAQ: http://books.google.com/googlebooks/perspectives/facts.html

Fiction: If a book is still under copyright, scanning it without permission is illegal.

Fact: This is probably the most common misconception about Google Books, and about copyright law in general. The "fair use" provisions of U.S. copyright law (USC 17 107) describe the conditions under which someone may copy a work without the copyright holder's permission, like recording a TV show to watch later or quoting from an article in a blog post. Fair use is designed to safeguard copying that doesn't harm people's incentive or ability to produce and sell creative work, including books.

We've carefully designed Google Books to make sure our use of books is fair and fully consistent with the law. Copyright law is aimed at protecting and enhancing the value of creative works in order to encourage more of them–in this case, to ensure that authors write and publishers publish. We believe that by creating new opportunities for readers to find and buy books, we can help authors and publishers sell more of them. You can read more about fair use here.

Given the obvious risk of being able to reconstitute the book samples into the whole the established publishing regime must have disapproved. Google engineers must have seen that coming and had some reasonable arguments to defend the position. To be a fly on the wall there...

TDD is Dead Long Live Testing?

David Heinemeier Hansson has a great article on his blog titled TDD is Dead Long Live Testing. I wrote a similar article here in 2012: To Unit Test or not to Unit Test. TDD is a great programming technique and I cannot agree more with David that when it works, it brings a new confidence to the iterative development practice that is hard to match. But set in its proper context of the software and testing life cycle, TDD is an interesting technique that has costs often exceeding its benefits.

Software Training is All About Timing

The point of this post is simple -- software training cannot be successful until users have the live system in front of them with a goal in mind they want the software to help achieve.

TL;DR: Up front training is not successful for logical reasons. Use up front sessions to create user buy-in instead of training. Parallel testing is often the ideal time to train users.

I am not an expert when it comes to the fine details of software training. How best to conduct the sessions and how to present the content are things I respect but have little practical expertise in. I am, however, a witness to a great many people who learn how to use new software systems and I am (painfully) aware of the kinds of problems they have.

I am not naive about the difficulty of setting up the "software in front of your users with goal in mind" scenario but in most software deployments there is one convenient moment that puts your users in a position to succeed -- during parallel testing. A parallel test is no small task but it is the perfect opportunity for this scenario to exist for a wide range of users. Piggy backing on the parallel test for training is superior in efficiency of dollar spent per unit of user skill gained to traditional up-front user training because of the psychological engagement only real use cases can invoke. I strongly recommend parallel testing for any system roll-out for many other good reasons but utilizing the optimal training moment is one of the best side effects.

Psychologically, when users have "skin in the game" they can learn. And to be painfully realistic, very few are capable of learning before that point. We are busy, we have deadlines looming, we simply cannot pay attention to a system training for a system we will not touch for another 2 weeks and we've never seen before!

So I am recommending the abolishment of traditional up-front user training sessions? No. What I am recommending is a shifting of the goal of that up front meeting (and hopefully reducing its duration and expectations).  It can provide enough of a primer that the users think the system will be easy to use. Show high level things it can do. Describe in glorious detail how it will make their life easier. Set up scenarios and make the software sing. Its almost a full sales demo, but with the system's future users instead of its purchasers. Get them excited about it. That first training session is more about "buy-in" and emotional connection to the new reality. Make them want it by selling the system. That is about as good as you can hope for. This is a huge difference from the usual top-down approach that has a tendency to demoralize future users and encourage animosity towards support staff (notice how support teams are seperated from the trainers? Why are these are different teams? Support is very often "just in time" training!) negative feedback that finds its way back to the stakeholders as complaints about the "complexity of the system". That rationally stubborn user behaviour can be curbed by acknowledging the very human need for buy in in a sales-like kick off meeting. Of course there are limits to the success of this initiative and after that buy in meeting there may still be resistors, but at least you've identified them (or perhaps the solution doesnt solve their problems and thats a whole 'nother issue :)).