Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert
Brendan Enrich has an interesting post on organizing the trunk of the source control for a system. Some of the principles include:
I like what I see. I think this type of structure should be widely used across many types of .Net solutions.
I’m giving my “TDD, DI, and SoC with ASP.NET MVC” talk at an INETA user group talk next Wednesday.
If you are in Bloomington, MN on Feb 18th, stop by and say hi.
Date / Time:
Wednesday, February 18 @ 5pm
Topic:
TDD, DI, and SoC with ASP.NET MVC
Description:
Spelled out, it is test-driven development, dependency injection, and separation of concerns with Active Server Pages .Net Model View Controller. This talk will dive into how to design a presentation layer using ASP.NET MVC.
In today’s industry, TDD, DI, and SoC are proven concepts that lead to more maintainable applications. Along with demonstrating how to use these techniques with ASP.NET MVC, we will discuss just what concerns should be separated. This talk provides a unique perspective on separation of concerns and uses TDD and DI to make it happen. MvcContrib is used in all the demos.
Presenter:
Jeffrey Palermo – Headspring Systems
Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems flying in for an in-person presentation from Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net, Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, INETA speaker, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate.
About our meetings:
When:
3rd Wed of Every Month @ 5pm
Where:
8300 Norman Center Dr., Suite 950
Bloomington, MN 55437
Sponsored By:
Just a quick note for folks interested in some of the positions with Headspring Systems. I’m very picky about those I hire, and those who have the best luck with the interview process are those who already:
I love recruiters, and I give them leads whenever I can, but the type of employees I hire for Headspring are typically not what recruiters have to offer.
If you are interested in a job, the bullet list is a great place to start. For those not in the Austin area, it’s worth noting that we focus on Austin only at the moment and work in person within the company as well as within clients. No remoting here.
With the imminent release of ASP.NET MVC, the industry is buzzing about this new way to write ASP.NET applications (not really new – i.e. MonoRail). Lots of folks are already intending to adopt this library when it is released, so Headspring Systems is sponsoring a free afternoon of ASP.NET MVC framework training at the Microsoft office in Austin, TX. Make sure to register for this event because there is a limited number of chairs.
Details:
Thursday, February 19, 2009 from 1:00 PM – 4:30 PM (CT)
Microsoft office classroom, Austin, TX
An afternoon of Asp.Net Mvc training that will go into the insides of the Asp.Net mvc framework. Students will learn how to use this framework to build a real application. Benefit from the work that Headspring Systems has done with developing applications on the framework for its clients and learn what they have about the do’s and don’ts on Microsoft’s new web framework.
The following topics will be covered:
For More information about Headspring Systems goto www.HeadspringSystems.com
Headspring Systems offers Agile Boot Camp™ for .NET classes
Jeremy Skinner and Eric Hexter went swiftly to work upgrading MvcContrib to the ASP.NET MVC release candidate. That release is up on CodePlex, and CodeCampServer has two failing tests now. We’re hoping that the Url Generation bug in the RC will be fixed soon so we can release CodeCampServer RC1.
In my last post about ASP.NET MVC, Jeff Gonzalez referred to WebForms as “Classic ASP.NET”. I had to take notice since when ASP.NET can out, we spoke about “Classic ASP”. This mere reference is interesting.
His comment goes on to talk about how ASP.NET MVC isn’t mature and not as “rich” as WebForms, but it also mentions the risks around using beta software for enterprise software.
My comments around this relate to the risks of using new, unproven, software. SQL Server 2008 is still not widely adopted even though it is fully supported by Microsoft because folks are very leery about upgrading something as critical as a database server. The same with server operating systems. I hoster I like very much, Rackspace, still promotes and sells many, many Windows Server 2003 licenses (including some for my clients).
Software tools, libraries and frameworks are a bit different, however. First, when you have a new project, it is wise to consider what version of libraries will be supported when the new project goes into production. To some extent it pays to attempt to avoid being a version behind even before the software launches. This is the case with ASP.NET for me. I know where this framework is going, and I trust the reliability of the proven ASP.NET pipeline of handlers and modules. I also trust the stability of IIS, on which it runs. The new paradigm is when ASP.NET needs a handler to handle a particular request. This is where the change in development is. For me, this mitigates risk around scalability and robustness because the foundation is already proven by 8 years of production use.
The other risk is around bugs. When your enterprise application goes into production, you want to be able to depend on your chosen libraries. If your test feedback cycle is long and expensive, there is not easy way to accomplish this. If, however, you have test automation, you can have high confidence that the software works as intended every step of the way. Regardless if the libraries in question are from a huge software vender like Microsoft or a single open-source developer, I consider it a must to have high test automation coverage to mitigate not only the risks of local software defects but also those within libraries on which your software depends.
Another consideration about maturity is documentation, and this is nothing to sneeze at. With 6 books on ASP.NET MVC slated to come out this year, the information will be there, but it is not there now, and many teams will need training on how to make pages with the new version of ASP.NET. This is definitely something to consider. Also consider that many projects successfully use log4net, NHibernate, StructureMap, and other open source libraries without full books written on the topic. In these cases, local documentation is sufficient. As always, you have to decide for yourself given immediate constraints.
The new version of ASP.NET is very, very close. Scott Guthri just announced that the RC was publicly available. I’m pumped about this release not only because of my book, but also because this new release makes delivering with ASP.NET sooooooooooooo much easier than WebForms. One piece of functionality that is not spoken about so much is the ability for a partial view to use a layout (Master Page). That’s right, folks. You can have a partial that only displays a snippet of a shopping cart, and that partial can use a master page. Then, the resulting markup is within the main view, which may also be using a master page. All in all, we just use ".aspx" views. We don’t even bother with ".ascx" views since they don’t provide any additional advantage, and they don’t work with master pages.
Great job to the ASP.NET MVC team.
Prediction: ASP.NET MVC will supersede WebForms for new project development within 2 years time. Web Forms isn’t going away by any stretch, but for new projects, I think MVC is going to edge it out, even if just 51% to 49% of new ASP.NET projects.
In January, I had the privilege of participating in a panel at Agile Austin with executives leading other software organizations around Austin. David Anderson also dropped in while he was in Austin.
Throughout the question & answer session, one theme became clear. The audience wasn’t clear on what agile is and what agile is not. So many folks have attended Scrum training that I think I can comment on what is being taught (caveat: each Scrum trainer does it a bit differently).
The most popular agile training is Scrum training. In scrum training, there is a lot of talk about the development team, the product owner, and the scrum master. There isn’t, however, a lot of talk about management. The scrum master is not a manager. It is intentionally defined as a facilitator who has to facilitate without direct authority. Every organization has management, however, but Scrum doesn’t really speak to that. I think this is a big gap with it. Extreme Programming doesn’t either, but it doesn’t pretend to be a project management methodology.
Agile is all about delivering frequently and refining as you go. Agile doesn’t have a set of dogmatic practices that you must adhere to. Every agile team will have a process that is unique because each has different business goals and different people. The team needs process. Larger projects need larger processes. Whole Foods is a very agile organization, and it has tons of processes to make it all work seamlessly. I have encountered some who feel that agile teams have to light on process. I believe that the team needs just enough process, and it’s probably just a bit more process than the average “Certified ScrumMaster” would think.
By now, we have all heard stories about the “agile” teams who adopted scrum and then subsequently burned through a year’s worth of sprints and still delivered nothing. The magic fairy dust of scrum is wearing off, and the industry is starting to realize that in any given project, success depends on the good and passionate work of the people involved.
All in all, it doesn’t matter where good ideas come from: waterfall, scrum, extreme programming, lean, FDD, or the next methodology that comes along. Good ideas are good ideas, and I strive to find them wherever I can.
Practical agile software delivery is hard. HARD. It requires confronting problems head-on, even when those problems are organizational. Short iterations expose the problems. Solving the problems makes them go away. The absence of problems leads to effectiveness. Rinse, repeat. A project will succeed or fail based on the people involved, not the “official methodology” used in the status report.
For four years, I’ve been using the point system for estimating software effort. This post is an attempt to convey all the variables involved in estimating software effort. I’ll also touch measuring effectiveness of a software project.
First, as a manager, I want to know if my software organization is being effective. Furthermore, I want to be able to measure each team in my organization and do some comparison between them. What is the metric by which I should measure them? Also, how do I measure and communicate improvement or degradation in effectiveness?
Many people have wrestled with this, and I am just one of them. I reached the conclusion that points cannot be used as a metric of effectiveness, and I’ll illustrate why.
A “point”, as used for software estimation is a measure of effort. It is a relative measure of effort, and it’s context is completely within a single development team. One team’s point is not the same size as another team’s point. Because a point is relative within a single team, it can only be used to infer information about that team.
It is tempting to use a point as a measure of value delivered. As a manager, I want to know how much value is being delivered because my goal is to maximize the value delivered within a given iteration. I’m still left with the problem of how to measure value. This post will not answer that question since that is a very holistic topic and not isolated to software development.
Sometimes I would like a point to be a measure of value. If it were, then I could just mandate more points delivered. As a manager, I can do that. I can mandate that the team deliver more points per sprint. The team, in self defense of an non-actionable request, will deliver more points in the sprint. . . but I will see the project progressing at the same rate. Because points are relative and not rooted in anything concrete, their size is controlled by the team using them.
So I’m left without a measure of value. All I have is estimates of effort.
If I accept that, I will still want some way of knowing if the team is speeding up or slowing down over time. This industry is plagued with teams that slow down. As defect lists grow, the team seems to slow to a crawl. If I’m rigorous about automation, I can keep my teams from suffering that fate (I’ve proven that). However, I still want to know how much my teams are speeding up over time. I know from past experience that agile engineering practices cause software development to accelerate over time as opposed to speed up; however, how can I quantify that?
I could turn to mapping points delivered per iteration. If I measure that over many months, shouldn’t I see an upward trend? That would seem only logical, right? As the team finds better ways to do things. . . as the team forms solid standards around the project and refactors common functionality into standard components within the software. . . shouldn’t the team be able to deliver more software each iteration? The answer is YES, but oddly enough, the number of points stays mostly flat over time.
How can the above be true if the team is actually speeding up? This is because the point is a measure of effort. As time goes by the team finds ways to make delivering similar functionality easier. Because the standards and componentization makes things easier, the effort for a similar feature actually decreases. The effort required to deliver a similar feature is less than it was before. This causes the team to estimate less than they had previously estimated. At the end of the iteration, the team has delivered more, but my graph of points stays flat.
This can be very frustrating, since I’m still grasping for my metric. I need a graph. I need a report. I need statistics about how well my software teams are doing. If a point is a measure of effort, and I have finally accepted this, then it will stay flat over time.
The whole point of this post is that worrying about points delivered is futile in the big picture. Because it is so consistent, it is a great predictor, but it is not open to suboptimization. Points remaining to the next milestone is a better measure because that metric is at least relative to the effort metric. When effort decreases per unit of value, the points remaining to the next milestone will also decrease.
This whole scenario is a bit frustrating, but if you, dear reader, have found the magic metric for measuring project effectiveness, please let me know in the comments.
Mitch Fincher was a student in our Agile Boot Camp, part 1, taught by Matt Hinze, CodeCampServer and MvcContrib committer. Mitch gives a good student’s perspective on the curriculum. For lots of folks, all the buzzwords sound like:
“Blah, Blah, Blah, Dependency Injection, Blah, Blah, Blah, Program to Abstractions, Blah, Blah, Blah, RhinoMocks, Blah, Blah, Blah, StructureMap, Blah, Blah, Blah, Inversion of Control.”
I think this is pretty common, and I think Matt did a good job of explaining how to use these concepts when coming from a place where none are used.
