Branches Getting Burned

I can't say that I didn't see this coming, but I met resistance today when I proposed branching the VSS project that I'm working on. We're in the middle of production fixes and implementing new features and the source is getting quite ugly. We deployed code Monday and had to remove some code post-haste as it was for new features that weren't finished.

The PM cited realistic reasons: poor team communication, VS.NET web project inconveniences, and VS.NET and VSS integration issues make branching an unappealing proposition. They had a terrible time getting the project into VSS to begin with. And the PM, rightfully so, is timid about trying that in the middle of a project. Not to mention that web projects, IIS, and VSS don't really get along to begin with, it would be a nightmare trying to get it all setup with the different branches.

To be honest, I accept the PM's remarks and can make do with our situation since I really have no other choice. The sad thing is, however, that it really doesn't need to be this way. Every one of the complaints has a solution. Team communication can be fixed and, at a minimum, is solved by individuals THINK!ing. Think about where the work you need to do is applicable before going code wild. If you don't understand, ASK! There are several workarounds to working with web projects, like making them class libraries instead. Hopefully, this also solves the VSS integration problems as well, but if not, may be it's time our SCCS grows up.

The truth is our process doesn't allow for this style of development and it's becoming a true roadblock in moving forward on projects. Unfortunately, it feels like we're going to have to hit the roadblock before we wise up to the true problem...

Striving for Agility, [Not]Willing to Settle for Mediocrity

In my "The More You Know" post, I mentioned learning agile methodologies and test-driven development. Today I stumbled upon Jeffrey's post entitled "Advocating Agile in a CMM or MSF shop" and said "wow...that's me". I'd like to share a little bit of my experience thus far.

Beginning this year, my department was told that if we can't show we are profitable, or the potential to be profitable, changes will be made...Given that, my "Mr. Fix-it" personality came out and began investigating the idea of becoming Agile. It seemed like, and still does, a good fit as, in the past, our biggest downfall has been under-estimating projects. We'd propose (read, promise) software at $50,000 and, in reality, it would be a $150,000 project. When higher management hears that, magnifying glasses come out and faces get more red than the general ledger.

The tune around work hasn't changed much since the beginning of the year. Projects are creeping out of scope and the books aren't turning green anytime soon. We're still bidding and proposing projects in a waterfall-like style overall, though some have taken a more Agile approach based on some customers having limited budgets. In those cases, we've taken what they've asked for and show them what we believe, given our current knowledge, what each feature will cost allowing them to see the whole picture and make informed decisions about what they can afford not to have. We've even had one customer confront us and ask "have you ever considered an Agile methodology?"; I/we still don't know if someone knew a hypeword and was just throwing it out or if they were serious. Given what I know about the project, I say it's 90% likely they were serious.

When you get down to it, the whole situation stinks, honestly. I've mentioned to my manager that, if we're serious about this, I'm not the one to implement it as I clearly don't know anywhere near enough to do it and do it right - even though I'd honestly love to... My fear is that, while we can justify - at a minimum, argue - the cost of getting mentored in an Agile methodology, only that "team" will be involved and not the whole department. Granted, this may be a good and, sadly, realistic approach, my real fear is that the knowledge won't get transferred and we'll just as ready go whitewater rafting all too soon. I personally believe immersion is the way to go. Open the flood gates and soak it all in. But I realize that can be a very impractical approach since I can't see any manager signing off on offlining an entire department for a week, or two.

I really feel like at I'm at one of the largest crossroads of my professional life. In front of me, I can stay - physically, mentally, professionally - where I am and just "settle" for being mediocre, realize that it will happen when it's right, and continue down the failing waterfall. I could also go right, embrace my new found faith in Agility, push until they give or I push out. It's at that point that I find another place to belong and try the same thing, since I have no knowledge of an Agile company in my area.

The last option is going at it on my own...and considering how young, relatively inexperienced, and spread-thin I am right now, doesn't seem to be a realistic option. On top of that, I'm really emotionally attached to my current digs...well, at least the people and projects.

Needless to say, something's got to change. And I won't settle for mediocrity.

Exceptional Exception Handling

I have a response to Jeremy's rant...

I'll admit up front that I'm an infant when it comes to agile/domain-driven design stuff, but this is something that a coworker and I have debated for sometime now. Long story short, the application he's migrating to .NET (and NHibernate, DDD, etc.) uses exceptions within the domain object property setters to send back validation error messages to the user. The exceptions themselves don't make it to the ASPX, but are still used as the "delivery" mechanism.

So, for example, if a Person's FirstName is required and cannot be longer than 50 characters, the setter would throw an ArgumentNullException or ArgumentOutOfRangeException respectively. Somewhere in the MVC layer of the application (I think the Controller, but I'm not sure), all exceptions are caught, translated (so an ArgNullEx will be translated to "FirstName is required") and the error messages are displayed to the user. He also added some attributes to help the MVC layer detect which data members are required, have length requirements for strings, etc. Since NHibernate is not able to discover this information from the database - at least, not that we've found.

Personally, I'm at a stalemate on the whole design. While it is intuitive and follows the DRY (Don't Repeat Yourself) pragmatic principle - to a degree, since there's duplication in the mappings and the database - and is centralized in the Controllers, any View implementation will automatically "enlist"(?) for validation. On the other hand, I feel this is breaking the idea of "Separation of Concerns"; I'm not sure if it's the Controller's responsibility to validate the data that's being marshaled to/from the Model or, for that matter, if the Model should be concerned with performing the actual validation. Is the Model just a plain-old data structure with no logic? There's also the design consideration I've read a few times around stating "save exceptions for exceptional cases/conditions"; does data validation fall under that umbrella?

Less "annoying" is the fact that we're (I really mean he, I just consult...and I "[have] been known to be wrong...from time-to-time") not using any of the ASP.NET validation controls as they can be cumbersome when there's the idea of separate logical forms and such...but that's really minor, when you get down to it...

Anyway, those are my thoughts. To surmise: where DOES validation logic belong? Obviously, it is easier to maintain in the higher-level languages...but where in your app's architecture does it really belong??

Branching Out is Good For You

I learned an invaluable lesson today: branch your code, especially when it's in production.

A project I'm working on has been in production for about a month now. I/we are following up on bug fixes as well as implementing features that did not make the original release. Did you see the hole we fell into? We didn't branch our source code before/after deploying the release to production. So now, everyone is working on the same codebase that's in production that includes both bug fixes AND new features.

Obviously, this bit us today when we went to deploy some fixes and it broke the application (in production, mind you) because one of the changes did not make it to the production database as it was part of the new functionality. Had we branched the project into a Production branch and Release 1.5 (or your name d'jour), the bug fixes would've been isolated from the new features and, theoretically, the deployment would've gone a lot smoother. We would then be able to merge the two branches when the new features are to be released and, at that time, we'd be able to include the fixes in the Release 1.5 branch as well....given VSS didn't destroy it...

Someday, our processes will be automated and we won't have to worry as much about this sort of nonsense that eats valuable resources from our projects...

VSTS2k5 Beta 2 VPC Available

If you're an MSDN Subscriber, Rob Caron notes that the Virtual PC Machine that was distributed at TechEd is now available for download. It's fully configured OOB, so all you need to do is point the VPC console at it and let it rock.

Sweet.

How about 3K LOC?

Jeremy recently blogged about identifying "Blob" classes. The "core" of the application I'm working on right now has a "Common" object. It spans 3000 lines of code, all of which are contained within Shared/Static member functions. It's the canonical example of Singletonitis let alone failing the "one class, one responsibility" test.

It's times like these I wish my Refactoring skills were much, much sharper...

The Effects of Change on a Team

YAT: Yet Another Thesis...

After much tripping over thoughts and ideas, I think I finally have this post straight. There's been A TON of changes in my company over the past year. You name it, we've done it. Not all of the change has been structural. People have changed; whether it's personality, life situation (20s-30s life styles, etc.), or work assignments, everyone within the company - specifically, my group - has changed. However, the most interesting aspect, I feel, is the change in self and team knowledge.

Looking back, one year August 1st let's say, I can say without any reservation that the software we developed then is nowhere the caliber or quality that it is today. No, unfortunately, I can't proclaim 90% or better code-coverage results or even 50% as we have no vehicle by which to collect such data; alas, we are not test-driven. Even without empirical data like unit and functional test results and code coverage analysis, the amount of knowledge that has been gained over the past year, I feel, is quite staggering.

A year ago, I personally, was mildly intrigued by this whole test-driven development "modality". Design Patterns and the-like were fascinating and incomprehensible. None the less, knowledge was gained in these areas. Good teams communicate and facilitate communication amongst members so that new, valuable knowledge is continually transferred and shared with the rest of the team. If anything, this, I feel, is the single largest change that my group has seen.

And for the better.

Such positive changes and experiences, I feel, need to be properly fostered, "pampered", and reinforced to avoid spiraling back into the depths from which we came. It must be realized that, while it may be unavoidable, at times, to keep a foot rooted (temporarily) in past, progress need not be hindered.

Which leads to my question: how do you "manage" the effects of changes that team experiences? For example, the single most difficult experience I have had, post-change, has been working with legacy code. It is, quite possibly, the most depressing experience I have had. The changes I have experienced over the past year cause feelings of panic, anxiety, and near-nausea when looking at and attempting to work on this project. I so badly wish to scrap all code, burn it, and completely rewrite the application top-to-bottom. I won't. I can't. Resources won't allow it. Yet it is against my ethics, as I know I am capable of producing better software, to conform to the current codebase.

How do you manage to prevent the spiral yet still facilitate an efficient work environment?

XMLUnit Framework

I stumbled upon Unit Test Frameworks while we were out this evening and it mentioned numerious xUnit test frameworks. One of which was XMLUnit. I have not taken the time to review it, but there apparently are Java and .NET versions available.

I still look to post on the topic, so check back some time soon...

FIT Article on MSDN

I'm glad my family keeps everything. While I haven't verified this yet, I believe if I needed, for whatever ridiculous reason, the January 2000 issue of the MSDN Magazine in print I could find it with relative ease. Having said that, stumbling across the February 05 issue was as easy as sitting down in the living room. It was this weekend that I discovered I missed an article in that issue discussing the concept of empowering customers with Excel to produce FIT fixtures for integration/acceptance testing.

Overall, it was a decent article. Stott did a very good job of presenting and introducing FIT and the need for it as a tool for automating acceptance testing. I personally feel that too much time was spent covering how to build your own FIT fixture runner, but it was pretty much a requirement given the route his article took.

In related FIT news, a book devoted to FIT was recently published by Ward Cunningham and Rick Mugridge, if you weren't aware. Cunningham was the author of the original FIT framework. You should be able to obtain a copy now with relative ease; I ordered a copy in mid-June and even though the publish/availability date said 7/5/05 I did not receive it until mid-July. I plan on tackling it next, as soon as I finish Pragmatic Programmer.

New MS Patterns & Practices Papers and TDD/Agile Security Woes

Two new, to me anyway, releases from Microsoft's patterns & practices group:

• Threat Modeling Web Applications
• Testing .NET Application Blocks (TAB)
  

The Threat Modeling guide is new this month and testing has been out since January '05 apparently. The TAB I found to be an interesting document. I use to be enthrawled by the DAAB, but that has since subsided. I'll probably review this one in more detail, just because I feel the Application Blocks are not going to go away - which, should not be infered as a bad thing.

The authors and contributors of both mention Agile methodologies (funny, as today I was pondering how threat modeling and such could/should/would be approached by an Agile team). While the threat modeling document, I feel, mearly mentioned Agile methodologies - plugging MSF Agile, I might add - and did not really consider how it might be incorporated.

While I'm starting to favor less up-front, big design more and more, I have trouble ignoring the importance of threat modeling and security considerations in developing applications. Agilers, if I may coin the term, I feel, focus more on getting the immediate feedback and less on design. Great. But what happens now that you have all this wonderfully unit and acceptance tested software that, since it is now so open for extension yet closed for modification, risks having malicious code injected into it? Playing devil's advocate, I mean, everything's just an interface, right?

Maybe I'm over-simplifying things, but I don't think that I'm all that far off. It would be great to know if anyone else has thought about these aspects and to know what their actions have been to combat them...

"The More You Know"

...is not neccesarily "half the battle"...

I feel as though I've been going through a really rough stage in my professional life. The biggest struggle that I am facing is the fact that I feel as though there's a lot of stuff out there that I'm really, really excited about and anxiously trying to [find the time to] learn. Really, I'm mean my head is almost spinning. Take a look at this list - in no order nor comprehensive:

• Test-Driven Development (.NET Style)
• VS/TS 2005 and Framework 2.0
• Effective and Reasonable Licensing of MS development tools
• Customer Driven Tests/Acceptance Tests with FIT
• Agile methodologies (Scrum and eXtreme Programming)
  
• Continuous Integration/Build Servers
• MCAD/MCSD Certification

The most frustrating of them is the last item, as I've already past one test, but mistakenly was credited to my father because the testing center (my own employer) thought I was him (same names...) and it's been over a year in trying to resolve it...

.NET 2.0 is going to be amazing and I'm really looking forward to it - if my company can afford to upgrade, which is where the volume licensing comes in.

The remaining topics can all be gathered under the umbrella of agile software development. My interest in these topics started my senior year in college when I took an intro to software engineering class. I considered investigating a related masters, but me being the over-achiever that I tend to be only looked into the program at CMU, which is crazy intense and I really didn't have that much motivation to persue it nevermind the prerequisits.

When you get right down to it, I'm really interested in the whole process of the Agile methodologies and the amazing tools that are available to help groups in implementing them, such as CruiseControl.NET, NAnt, NUnit, and FIT to name a few and, [un]fortunately, they're all related. So, you really can't just pick one (well you can...work with me people!). Personally, I'd like to roll my own CC.NET for the experience, but I fear that'll go down the path of all my other rather ambitious software project ideas...

So, for now, I'll probably have to work extremely hard to focus my effort at the easiest and most (immediately) rewarding: finishing my MS certifications. Within that, I can be working on my TDD and refactoring skills, since my day-job won't be studying/preparing for the exams. This, hopefully, will flow into learning Framework V2.0 and related tools. This doesn't leave much room for the other facets of Agile methodologies that I've mentioned; hopefully, I will be able to continue the work that some of my team members have started in this area, as time permits.

This wasn't meant to be an introspective professional review or assessment, but it kind of turned into one that resulted in a plan...at least on (digital) paper...

Virtual PC/Server Bliss

I don't intend for my blog to become my personal reminder, but I'm sure I'll forget about this one...Aimlessly browsing the web tonight, trying to muster the will to close Firefox, I came across a post on the wonderfulness that is Virtual PC differencing disks. My team has started giving regular FYI presentations and demos during our monthly staff meetings and I'm going to give a talk on VPC and Virtual Server. You better believe this will make it into the demos!!!

"I Like Your Style" NAnt/#develop

A coworker came over to me and we were discussing VSS and shadow folders. I mentioned to him, hinting at continuious integration and frequent releases, that it wouldn't take much to have a build get fired off when a file is checked-in because all you'd have to do is watch the directory(ies) for changes. And if you break the build, you'll be flogged, no questions asked. Surprisingly, I got a pretty positive response from him.

This led me to the NAnt web site. I hadn't been there in a while but, apparently, back in April, the guys on the #develop project introduced NAnt integration with their product. I watched the video that's available and it's pretty sweet and really well-integrated. I'd really like to consider these two products but with the lack of WYSIWYG support for ASP.NET and source control integration (VSS or otherwise), I don't see my group favoring it over VS.NET any time soon.

Still...very nice...

"You Doin' Me Wrong" VSS/VS.NET

Rant warning...

So I know we all have our reasons for hating Visual Source[un]Safe, but I've personally had enough. My list of reasons is pretty long:

1. Doesn't play nicely with web projects that exist outside of wwwroot.
2. Doesn't play nicely with web projects that exist on IIS with mutliple sites
3. "Get Latest version (recursive)" within VS.NET 2k3 doesn't always guarantee you that you did, in fact, get the latest version
4. Files that aren't in the solution/project but are in VSS are not pulled down even if a dependency exists in one or more projects
5. Why do I need a ".root" project in VSS?

That's not really an exhaustive list, by any means. If anything, the most annoying VSS/VS.NET 2k3 "features" are items 1 and 2. I can't tell you how many hours I've spent at work getting projects/people/PCs setup and its never the same experience...Unfortunately, I'm not a technology decision maker or I'd suggest something like SVN/CVS or some other solution. Even if I was a decision maker, it would be an up hill battle because of our current investment in the terribliness in VSS...

But I digress...

"Soul Vaccination" for Data Access Layers

Sorry, but I have to play the devil's advocate...Jeremy Miller recently blogged on Quarantining ADO.NET code to a reusable, separate layer; I couldn't agree more. I've been tasked at work with finishing an ASP.NET application that was written by subcontractors that - well, let's just say I think the result would've been different had it not been subcontracted. One of my biggest peeves with the application is that, with my TDD enlightenment, it's nearly impossible to unit test anything. It very well may not pass DataSets around, but since the ENTITIES are not really ENTITIES (no use of ASSOCIATIONS here folks), the application might as well just pass on the low-level System.Data objects because every action results in at least 2 or more database trips.

Therein lies my concern: over-, and incorrect, use/implementation of O/R persistence. My fear is that O/R persistence is becoming a buzzword or hypeword and that they'll go the route of Web Services. I'm guilty of it myself, I'll readily and openly admit it. I've uttered the phrase "man, if project XYZ were using NHibernate, development would be so much easier and it would be testable blah blah blah" many times and not just for the project that I'm on right now. O/R persistence frameworks empower developers and "with great power comes great responsibility"; we need to be responsible and know when the time is right to employ an O/R framework and when a well-crafted DAL will suffice.

So, in summary, I completely agree with the point of Miller's post: DAL code should be abstracted and encapsulated at a level as low as possible to minimize the possibility of falling into the fate of the 900 ASP file application he mentioned. However, an O/R framework should not be the end-all-be-all solution. If anything Newkirk and Vorontsov's TDD book is a testament to what can be done with a well designed and tested application.

Back, Once Again...

I was out on vacation last week and work and personal life have kept me from being able to contribute more here; I'm looking to make up for it soon.