by: Darrell Mozingo

December 2006 was a low point. The company had lost some good developers, projects were stalling, morale was low, and the outlook simply wasn't good. It was the usual story, probably heard thousands of times before and still lived by thousands more: cowboy coding in continuous crunch mode. Page behind line counts were climbing into the mid four digits and the simplest changes had huge rippling effects across not only the current project, but other systems that were so tightly coupled together they were all fused at the hip. I was in the process of flirting with a few other companies at the time too, but after realizing I didn't want an almost hour drive each way every day, I decided to stay and try to help turn things around.

Coincidentally, something also changed in management around this time – perhaps they saw the sharp morale decline in recent months, or read an article that got them thinking, or who knows – and they too decided things had to change. So, the first step was talking them into getting us some quality training, and not just the ‘ol Advanced ASP.NET training, but some more basic and helpful training, like Object-Oriented Design & Analysis. They agreed, and everyone was thrilled afterwards. We saw all of our current pain points laid out with corresponding ways to counter them using solid OO designs and techniques over the week long course. Sure we all had our OO classes in college, but we'd never really seen how to properly apply them to business applications. First thing after the training, both management and all the developers sat down to lay some new ground work for our future course.

Books were ordered to rebuild our then defunct library, including plenty of juicy OOD books and some old McConnell classics. Online articles started getting sent around between developers for more reading. We started pushing back on clients (who were, in a way, internal clients) to give us time for development. Management loosened the budget for new hardware and software. Things started looking great, and it all happened in only a few months time. It was amazing. Sure, there were still things that needed to change, but we were definitely heading in the right direction.

Before "the transformation" had even began, several of our internal clients had been wanting complete new systems (some were still running classic ASP, some had completely changed their business model, etc), but they weren't quite ready yet. So we kept chewing on existing work that needed done. For almost a year afterwards we tried the various techniques we learned, along with some new ones, on existing projects and several smaller new ones. OR/M's, small scale unit testing, decoupling, CI, and more were all being tried and accepted within the teams. With these large, green field, development projects looming ever closer, though, we were still hitting pain points using these new techniques. Clients weren't completely happy, and there was still something just not sitting right with us developers.

One of the newer developers – not junior, just new- had been looking into adopting RUP at his old company. IBM agreed to come in for a quick one day assessment of our current lifecycle process, where they'd sit down and talk with our clients too, and give us suggestions for improvement (sales pitch, anyone?). When they gave their review, though, it hit me like a ton of bricks. We were using good development techniques, sure, but inside an almost pure waterfall structure. We all knew waterfall wasn't the way to go, but we were totally wearing blinders to the fact that we were even doing it. Whoops! Oddly enough, IBM pushed a very agile form of RUP on us afterwards, so we took a look.

Since then, some teams have adopted a more formal RUP framework, while others, like mine, have gone with styles leaning heavily towards agile. I'd done tons of reading for quite awhile, and a bit of playing in my off time, with test driven development, so I pitched it along with the new ASP.NET MVC framework, and they took it. The team I'm on is small, with only two other developers working on a large, green field payroll application, so acceptance is usually easier to get.

We're now on iteration 3, developing in a completely test-driven way (though we still catch ourselves doing some test-after-development, but we're working on it!), delivering functioning software to the users a little bit at a time using as "many practices" from the ALT.NET community as we can. We're not completely agile – we're not really doing user stories and planning as, say, an XP team would, but I'm sure we'll fall into that eventually. One piece at a time we're converting over. We're also very interested in BDD and DDD, too, and are looking into it while adopting some of those practice's lower hanging fruit.

So far our users are thrilled with the software, we're very happy with the design and testing being built around it, and I'm absolutely loving my job again. We've come a long way in a relatively short amount of time, and things continue to get better every day. To think, I almost quit.

Mentoring is something that is in my DNA. When I was in college I remember not just trying to learn what the teacher was presenting, but I'd also pay attention to how the teachers conducted their lectures. In some cases I'd think to myself that if I were at the podium, I'd present this subject differently.

I have never formally taught any class (although that is definitely in my list of things to do one day) but now I frequently find myself serving as a mentor to a less senior developer or a new team mate. It's not the same thing, but it has enough in common with teaching to make my college memories useful.

Back to my college days, in that brain-draining BSEE curriculum, one of the clearest demonstrations of teaching skills was given to me in a way that I will never forget.

One of those semesters I was attending the Cryptography class and I just couldn't stand the way the teacher was presenting her material. Incredibly boring projector presentations, mostly reading from them and making no effort to keep the class awake. After I got my horrible results in the first round of exams, I was considering getting out of that class and coming back next semester. People kept telling me to not do that because the new teacher for the next semester was rumored to be tough and very serious about his classes.

After a little hesitation, I decided to get out of that class and I was back in the following semester, new teacher and all. That was the best decision I made in the entire course.

Mr. Campello was the best teacher I ever had. That guy had passion for Electrical Engineering, Cryptography, and for teaching.

Differently from the previous semester, his classes were packed. Students would not want to miss a second of each class. He would deliver never ending nuggets of wisdom, incredible stories about how cryptography has been important throughout history. War stories. Ancient history. You name it. They guy knew it all. Cryptography became one of my favorite subjects, even though it's mostly advanced discrete arithmetic, which is as boring as it gets.

During one of those classes Mr. Campello dropped a monster bomb of a quote. I don't know if that quote is his original, or if he was quoting somebody else. I don't even remember the context in which this quote came about. He said:

"Teaching is like telling a smaller lie everyday"

I won't bother explaining the power of that statement. I'll leave for your own analysis. I don't think there's any other thing that somebody told me that had similar impact that this quote.

Replace teaching with mentoring, parenting, modeling, etc and you've got yourself a lot to think about.

by: Glenn Goodrich

The story you are about to read is true. The names and identities of the innocent have been changed to protect them and my job. No animals were harmed in the writing of this story.

Roughly three to five years ago I was an intermediate ASP.NET Webforms developer. I had produced several applications for various clients that were in different stages of test/production/maintenance /graveyard. Some of these applications were loved by my clients, others were tolerated, and still others were abhorred. The aspects all of these applications did have in common were a high level of difficulty to maintain and an almost violent resistance to change. Most of my clients tend to generate requirements in a management bubble so during the first round of testing, (if it existed) or the first weeks stumbling through production deployment, the user feedback was very large. Of course, the client always desired make changes accommodating this feedback, which is often where my real troubles began.

There had to be a better way. So, I started combing the web, hoping to find people that solved issues like mine. Googling phrases like “extensibility”, “webforms pain”, and “easy asp.net deployment”. If memory serves, the first fish on the line was Rails. I did the Rails “Hello World” and was amazed at how fast you could get going, how easy you could add views, and how much of my nerd life I had wasted. Realizing that my clients were not quite ready for Rails (“Ruby on what??? Where’s the msi?”) I started looking for MVC in .NET. This, as you’ve probably guessed, landed me at the Castle Project. Monorail was just what I needed. I could shoehorn it past my clients’ open source/never-heard-of-that worries, because it was .NET. But this was just the beginning.

The Castle Project also had the Windsor Inversion of Control (IoC) container, which led me to things like “separation of concerns”, “single responsibility”, and the “open-closed principle”. It really started me down the path of Test Driven Development (TDD) which was probably the single biggest positive change to my coding practices. It was a little bumpy at first, but once I saw that I could get all my code working before I even had a web site application AND I could really test it, I was hooked.

I started reading the Castle Forums as well as Hammet’s blog and Ayende’s blog. Figuring they weren’t the only really smart people out there, I started reading tons of blogs (CodeBetter, Martin Fowler’s Bliki, etc.) which showed me the endless world of better design practices. I started reading books that weren’t from Microsoft Press (nothing against them, but there are a lot of good books out there) including Head First Design Patterns, which was another huge A-HA! moment for my development career. I now read blogs everyday and have at least two books going at any moment in time. I read about Continuous Integration and CI Factory, as well as NHibernate and other OR/M frameworks. This was my first steps into Continuous Improvement.

So, where is this going? Is there a success story in our future? Before you object to the relevance of my opening statement, we have finally arrived at my success. We were handed a very large client from a business partner, partially because that partner could not satisfy the needs of the client. The client (who I will call BigCo) wanted a web-based application to put in front of their customer-facing employees to, basically, figure out if BigCo could provide any services to new clients. There were various factors that affected BigCo’s ability to provide services to a given customer, and the application would have to perform the logic that determined each of these factors. For this article, we will call the application ProviderApp. ProviderApp had to do the following:

Collect information about the customer. Find out where the customer lived. See if BigCo had the ability to provide services to that location. If the location was good, show the employee which of BigCo’s services were available. Persist the results of this interaction.

So, BigCo wanted a prototype. Tapping into my new approach and knowledge, I started writing tests for my (persistent ignorant!) domain model. Customer, Address, ProviderResult, and other classes were the result. All clean and responsible only for themselves and fully tested. I used separation of concerns to partition out the factors into services, being sure to use interfaces. These services were also open for extension, but closed for modification. In fact, for testing, I actually wrote test-only providers, removing the need to invoke some needed external services that would be used in production. I had all the logic for the factors written and tested, all the domain model designed and tested before I had even created a web application. Also, thanks to CI, I knew when the build was broken immediately, so bugs didn’t have a chance to get stale, causing me to have to hunt for hours or days because I didn’t know when the bug was introduced. By the time I got around to the user interface (the web application) it was simply a matter of writing my views and consuming my services. Oh, and the act of writing pure HTML views was a breath of fresh air.

I finished the prototype a couple of days early, so we had to time to actually perform real user tests, which I don’t think I had ever seen before. The bugs found here were relatively small but made a big difference in our demonstration of the prototype. On demo day, BigCo was very happy with the prototype. They were not wowed, they were not dazzled. Their reaction is not the success story. The success story comes from the fact that I was relaxed on demo day, confident the software was solid. I had no anxiety about getting off the beaten path, which was new for me. In fact, I let the BigCo folks drive the application at the end of the meeting and told them to show it to whomever they liked later. There is no way I would have been confident enough in my previous life to let a client demo my “prototype” code.

At the end of the meeting, the BigCo people asked me how long it would take to “make this real”, which is when my success story really sunk in. I realized, right there in front of them, that the application was done. My answer was a matter of days, as I did have to write new providers for a couple of the services, since they were using different back-ends then the prototype, but that was it. They also asked about some changes, a question that would have usually caused my ulcer to start. Each of their requests was a trivial change, taking me a few minutes to incorporate.

I remember walking out of that meeting realizing I had taken a huge step in my career. We are still doing a lot of work with BigCo, and they are a happy client. I no longer fear change, and am still continuously improving.

Well, I didn’t mention DDD, because I haven’t gotten to it yet (it’s on the list, which seems to get longer all the time) but I hope you’ll consider my contribution. Either way, I had a lot of fun writing this.

We've just finished tallying up our votes for the Great Devlicio.us Giveaway and we are pleased to announce that the winner is Glenn Goodrich. We had enough entries to make the contest worthwhile and we decided to give prizes for every story. Everyone got one of the books in the original list and the 2nd place also got Visual Studio Team System. You see? I told you that you should tell us your story.

Some people asked if there will be a contest where they could submit horror stories instead of success stories. Well, I'm considering running a contest for that, but I'm afraid the prize will be limited to a bag of Doritos.

Glenn runs a very nice blog and his story, which will be posted here tomorrow, shows that the quest for a better way to develop applications or, in broader terms, the constant pursuit of improvement should be in our DNA.

I'll quote from his story:

... Head First Design Patterns, which was another huge A-HA! moment for my development career. I now read blogs everyday and have at least two books going at any moment in time. I read about Continuous Integration and CI Factory, as well as NHibernate and other OR/M frameworks. This was my first steps into Continuous Improvement.

...I was relaxed on demo day, confident the software was solid. I had no anxiety about getting off the beaten path, which was new for me.

Congratulations to Glenn, we are very happy that the prizes are being given to such deserving hands. You make us proud, Glenn.

Be sure to check back tomorrow with the full story.

Let's say you are hired to help build or fix an application. You contract is not for hire and you know that after 3, 6 or 12 months you will be gone to repeat the same cycle elsewhere.

I'm sure we have all seen contractors that will do just about anything to complete the task in the allotted time span, sometimes in detriment of the code quality and maintainability. I'm also sure that if you're reading this then you probably care about this enough to avoid replicating this pattern.

But here are some important things that might go unnoticed in the above paragraph.

• Define The Task
• Define Quality
• Define Maintainability

The Task

In my limited experience, I'd say it would be shocking to be hired to just write code regardless of any parameters, as long as the deadline is met. I don't expect to hear from my client "I don't care if what you write is absolute garbage material but it needs to go live in 6 months."

Even if the client is very much driven by the deadline, even if the client doesn't say it out loud, there will always be an implicit expectation that our solution will have a minimum of quality to survive the planned life time.

Our task is never to just write code. They could have hired a high school intern if that's all they wanted.

Quality

I think the quality of a software product is directly related to how well the product adheres to the specifications. Oh, no, specifications. One more thing to consider.

If we're lucky the specifications will be available and include not only the product feature list but also architectural needs, expected maintenance and upgrade pains.

Again, we are not being given carte blanche, even if it sounds like we are. Maybe the client doesn't know how to communicate that to us, but we ought to know that our design needs to accommodate changes and lay on top of a maintainable platform.

Maintainability

The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment - IEEE Standard Computer Dictionary

The IEEE definition above is fine but, after a discussion in the last Chicago ALT.NET meeting, there seems to be an important omission here and the main reason for this post.

Maintainable by whom?

The same way our proverbial consultant from the beginning of the post could deliver abominably graded solutions and run away, so can we — with all our shiny, fancy-pants design and tools.

We have the responsibility of designing a solution that is maintainable by the client with their staff of with realistic chances of finding other contractors that can take it on (not necessarily us all the time.)

We have to weight our design decisions and desire to apply the better tools and architecture against the existing scenario. When discussing the possible solutions with the rest of the team that's a good opportunity to assess what kind of team we have to work with (or work for.) If the scenario doesn't look good, there at least two things that can be done:

1. Discuss the problem with the client and suggest that the staff would benefit from some training or mentoring, so that we can apply a solution that can be maintained more effectively. Training and mentoring may be strong words, sometimes a few informal sessions with the team can go a long way.
2. If the above is not possible, then the responsible thing to do is choosing a design that the existing team will be comfortable maintaining after our departure. Knowing when to suppress your good intentions is also an important quality of a good consultant, I think.