Fear and Loathing

I thought I would share a little insight into my brain on planning releases for my SharePoint Forums Web Part using the Scrum development process and what CodePlex has to offer to support this approach.

As you know, CodePlex is a community site that hosts the forums project and there are a few nice tools they’ve baked into the system that help me plan my work a little better. Even though I’m a one-man team (although I’m just ramping up to expand this) I still follow Scrum to plan out the releases and manage the work. Here’s how it breaks down.

The entire Issue Tracker is my Product Backlog. I export all unassigned items to a CSV file via CodePlex online. Then I apply a filter to be able to sort and view the data. Each Sprint is 1 month, delivering on (or about) the 1st of the month. Before I export the work items, I add the next sprint release date and version so it’s available in the filtered data (I have to assign something so it shows up in the filtered data list but I just move this item back to unassigned when I load up the spreadsheet to work.

Two more things I do is assign new columns to the spreadsheet after the export. First is my story points column. Rather than working on hours for estimating, I use points. Each item gets either 1, 2, 3, 5, or 8 points assigned to it. Nothing is larger than 8 points (meaning it’s going to be a lot of work). More on the point system later. Second is a priority column. CodePlex provides High, Medium, Low for priority but for Scrum you have to use numbers. There can be only 1 number one priority (even if multiple people are working on the system). After all, if everything is High how do you know what one you do first?

Then I’ll do a couple of sorts and filters. First I sort out the features from the issues (bugs) from the tasks. Tasks are just things that have to get done, and depending on whether or not they have enough priority they’ll get included in the next release. It’s give and take whether I include a feature or a bug or a task in the next release, although I’ll try to include bug fixes before features and features before tasks (at least I try to plan it that way). Once I’ve gone back and forth with each item, I’ll give it a priority. The decision on what goes before what is driven by the community (that’s you) and my own judgement of what’s important. Bugs that are really stopping people from using the system easily get higher priority than new features that nobody wants. On the flipside, features that people really really want will take priority over low priority bugs that people rarely stumble over or care about. They’ll all get done, but as I only have a finite time, I try to position things higher up the priority scale to get the best bang for my buck.

So now I’ve got a modified backlog with a list of items sorted by priority and a column showing how many story points it will take for each item. There are tasks that will be added later, but for now each story has it’s own weight based on things like how complex it is, if there’s already existing infrastructure in SharePoint to leverage, is this something I’ve done before, can I find an example on the web as to how to do this. Stuff like that. Now it’s time to figure out how many things I can fit into the iteration. I’ve time boxed the iteration at 1 month however contrary to popular belief, I don’t work full-time on this so it’s really more like a couple of hours every few nights. At my current velocity I can finish off 15 points per iteration. How did I arrive at this number? Based on the two releases I have, that’s how many points I finished previously. So for me, 15 points is a months worth of work doing a few hours here and there.

Now its time to go through the list and see what fits. If I can cleanly find 15 points from say the first 4–6 items, I just call it a day and that’s the release. If I can’t, then I need to shift some priorities around. Sometimes a #5 item gets shifted down to #7 because it’s too big to fit into the rest of the available points and item #6 will. It’s just numbers and works out well. Once this is done, I assign the items to that release number on the CodePlex site and export those items to a new worksheet which becomes my Sprint Backlog for the next release (I only priortize and estimate one release ahead).

They’ll be adjustments. With each release I look over how many points I completed and see if my velocity is improving (or not). This has an effect of auto-correcting my estimates. If I keep going at my current estimate of 15 points per iteration, I’m fine but if I find that I only deliver 10 by the time the end of the month comes I know that I under-estimated on 5 points. I’ll take a look at where that way (perhaps it was a feature I thought I knew what was required to make happen, but got bogged down by details). Cosequently, as I might bring on more people the number of points we achieve could go up but it doesn’t change how simple or complex something is. In any case, I’ll correct the project velocity as things change and hopefully estimating will get a little better on the next release.

Yeah, it’s a lot of work for a one-man project that comes out every month and there’s the danger of me running too many projects at this speed. However it gives me a good feeling that I know what the month of work is going to look like, I can pretty confidently estimate how many features are going to be delivered with the next release, and I can talk to people during the month about what’s coming which should hopefully help me plan the next release after that.

It’s not pure Scrum either as in 1 Sprint = 1 Release = 1 Month, but it works for me.

A good friend of mine, fellow co-worker, and all around nice guy is now blogging about SharePoint. Monty Grusendorf got setup on SharePoint Blogs a few days ago, but I was waiting for him to post something more than “Hello World” to unleash him to the cold unforgiving handful of people that stumble on this site looking for Hunter S. Thompsons’ musings. So now he’s blogged about a nice SharePoint nugget. The other day he said hey, did you know about this? While I am the wise old SharePoint guru (or the crazy old unabomber, not sure which) this information was new to me. Very cool (although it would have been much cooler with screenshots Monty, hint, hint). I won’t give away the gold so you’ll have to check out his blog to see what it’s all about. Here’s to seeing more SharePoint blogging goodness from Monty.

I’m really digging the series of blog posts over at Coding in an Igloo (an Edmontonian) that cover Code Naming Conventions. Normally blog entries are either just talking about one thing (say the naming of classes) while others try to cram everything into on post and really don’t cover it. Here he runs the entire gammet, from soup to nuts and everything in between. It’s a very complete reference and not only has his ideas of what is works for him, but why, which is as important as to the what.

Here’s what he’s posted so far:

• Consistency Through Convention
• Local Variables
• Modular Variables
• Functions and Method Naming
• Properties
• Classes
• Interfaces and Super Classes

Next up is UI Controls which I think is always a point of discussion. I personally use the txtFirstName convention, although I flip flopped between that and the firstNameTextBox idea for awhile but landed back with the control name flair. I think UI controls is the only place where our big, fat ugly aunt from the Hungarian hills shows it’s face, and it doesn’t seem that bad?

Anyways, great series so I highly recommend following it. I’m sure at the end of the posts you could simply snag all the entries and use them as-is for your own standards.

So what’s this MVP thing? Bil’s an MVP so now he’s a pattern? I don’t get it.

Well, not quite.

Model-View-Presenter (MVP) is a fairly new(er) term for an old(er) pattern in Software Design. Its similar (but not necessarily the same) as the Model-View-Controller pattern (MVC) that you may have heard of or seen around. MVP is a pattern that will abstract away the display of data from a user interface. This is done for a few benefits, like being able to test a UI without a UI (yeah, let that one cook in your noodle for a minute or two). It also reinforces your domain model so you’re not doing screwy things like writing logic decisions (should I display a row of information if the user has permisions or not) in the user interface. Bad, bad place to do this.

Quoting Martin Fowler, the MVP pattern “Separates the behavior of a presentation from the view while allowing the view to receive user events.”

So MVP is a great pattern for doing UI elements, and keeping your domain logic where it belongs (read: in the domain silly), while maintaining a good, clear separation from the UI. In essence, the view subscribes to events and the presenter, well, “presents” them to the UI. The UI then figures out how to update itself and doing crazy user interface stuff like change lists of data or display rows of information.

Still with me? Imagine that Bert is the View, Ernie is the Presenter, and Mr. Hooper is the Model. Mr. Hooper has some jellybeans for sale at his store. Ernie can go to Mr. Hoopers store and find out how many jellybeans he has for sale today. Ernie will tell Bert this so Bert can update the Sesame Street website. Ernie doesn’t know anything about HTML but does have the information Bert needs to do his thing. Bert isn’t allowed to talk to Mr. Hooper or go anywhere near his store (after that last incident with Mr. Snuffleupagus and the latex) so Ernie heads out to Mr. Hoopers store and counts the number of jellybeans he has for sale. He comes home and tells this to Bert. This is how Bert gets the information he needs to update the website. Got it?

The thing about MVP is that UI doesn’t really care how (or for that matter where) the data came from. The presenter just gives it to the UI in pieces. The UI is a dumb animal (and should be) and should only know simple things like adding items to a drop down list, or displaying a grid of information. User interfaces are stupid and should never get any smarter than knowing about the UI. Much like any project manager.

Okay, let’s get into this and walk through an example of creating the MVP pattern with SharePoint Web Parts. There’s an excellent article on The Code Project that describes the MVP pattern in-depth here. I’ve adapted it to use a SharePoint Web Part instead of an ASP.NET page for this article.

Side note: This is the first of two articles I’m going to do on the MVP pattern. The first is going to be for .NET 1.1 (Visual Studio 2003) and SharePoint v2 (or 2003 if you prefer). The second article will come later and be written in .NET 2.0 (Visual Studio 2005) and SharePoint v3 (or 2007). The two articles show the same pattern, but are implemented differently as I can make use of Generics and other features of the Web Part framework. I just thought I would kick it off with a 2003 demo so anyone writing Web Parts for SharePoint today could make use of it.

The View

No, not that crappy TV show with Starr Jones quitting over the number of M&Ms she needs, but rather the “V” in “MVP”. The View is responsible for exposing the data we want to the user interface. You might say that’s what say a class inherited from WebPart does. Well, yes, but since we want to tell the view (indirectly) what to update and we don’t want to know about UI type control things (listboxes, drop down lists, data grids, etc.) we need something called a View. The View gets implemented as an interface and as you know in .NET, you can implement as many interfaces as you want on a class.

Here’s a simple view that has one property of type DateTime called CurrentTime that any class implementing this interface must create the setter for.

The Presenter

The Presenter is the guy behind the curtain that makes the magic happen. The Presenter marries the view and the model together in a harmonious fashion, wiring itself up to events that are triggered from the view. When the view requests a change, it does so through the Presenter and the Presenter (talking to the Model) will respond accordingly. Finally the View updates itself via the UI (whatever that UI may be, a User Control, WinForm, WebForm, or in our case a SharePoint Web Part).

Our presenter is simple and will do two things. First, it gets created using an object passed into the constructor that conforms to the ICurrentTimeView interface. Next, it provides a public method called InitView that will initialize the view when called. Here’s the code for our Presenter:

The Model

This is the class that represents the data we want to present. As you may not need to expose your entire domain object graph to the UI, this might be a subset or slice through that data. Whatever is relevant to the UI and the properties you need to expose. Our Model is going to be simple and we don’t have a class for it. It’s just what gets set during the initialization of the view but you could create your own Model class or have the Presenter talk to a Facade or Service object to get data. In this example, the Service object is the current DateTime instance.

Bringing it all Together

Let’s bring this puppy home. So we have a view interface, and we have a presenter that will take an interface of that type during construction. First we need to add the ICurrentTimeView interface to our Web Part and implement the member(s) that it describes. Here’s what that looks like in our Web Part:

This is just the generated Web Part you get from the template in Visual Studio 2003, except we’ve got two new things. First the CurrentTime property, which is an implemention of the ICurrentTimeView interface and the interface has been added to our Web Part declaration.

The CurrentTime implementation is up to us and in our case, we’re going to set our Text property to it. When the Web Part renders, it will render out the Text property that will get set.

So how does the Presenter talk to the View? We need to add one more thing to our Web Part. In the override to the OnLoad method, we’re going to create the presenter object and initialize it like so:

Remember we said that the CurrentTimePresenter class takes in “this” (meaning the Web Part object) to its constructor. CurrentTimePresenter actually wants an object that implements the ICurrentTimeView interface. It doesn’t matter what object it is, or what it’s derived from, it only pays attention to the interface. Then it calls the “InitView” method of the view. That’s not part of the Web Part, but it will talk to the Web Part through it’s CurrentTime property.

It’s all about misdirection. Like magic.

This is a simple example. A more concise example is to have a backend data source (either a SharePoint list or a SQL database) feed the data through the Model (using a Data Access Layer or something). Or you can have the Presenter fetch the data through a Facade for the business layer (again calling some external data source via a DAL). Also you can have multiple properties and methods on your view interface (that your Web Part will have to implement). Use your imagination. Remember to keep your UI thin and simple. You’ll probably need one View and one Presenter to keep things clean but they’re simple to make and easy to use.

The killer gain here? First, I can unit test my presenter and model (and view) without SharePoint. No, I can’t get SharePoint data without SharePoint but remember when we created the Presenter in the Web Parts OnLoad event? Notice it passes “this” as a parameter, but the CurrentTimePresenter class doesn’t know anything about Web Parts. That’s the magic of interfaces and designing by contract. The CurrentTimePresenter class expects an object that implements ICurrentTimeView. The Web Part is derived from this so it can be passed into the Presenters constructor. The Presenter couldn’t care less about the other “SharePoint” stuff, it’s just going to call the implementation(s) of the views interface(s).

Also notice that the ICurrentTimeView implementation (the CurrentTime property) isn’t a SharePoint property, but it does set one internally. This is hidden from the Presenter so the Web Part could have just as easily set a text box, filled a data grid, or updated some AJAXy-type control (again, use your imagination). When the Presenter updates the Model, it does so through public properties that are defined in ICurrentTimeView. Again, it doesn’t know that this is updating a property on a SharePoint Web Part and couldn’t care less, it just knows that somewhere (somehow) the UI is going to make it work.

Neat huh?

Okay, go forth and code.

I was a little confused (as I often am) earlier today as I noticed Todd Baginski has put together a tool he called the “MOSS BDC MetaData Manager”. Catchy name but didn’t I just hear this tune? There’s a CodePlex project underway called the “Database Metadata Generator for the Business Data Catalog”. Okay, not as catchy but isn’t this essentially the same tool? Not quite.

Todd explains he looked at the project on CodePlex and there are differences between his tool and that one. He outlined them in his blog which I’ll share here:

Features Todd’s tool has that the CodePlex one does not:

• Granularity: Allows you to create BDC components (LOB Systems, LOB System Instances, Elements, and Methods) independently of each other.  The application on CodePlex creates one LOB System, one LOB System Instance, an Entity and two Methods.  My application allows you to add LOB Systems, LOB System Instance, Entities, and Methods on an ad hoc basis so the Application Definition can grow over time. 
• Support for SQL Server Authentication. 
• Ability to query objects in the BDC (LOB Systems, LOB System Instances, Entities). 
• Column selection capability instead of returning all the columns in a given table. 
• LOB System Instance configuration.  Authentication Mode, Database Access Provider and Connection Pooling can be individually selected and customized per LOB System Instance. 
• SQL Server 2000 and SQL Server 2005 support (I'm not sure if the CodePlex application supports SQL Server 2000 because I did not test it against SQL Server 2000).  I tested the CodePlex application with the AdventureWorks database in SQL Server 2005 and the application threw an Exception.  I believe this is due to the fact that all the tables in the AdventureWorks database do not have dbo as their owner. 
• Database selection capabilities that allow you to browse through the database server to find the database and table you are looking for. 
• Export to XML capabilities. 
• SSP Administration web site built into the application. 
• Guided help and instructions for end users. 
• Help system not only describes how to perform tasks but also educates the user on the various BDC components and how they relate to each other. 
• UX: Easier to work with than the command line (that's just my personal point of view) and provides the context as well as the status of the current BDC elements as you work with them.

Features the CodePlex tool that Todd’s does not:

• The ability to generate a SpecificFinder Method.  (I will be adding this functionality later in the week.  I wanted to get my head around the BDC object model before I tackled this functionality.) 
• The ability to execute the program via the command line or a batch file.

Like he said, he’ll be adding the SpecificFinder method later this week and executing from the command line, well, might be value-added but I’m not so sure given all the “extra” capability that Todd has already baked into his tool.

Botton line, get Todd’s tool and you’ll be good to go, creating application definitions at the flick of a mouse. If you haven’t figured out what the BDC is all about and what it can do, please dive in (a good starter is here). It’s going to be the unsung hero of SharePoint 2007 IMHO (I’m also giving a presentation at this fall’s DevConnections in Vegas on the BDC and will be using Todd’s tool for some of the demos as I can’t really create a definition in an hour AND present all the other stuff).

Hey, what's a girl to do when his brain is just cooking with goofy ideas. With more ideas than can fill the Exxon Valdez, but not enough time to do them here's the latest chicken scratch courtesy of your friendly neighborhood MVP.

The SharePoint Knowledge Base Web Part!

It's a single web part (backed by multiple lists again, seems to work for my SharePoint Forums Web Part) that let's you create questions, assign them to categories, and rate and comment on them. I've dug around the net on various knowledge base software and pulled together the features that I think makes up a good kb web part. Here's a rundown of the features:

• Ability to add as many questions as you like
• Ability to add and categorize questions into categories (including multiple categories for a single question)
• Search capabilities to find questions and answers
• Rating for each question (was this helpful - yes/no)
• Add comments for each question
• Moderation of questions (or you can leave it open so questions are published immediately)
• View questions by category (with number of questions displayed)
• Quickly jump to any category instantly from the main page
• Assign related questions to other questions
• Attach any number of files to a question

Of course, no announcement would be worth it's dirt without opening the kimono so here's some screenies:

The main display of searching, selection by category, and the category display:

Displaying a single question with option to print, email, add comments, etc.

Watch for a release later this month (probably after the August drop of the SharePoint Forums, need to get a new project setup on CodePlex for this ;)

I wasn’t sure what to call this blog entry so maybe it’s mis-titled. As odd as it may sound, this entry stemmed from a conversation that’s going on over in Rory’s side of the web where he praises Carl Franklin on his community efforts. I threw in my own “praise the world” type comments, but there was a link to a site called Design Patterns for .NET. This of course peaked my interest, but some of the comments Rob Daigneau made about what is a software architect triggered something in me noggin.

Everyone and his brother has written what a software architect is (and is not), comparisons abound on how software architecture is like building architecture, blah, blah, blah, blah, blah. I don't know what Rob Daigneau is (other than an Enterprise Architect for Monster.com, and after this post I can probably kiss any hopes of working for them goodbye), but he misses out on what I think is the key elements of what software architecture (and Architects) is about.

It's really not about patterns and technology. Really. Sure, they're an integral part and any good Architect needs those skills but they're just mechanics. Anyone (with the right aptitude) can pick these up (how do I make pretty UML diagrams, what is n-tier, etc.). IMHO the key things architecture is about is:

• Communication
• Abstraction
• Negotiation
• Influence

A good architect excels at these attributes because they have no power, only persuasion to influence, and they need to know how to communicate what they're thinking so everyone understands them. I wanted to present my take on some things that make up a good Architect.

Communication
Everyday the architect on a project is trying to tell someone something. You’re the liaison between the business and the geeks. You’re the instigator of change. You’re the guy who’s trying to demonstrate to the client that before they sink $5 trillion dollars into this IT project the concept is sound and the team can deliver what the business wants. You’re also the guy (or girl) who’s telling the business that you’ve heard what they want and think you know what they said. The rubber hits the road when you tell the story back to them and see if you were listening correctly. Finally, your the guy who’s trying to bring the stone tablets down from the mountain to the nerds who are going to build this monstrosity you’ve architected. Somehow, using a combination of knowledge of the requirements, kung-fu coding skills, and an understanding of your model, they need to create it. Yes, even if you are building your own system (I like Architects who code and I would like to think I’m one of them) you need to know the intent of what you’re building. Drive by coding and architecture on the cuff because you’re stuck down a dark Architectural alley is no way to build a solid system.

Abstraction
We all know there’s abstraction in the domain and I’m not really talking about coding abstractions here or implementing interfaces for unit testing. I’m not even talking about technical abstraction (from an infrastructure perspective). No, this kind of abstraction goes hand in hand with your ability to understand the business requirements asked of you. And your ability to Architect a solution that meets those requirements. Something that does incorporate the technology you need and solve the problem at hand (whatever that problem is). If you’re too close to trees to see the forest, how can you really see the big picture of what needs to be done? I’m also not talking about big design up front (BDUF) or anything. Just simply being able to abstract yourself away from the techno-babble the geeks of the world will get wrapped up in and the little nuances the business wants from a solution perspective. It’s nice they want blue buttons and an user interface that’s “intuitive” but if you’re not solving the problem asked of you and reaching the overall goal with the entire solution, what exactly are you building? A great looking UI that moves data around? Where's the business value in that?

Negotiation
It’s all about compromise. There are so many times you’re going to have to hold your Architecture nose because of the horrible smell you’re about to create because some network junky says you can’t have unsecured traffic over HTTP on port 80. You can come up with an architecture for a system that is technically perfect, but you have to live within the constraints of whatever infrastructure you build it on (or in). Corporate intranets and network security paranoidites are out to lock down and otherwise curb your seemingly elegant solution. For this you need to be able to compromise and find a balance. For this you need to negotiate. Sometimes it with the technicians who refuse to punch a hole in their firewall just so you can get FTP traffic flowing, other times it’s the customer who flatly refuses to back down on the sub-second response they want (without paying for the infrastructure upgrade needed to make it happen). There are negotiations to take place and through your bargaining skills, you’ll find that sweet spot that will make everyone happy.

Influence
There is no power. If you, as an Architect, think you have the power to move things and leap tall requirements in single bound, think again. The customer is always right, and usually holds the dollarinos that feed your family. They’re not going to care that you think a SmartClient n-tier approach to solving their problem is better than a 3–tier application with a web front-end. They just want to do their business. And power over the developers who are building this thing? That’s an entirely different influence you have to master, since they look at you as a techno-dweeb who can barely code your way out of a paper bag. Not even the coolest looking UML or class diagram (even if there such a beast) is going to persuade them that your kung-fu is any better than theirs. Bone up on how to influence people. There are many self-help books out there that are good for this.

Now a few things about this post. I don’t get into the differences between the various architect flavours out there. Software, Solutions, Data, Enterprise. An Architect is an Architect is an Architect. The core skills are there for all of them, the media and technical skills just vary.

Well, maybe I’m the one that’s completely off my rocker here but these are my views of architecture from the software space and it’s my blog and I can rant if I want to, so there. YMMV.

First off, thanks to everyone who's been contributing stories to SharePointKicks.com, kicking stories, and generally promoting the site by providing "kick" links in your own blog posts. SharePointKicks is growing and growing (which is a good thing) and becoming a great resource to filter out only the *good* stuff.

Also props to Gavin Joyce who has singlehandidly (is that a word? where is my Websters plug-in?) been updating his *kicks* sites, and generally adding features as he can find time. Its interesting to see that DotNetKicks and SharePointKicks are the guinea pigs that get the first kick at the can for the new features (no pun intended). Maybe an indication of how popular kicks is.

The recent updates are well recieved and will let you sort (using no-postback ajax techniques) the latest stories and top stories (based on number of kicks) from the last day, week, month, and year. There's also tagging which was added a few releases ago. This lets you add additional filters to posts so you can submit a story to the Community category, but then tag it with something like MOSS, Development, or Customization (or create your own tag). The tags display is based on how many items are tagged with that word, so larger tags will have more stories associated with it (very much like Community Server has with it's tagging system). I'm sure there's an official name for this who tagging concept and there's probably an entire blog dedicated out there that describes the origins (feel free to put a link in the comments if you know or come across it).

Anyways, thanks again to everyone in the community for making SharePointKicks a great SharePoint resource (and so quickly!). Please do continue to contribute, kick things, and generally pimp it to the world as you can find the time. Also if you do have suggestions on SharePointKicks feel free to send them to me at info@sharepointkicks.com. Some of these suggestions may make themselves into the *kicks* software Gavin puts together and would show up on all the kicks sites, so consider your contribution not just to the SharePoint community but the development community at large.