I actually a while back wrote a discussion on software estimation that someday I'll post.  However, this evening I ran across another item that I felt it worth pointing out.

In general I consider software estimation to still be more art then engineering.  I don't mean this as a complement, I mean that its predictability, which in engineering we strive to keep high, is in reality low (experience people operate closer to medium predictability...) Part of the problem of course is the ability to learn over time and effectively apply the lessons.  The fact is an experience software lead has learned over time how to estimate and may come close but the learning is of a more intuitive nature.  That's why someone will ask 'why did you estimate that X would take 3 days?' and the engineer's answer is the equivalent of 'because.'

So why am I bringing this up, well I'm going to reference one of those people who's blogs I follow in terms of the business of software.  As I've said in the past - if you are working in this industry not only should you be keeping up with technology, but you need to take some time to learn about the business side - and estimation definitely falls into that category.  Let's face it, from an engineering standpoint I wouldn't care if I finished in a week or a month, but from a business standpoint - well that is a huge difference.

With the release of their latest version of FogBugz, Fog Creek has introduced a new feature for software estimation.  In short the idea is that over time as you define and estimate tasks the software tracks the accuracy of an individuals estimates over the course of a project.  It then determines an accuracy factor.  Over the course of several projects it refines this factor.  It then applies this factor to an individuals estimates - for more information check at Joel on Software's blog at: http://www.joelonsoftware.com/items/2007/10/26.html 

On the surface this is a great feature and I like it but a couple notes, not to bash but as a warning since even my first impulse is to say "I'll take 2".  First the estimator (person creating the estimate) can't know what the tool's adjustment factor for their estimates is because they'll probably 'game' it.  That is to say the estimator will consider their estimate and if they know that the tool will double it, well they'll reduce it by some percentage, because of their inate desire (and it may be totally unconscious) to hit some number (generally as low as possible).  After all the estimator says (ex: "I know I was over by 50% last time over the project so I was going to double my initial gut estimates but the tool is going to do that so I'll need to reduce my estimates so that when the tool doubles my estimates they won't be too high.")  The net is this can result in a reduction of the original estimate to account for the tool's automated increase.

The second thing to keep in mind is that the tool doesn't account for the fact that each project is truly different.  If the developer were consistently estimating the same type of task then the 1 to 1 corrolation that the tool applies makes sense.  But if project 1 is say a desktop application and the developer's UI estimates are 50% under and the next project or the third or fourth consectutive project is suddenly an web UI or a pure business interface and as such the developer's estimate is 90% correct - well suddenly the game has changed and in reality the previous estimates shouldn't be weighted as heavily - but how heavily is the question, that 50% and 90% could also be reversed.  The tool isn't magic and it can't account for all of the variables. 

Finally by its nature this tool will always penalize someone who's estimation skill is improving.  The first set of estimates might be all over the map, the next set might be consistently 25% of actual and then if the estimator sees this and ups their estimates by 150% the correction factor of the tool will suddenly make the estimate way over the top.  Something to keep in mind whether your tool is a fancy algorithm or a set of multipliers in an Excel Spreadsheet - the tool is only a tool - you will still need to carry out a reality and business cost review of the estimate.

One of the most highly anticipated features of Visual Studio 2008 is XML Literals.  It doesn't sound like much until you start thinking about some of the ways that you can leverage this capability.  One creative way is to replace code, Beth Massi of the VB Team recently made a post highlighting a little of the power that you can have with XML Literals in Visual Basic 2008.

http://blogs.msdn.com/bethmassi/archive/2007/10/23/avoid-underscores-in-your-multiline-strings.aspx

What's interesting is her post leverages another new feature call type inference which allows her to create the new object with specifically needing to specify details of the type.  She continues the example but just the first section allowing you to format strings without any special characters is pretty awesome.  Of course the syntax <%= %> might give me nightmares of ASP but overall the capability is very cool, and combined with some of the power of XLINQ that VB provides (see Scott Hanselman's post: http://www.hanselman.com/blog/XLINQToXMLSupportInVB9.aspx) VB is definitely looking to simplify working with XML... you know that data structure which is at the core of things like XAML and Silverlight.

Update:
Beth's keeping the XML literal ideas going with her latest post: http://blogs.msdn.com/bethmassi/archive/2007/10/26/xml-literals-tips-tricks.aspx

So the latest industry buzz-term (since it's not a word per say) is MVC.  MVC is a description of a software pattern.  The key to software patterns is being able to speak them and understand them.  I'm sure you've read many articles that mention MVC and you sit there wondering: What is MVC?

So some 'jerk' (you know the type who provides your latitude and longitude when you ask where you are) says to you, "MVC stands for Model-View-Controller and it's the latest in architecture." 

OK, What is a Model View Controller and what do I need to change in my architecture?

This is actually a pretty simple question and as I've said before, outside of major paradigm shifts - the more things 'change' in the technology world, the more they stay the same.  Many years ago - probably before some of you reading this were born we had the concept of a 3-tier architecture.  The idea, which followed on the heels of modular programming was that you should separate out your User Interface from your Business Logic from your Data Access.  (UBD... or reordered DUB) Over time this was called n-Tier because you might have more then one 'tier'.  The idea however was that you had components responsible for these elements.

Well in an MVC model the Model represents your data access, the View represents your User Interface and the Controller represents your Business Logic.  So you have DUB -> MVC - but wait say the formallists, it isn't the same.  So what's the difference?

Well under the n-tier model there were those who subscribed to the idea that all communication had to travel from the User interface to the Business Layer to the Data Tier, and in the reverse.  In other words the User Interface wasn't allowed to directly communicate to the Data Tier.  We tended to refer to people who tried to enforce this as 'jerks' (see above).  Generally those of us developing applications spent hours justifying the fact that in the real world it made sense to have the User Interface directly access the Data tier to retrieve key data and in some cases even for certain key automated updates.  That's essentially the gist of the difference.

So there you have it because people couldn't adapt to this one concept we have a new name - MVC to describe an old concept.  So when someone suggests you re-architect your current n-Tier application to be MVC based and they want to charge you money to do so - well you know how much it should cost - nothing because even if you kept your UI from updating database directly, you still have an MVC architecture in place.... now you can just stop being so * retentive about which components in that architecture communicate.

Its funny we literally created a new name for an old concept, why?  Well the 'jerks' will accept a concept with a new name that doesn't exactly match their understanding of an older concept.  It's literally easier to reaname and remarket a concept then to for some people to update their knowledge.

The preceding is of course a brief comparison - to wit there are several other characteristics of the architecture models I've omitted (such as n-Tier) in order to quickly illustrate the key similarities between these models.  I'm sure someone (see jerk above) will point out one or more such items in the comments...

UPDATE: I should also point out that yes the MVC pattern has probably existed for as long as the 3-tier architecture has. The point here is that it is the latest trend for architects and for many the new description seems like it is describing something... well.. new.  In the past MVC was a common model for application logic but now that more "software architects" are actually learning about software best practices it has made the move to describing enterprise architecture.  The concepts aren't new, just the name being used to describe what we've been trying to do.

Microsoft recently released Visual Studio 2008 Beta 2 (http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx).  Being the type of developer who is always interested in such tools and more importantly currently being involved in a couple Windows Presentation Foundation 3.0 projects I was one of the first to download a copy.  One of the new features of Visual Studio is that it allows you to target your builds at the .NET 2.0, .NET 3.0 or .NET 3.5 versions of the .NET Framework. 

 

My expectation although the documentation doesn’t claim it, is that I would be able to start using VS 2008 while other members of my team continued to use the older Visual Studio 2005 with the November 2006 CTP extensions for WPF support.   I was partially (mostly in fact) correct – but it requires a few ‘tricks’, and more importantly even for true .NET 2.0 projects that isn’t a true statement.

 

The warning shot was fired when I opened the project solution.  The first thing that VS 2008 did was initiate a conversion wizard to convert the solution and project files on the project.  It kept them targeting .NET 3.0, but they would no longer open in VS 2005.  Fortunately I hadn’t checked anything into TFS so I copied the files and undid my changes.  (Note: I later tested with .NET 2.0 projects and the result is the same.  There is actually a reason or arguable merit for this, as I’ll explain as I discuss how to manage this scenario.)

 

So what I then did was take my solution and project files which I had converted and copied out and named them with the original project name plus “2008” on the end.  This meant I still had the original project files and the newly converted files.  In comparing these files it was apparent the scope of differences was minimal – in fact it was mainly a couple strings to reflect that these were in fact 2008 versions of the same file.  So I modified the solution file and instead of referencing the projects in the solution by their original name I adjusted the solution file references to be the other “2008” versions of my project files.

 

I then reopened my new solution file in Visual Studio 2008 and found that my solution would build and was maintainable.  In fact I was able to work in this mode quite literally for a couple of weeks with no issues what so ever.  It then came time to package this project for deployment.  We were using a Click Once deployment model and this is where two issues were discovered.  The first issue was that Visual Studio 2008 Beta 2 did not include a signed .NET 3.0 Framework redistributable package that you can add as a dependency to your project.  There wasn’t much to be done about this but I did mention it along with my other problem to Microsoft.

 

The second issue was that while in the project properties, if I clicked on the Security tab, Visual Studio 2008 crashed.  Not threw an error - it crashed and burned.  As part of being a Microsoft MVP I have access to a shortcut for contacting a couple people on the development team about issues when I’m working with something like VS 2008 Beta 2.  In this case I mentioned my concerns about having new project types, my concern with the .NET 3.0 redistributable and  my issue with the Security Tab for my project’s properties causing Visual Studio 2008 to crash.  This got the attention of Eric.Knox one of the ‘developers’ @Microsoft who emailed me about reproducing the problem.  Because the customer was comfortable with me sending this problem to Microsoft I forwarded Eric a complete copy of my solution files (fortunately it was a relatively small code base).

 

Eric was immediately able to reproduce my problem (which was good) since I was now bothering someone who's time is arguably more valuable writing new features into the product J.  After a couple hours Eric contacted me to tell me what the problem was.  In short when I readdressed my solution file to reference my project files, I failed to also adjust the project references in my project files to do the same thing.  For most of Visual Studio this wasn’t a problem, but in the case of the security tab this caused a fatal error.  Eric was able based on my code to find this in a relatively short period of time – and in the RTM version of Visual Studio 2008 the environment won’t crash if you repeat my mistake.  At the same time however, this is still an error in Visual Studio 2008 and the error message you get may not be the most helpful.

 

The key is you need to be certain to convert the project references in both your solution and project files if you want to develop on Visual Studio 2008 in parallel with someone using Visual Studio 2005.  Aside from the preceding issue I’ve had only one issue (that I’m about to discuss) working this way, and being able to work in Visual Studio 2008 has made me far more productive then I would have been with the Visual Studio 2005 environment and the XAML editor which is almost non-functional (for complex XAML).  In general I’ve just manually added new classes placed in the Visual Studio 2005 versions of the project files to mine and vice versa.  The coordination on that level has been very easy and relatively painless – so if you are in the scenario where not everyone on a team is in a position to move to Visual Studio 2008 simultaneously, I’d still go for it on .NET 3.0 projects.

 

However, there is the remaining issue which appears to coincide with the reason Microsoft is moving the project files forward.  I stumbled on this issue quite by accident when during development I created a new class in the project.  As part of this new class I happened to syntax which is based on the new release.  I didn’t reference any .NET 3.5 libraries but I wrote my VB/C# code using syntax which the Visual Studio 2008 compiler recognized.  However, Visual Studio 2005 and Visual Studio 2008 don’t use the same build engines and as a result when a team member tried to compile my new class the compiler kicked out my code.  So if you are going to attempt this route recognize that although you are still building a .NET 2.0 compatible project (based on the libraries which are referenced) you  will have access to language features that are interpreted by the compiler at build time which aren’t compatible with the build engine a Visual Studio 2005 developer will use.  Again this wasn’t a major problem, in fact it was incredibly easy to recognize and resolve but this is probably the type of issue that the folks at Microsoft were most concerned with when they made it so that the same project file wouldn’t work in both build environments.

 

Finally of note, keep in mind that a new version of TFS (TFS 2008) will be shipping with Visual Studio 2008 along with a new version of Team Build.  Both have several new features that you’ll want to access and since your old Team Build 2005 won’t like Visual Studio 2008 projects – you’ll need to upgrade to TFS 2008 in conjunction with or before you move your developers to Visual Studio 2008, so make sure you start looking at that Beta 2 product now as well.

Matt Gertz of the Visual Basic team has posted an excellent discussion describing the release process for Microsoft's product development teams.  Often as a presenter I'm asked 'how does Microsoft do it?'.  Matt's post does an excellent job of talking about the project management details of managing quality for a product release.

http://blogs.msdn.com/vbteam/archive/2007/08/27/endgame-matt-gertz.aspx

I keep meaning and forgetting to add a link to an excerpt from the latest edition of the Profession Visual Basic .NET 3.0 book.  The editorial staff chose to excerpt a portion of one of my chapters to let you see some of what is new in the current edition.  We of course are already working on the next edition now that Visual Studio 2008 and .NET 3.5 are in Beta 2, but for the time being this book offers some insight into the new .NET 3.0 technologies.

 

http://www.wrox.com/WileyCDA/Section/id-305563.html

 

It's been a long weekend and I didn't get all the work I wanted done, but I thought it was time to capture a couple of the random thoughts that were ricocheting around...

1. There is a technical person with whom I have worked for many years.  We have somewhat similar pre-.NET backgrounds although his primary background was more in Visual Basic under COM while mine was more a combination of C++ and VB.  After .NET was released this individual quickly picked up C#.  Becoming quite adept with C# this person was then heard to state publicly (paraphrasing in spite of quotes) "VB developers should focus on C# instead of VB, because they'll find it easier to learn {a complete new syntax, language and object oriented environment} then trying to understand the differences between VB 6 and VB.NET."

I'm actually not going to touch that statement however; I was wondering recently if then the reverse wouldn't also be true.  Specifically, those developers familiar with C++ and Java should move to VB in .NET.  The reasoning stands that "they'll find it easier for them to learn {a complete new syntax, language and object oriented environment} then trying to understand the differences between" C++/Java and C#?  Seems like if A is true B should also be true and if B is false then perhaps A is...

2. This one is more a conversation quote -> let me set the stage.  We work in small teams on most projects.  Those teams have used (for years) a custom 'Agile-like' process.  Not everyone has the same level of experience with this model and at some point in the past the following conversation (paraphrased) took place.  I was the engineer involved and the other person - not being an engineer supposedly doesn't suffer from my "innate inability" to communicate.  We join the conversation in progress; Eng. 1 has just told Eng 2 a few things they should coordinate for today and tomorrow:

Non-Eng - "So how will the two of you coordinate?"

End 1 - "We'll talk during the course of the day."

Non-Eng - "That needs to stop.  We need to change that."

So in the past I've written articles that talk about how the web as an application model is peaking for certain types of application models.  Specifically that while the 'reach' of web applications - ie. the way that even now I can be sitting in a Del Taco in Riverside (where it is 108 degrees farenheit) updating my blog just prior to heading over for a user group meeting, provide a powerful paradigm.  This isn't going to disappear and isn't to be discounted, but it isn't enough.  New technologies such as Silverlight and WPF will help extend the life of the web as a UI, but the reality is, web services allow me to use a rich client vs. a web site for editing my comments and then just submit the data to the server. 

Most enterprise  applications (as opposed to public facing) continue to be rich client applications. In the future there will still be many such applications which are written from the ground up, expecially those which are focused more on sizzle then steak.  But I feel that the new paradigm for actual business applications will be to leverage someone else's User Interface for much of the framework with a minimalist custom set of controls.  A couple years ago the common 'UI design pattern' we heard from smart client customers was for them to ask for a user interface based on Outlook.  This is still the case but things are shifting, you see instead of asking for a client based on Outlook - instead we are starting with Outlook as the client and just customizing it for the needs of the organization.

Visual Studio Tools for Office (VSTO) have been around since .NET 1.x but as I have been informed many times - haven't really taken off as some expect.  However, like so many things, until the rest of the infrastructure to support a technology is in place even a great tool gets only limited use.  In the past VSTO has primarily focused on the document.  Specifically it started as a replacement for VBA and the document centric customizations of VBA and Macros... but with Office 2007 and Visual Studio 2008 (Orcas) - well this isn't the same model.

An OBA is an Office Business Application, in short it is an architectural model which leverages the full Office System to implement custom business solutions.  The first key enabling technology is of course SharePoint aka Microsoft Office SharePoint Server 2007.  I'm not a big fan of SharePoint as a development platform, but as a host for documents and document templates it is unparalleled.  By marrying key document templates with a web site you gain the benefit of a web application with a rich client.  I'll post more in the future on some of the key enabling technologies which can then be built on this - think about Add-In's and custom message contents but the key is now that we have a solid server combined with a host of new tools the OBA model leveraging VSTO is a very viable solution framework.

Don't think so - well take a close look at Team System.  Team Explorer is in part an OBA, yes there is a 'custom' add in for Visual Studio which isn't part of Office - however, I know for a fact that when I start working with tasks, work items, bugs etc. in TFS I do it all with Excel.  Why because Team Explorer's custom interface pieces aren't natural to me, but the add-ins for Excel and the way that the forms are hosted on SharePoint and retrieve and update data from SQL Server provide me a user interface which is effective.  So when you are thinking about how to engineer that next big smart client application don't discount the value of being able to leverage the Office System as the plumbing for much of what you'll do.

Tonight I'll be presenting on a demo OBA solution which InterKnowlogy helped Microsoft develop to highlight some of the new features of VSTO 2008.  This is a powerful architecture and I'm expecting to do additional presentations similar to the one I'm doing tonight for the Inland Empire .NET User Group.  I grabbed a screen shot of their homepage describing tonight's presentation iedotnetug_org.JPG (172.5 KB) but feel free to visit their site (http://www.iedotnetug.org) or stop in for a meeting in the future. 

A couple random thoughts this evening:

1. Why do the San Diego Chargers (and I'm sure other professional sports teams) insist on giving out things like posters and calendars as you enter the stadium?  Don't get me wrong if it's a towel or hat giving it out on the way in works... but take this past Sunday as each person entered they were offered a poster literally a 2 foot by 4 foot poster with key players in the new ugly uniforms.  Great - but where do you put them for the rest of the game - you can't take it back out to your car and under your seat it gets trashed - if 10 people managed to keep them in pristine shape (out of 57K attendees) I would be amazed.  Do us a favor - let us pick up that sort of thing on the way out where there's actually a good chance it'll make it home as opposed to going straight to the stadium dumpster and local landfill.

2. OK, I know it's considered good practice to bring everyone's food at once but a note to what we'll call informal restaurants - Chili's, Applebee's, Friday's, etc.  If you have a couple with an infant/toddler (in a high chair) and the parents order something for the small child do us all a favor and offer to bring it early.  Mom and Dad have to cut and prep everything for the toddler so having the child's food arrive early is a blessing - they can focus on getting the child started and then when their food arrives shortly (and short is important) thereafter they can actually focus on eating while the child eats as opposed to one or both letting their dinner grow cold.

You might think I'm 7 or so years to late with this story... but apparently not.   Turns out that NASA who has been the primary repository for US and world temperature data was recently informed that they were operating for the past seven years with an undiscovered Y2K bug that corrupted the official average temperature calculations.

These folks who are at the center of the Global Warming debate don't let anyone know how they compute the average temperatures - but someone noticing a big jump at the turn of the century managed to reverse engineer and prove a bug in their code.  Turns out the warmest year on record wasn't 1998 followed closely by 2006 - but rather 1934 followed by 1998...

In fact now that they've "corrected" their calculations it turns out that like 5 of the top 10 warmest years on record are from prior to WWII.... hmm - can we get a code review here?  You'd think an organization like NASA would be open to a code review...

Here are the updated stats: http://data.giss.nasa.gov/gistemp/graphs/Fig.D.txt

And someone who seems a bit more peeved at the whole thing - http://www.coyoteblog.com/coyote_blog/2007/08/official-us-cli.html

(Personally I just think it shows what idiots the team at NASA is for not having their code reviewed - even now - could we get that organization to implement some sound engineering principals!)