Something Smells

I have been hunting around for some code generation tools to play with. I"m really looking for something very simple like the Ruby on Rails generator. I've come to the conclusion that no one want anything easy in the .Net world. I've also been looking at some DALs, ORMs, etc. Really, most of the DALs and ORMs offered in the mainstream are just WAY too much. I really have to think that if you need some of the more advanced features of these systems you may want to relook your design. Heck you may want to read up on doing "The Simplest Thing that Could Possibly Work." Anyway, I use Castle's great framework called ActiveRecord . It's so simple that you really don't need code generation. As long as you keep things simple when you begin using it, you can slowly move towards the advanced stuff (if you really need it). So what was I REALLY hunting for. I'm really looking for a database schema upgrade (or migration) that's as simple as activeRecord. A...

I'm starting a new Open Source project. It will be a Planning Poker game for distributed teams. Here's the blurb on the project site: The planning poker on rails website will allow distributed teams to play planning poker. It will track user stories and the points assigned to each story. It should also allow for quick access to archived stories as references for future planning games. Each player should be allowed to place a card (estimated effort). Once the cards are all placed the application will reveal the estimates to everyone. If no concensus is made then each player will have the floor to make comments. As each player makes his or her comments the application will move to the next player. Once all players have no more comments OR a player presses the VOTE NOW button. The computer will take another vote this continues until concensus is made OR all player agree to table the vote. Before you google it...YES another project already does this. So, you may ask, "why...

I just read an article that takes a very cynical view on XP and Agile methodologies. I wasn't allowed to comment without signing up for something so I will comment here. Check out the post " On the trail with the Cowboy Coders ." I think the author misses the point of Test Driven Development (TDD) and the XP practices, as a whole. His suggestion that XP is "Cowboy Coding" couldn't be further from the truth. In fact (this is always said) XP takes a great deal of discipline. All of the practices and values must work together or you will never reap the benefits of XP. In particular, TDD is not merely a way of making sure that your code is tested. This is a common misconception amongst those who have been newly introduced to TDD. The reality is that TDD serves as a design tool. Now, XP does "shun" up-front formal design. But XP does not ask us to do "no design". The design is expressed differently....the design evolves. Let's take a look...

Well, It's been a while since my last post...trust me I've been busy! I've been reading quite a bit about Agile Developmet trends. Always ready to learn some new nugget of goodness. I always find myself asking, "What is really, really important to an agile project?" Is it simplicity? Test Driven Development ? Pair Programming ? Evolutionary Design? One of so many other values and practices ? Of course my first response is, "it's all important, XP requires a tempered application of ALL the values and practices." We have so many around us that don't like this answer. They wonder, "where are the controls? What is the process?" My answer is, inevitably, "the team is the control and the process. They are guided by a coach and a good faith effort to provide regular software releases." I must admit that, in business, we need to"know". Know when the software is going to be done. Know when the software is not going to be done...

Tactical Scope Creep In my experience, scope creep is one of the greatest threats to the completion of an iteration. I would even suggest that the most dangerous "scope creep" is the kind inflicted by engineers. Most discussions of "scope creep" tend to focus on the customer inflicted variety. For agile teams, working iteratively, this sort of strategic creep has been managed (see embracing change). The creep we don't always catch is the creep at the tactical level. Have you ever been faced with a simple story and somehow ended up making a Rube Goldberg machine ? Damn the schedule and designed a complex framework in hopes of using it again later? Regretted wasting time on a complex API that did no more than paint your project into a corner? In the end, all of these cases are examples of one thing...tactical scope creep. I myself have never fallen prey to these vices (yeah right). Seriously, I can't count the number of times I was going to write the next gr...

ASP.Net Frustration It's very hard to articulate "why" I am frustrated with ASP.Net. Recently, I found a post that, while not articulating the "why", does articulate the feeling: I think what annoys me the most is that I really like C#. It’s a great language, and the .Net framework is awfully well put-together. I really enjoy spending time with C#, but then along comes ASP.Net like the loud, overbearing, half-drunk uncle at a family reunion, tips over our picnic basket, and ruins everything. - Deane I've tried exploring this subject on many occasions and come to the conclusion that it is a subject best discussed over a pitcher of beer! Before I go on I must give thanks to the guys (and gals?) at the castle project and their incredible Rails Framework Monorail . So, ASP.Net is frustrating. To be fair to many who have bought into ASP.Net, ASP.Net sells itself very well. As a technology it is very heavily driven by marketing needs. The MS sales force wanted...

Castle Project and Monorail I just wanted to give a quick nod to the guys at the Castle Project ! We've started converting one of our major applications to their Monorail framework. For those of you unfamiliar with Castle or Monorail, Monorail is an MVC framework for .Net web applications. It completely replaces the webforms framework with a much simpler (and more powerful) rails style implementation. The project includes an OR Mapper (ActiveRecord) that uses NHibernate as it's back-end. Their ActiveRecord implementation greatly reduces the time it takes to map objects to the database. They support several view engines based on Nvelocity, Boo (brail), string template, and some others. They also have a basic generator for scaffolding and a basic migrations framework is being developed. If you are in a .Net shop and looking to take advantage of Rails/MVC or if you are just fed up with the overengineered webforms model then check out Monorail! Here is a link to my Castle bookmarks...

If you didn't know then I'll tell you now...... I am a huge proponent of XP . I don't much care for Scrum.....it just doesn't work for me, deal with it. I recently read an article " Should a ScrumMaster Give Performance Appraisals? " For those of you who are unfamiliar, a scrummaster is the same as the XP coach. My first thought was, "who else is really qualified?" My second thought was, "yeah, who else is qualified?!" Now, I'm not a big "Performance Appraisals" kinda guy. Just seeing the words makes me feel kinda sick. I've rarely written a performance appraisal that I didn't wish I could change later. Even when I was in the Army (yes I was in the Army for 12 years) we prepared many "Performance Appraisals" called Evaluation Reports. If it was a good soldier we scowered the last years calendar for good stuff he had done. If it was a bad soldier we scowered their folder for negative things to say. All sa...

I just read an interesting article that breaks down the Agile planning process into 5 levels : (This is slightly modified) The Vision The Roadmap The Next Release The Next Iteration The Next Day Essentially, each agile planning session occurs in one of these levels. With each level dependent on it's predecessor. Ideally, you need a vision before you have a road map, road map before you plan the next release...you get the idea. This really made sense to me. For years now I've used a somewhat complicated model to describe what it is we do. This model, oddly enough, can be easily distilled into this 5 level process. In the table below I have identified each level of planning with WHAT being the expected artifact and the WHO generally describing the participants: Level What? Who? The Vision A Vision Statement Chickens The Roadmap Roadmap (duh) Chickens The Next Release Rele...

Problems with modules2 and CVSNT .... CVSNT has an interesting feature not found in the generic cvs server...." modules2 ". I've been using this feature for quite some time. It offers some interesting options when compared to the standard modules feature in cvs (and cvsnt). I am not going to cover all of it's features since those can be found on the cvsnt web site ....suffices to say that modules2 allows you to define alias modules in cvs using a sort of regex language of expressions. For a long time I had my guys using modules2 strictly for checkouts done by our build server. We could wrap up all the dependencies in cvs under a single "alias" module. So far one downfall has been that modules2 modules don't support the history command :P Oh well, it still made managing dependencies easy. I've always shied away from letting engineers use modules2 locally because of potential issues with check-ins and creating new modules. Recently some of the engineer...

Automate, you must! Recently, at work, we rolled out a new version of one of our major web applications. Until recently rolling out changes was a major undertaking. Over the past few years it's evolved into a much more reliable system that takes about 11 minutes! Here is a quick chronology of the evolution of our deployment system: Pre-deployment system Believe it or not our earliest versions of this product (many years ago in a galaxy far far away...etc) had no deployment system, let alone automation. Unless you considered me or some other guy making a change and Ftping it to the live site for testing, a deployment system. These were carefree times with few users to be annoyed by the occasional bit of downtime. Also, we worked in mostly interpreted languages (ah the good old days!) Let's get a testing server! As we grew and more users were around to pay attention to our untested new "features". We decided a test server was in order. The first iterations of the test s...

"mmmm...code smell this has". I wish it was original but a co-worker of mine came up with it while we were making up a fictional Agile Jedi (yoda kinda). Some others were, "YAGNI this is" and "Refactor you must". Having pulled our team, some kicking and screaming, into the Agile world. I have to wonder what has it gotten us? Also, what do we still need? Hopefully, over the next few posts, I can explore this. I know we're not perfect but I believe we're on the right track. I'd like to start my blog by examining some of the lessons I have learned. Lesson 1: You need a Coach! This I can't stress enough! The agile approach depends so much on having a coach. Just like a viking war ship needs a guy beating a drum, an agile team needs a coach. The coach keeps the team on track. He Reinforces and evangelizes the agile (XP) practices. The coach is shield from scope creep (YAGNI). The coach is often the tie breaker. The coach even takes care of some...