I'm tired.

I'm tired of being the person that everyone comes to with their problems, looking for solutions.

I'm tired of being the responsible one.

I'm tired of being the supportive one.

I'm tired of being trustworthy, loyal, helpful, friendly, courteous, kind, obedient, cheerful, thrifty, brave, clean, and reverent, of being prepared, and doing a good turn daily.

I'm tired of not being feeling considered.

I'm tired of not being respected.

I'm tired of not being heard.

I'm tired of being the one who is fighting for the cause.

I'm tired of being the one willing to change.

I'm tired of being the person that everyone thinks I should be.

I'm tried of being who I am to some people some of the time and not all the time.

I'm tired of being weak.

I'm tired of caring.

I'm tired of not knowing what's wrong from right.

I'm tired of not knowing the causes worth fighting for and the ones to walk or run away from.

I'm tired of being the "go to" guy.

I'm tried of being the guy that "knows everything".

I'm tired of not feeling valued and taken for granted.

I'm tired of feeling overlooked.

I'm tired of being the decision maker.

I'm tired of being the stand-in.

I'm tired of being the dream-chaser.

I'm tired of being the time-filler.

I'm tired of being tired...

[My] Ethics of an Agile Software Project

I don't think I could never make it as a mechanic. I don't think I've ever had a pleasing experience getting my car repaired. My estimates never seem to be anywhere close to the actual costs of the work I ask to be done and what's worse, I feel, is that I never really know if they only do what I ask and nothing more. If a mechanic were to call me and report that s/he over-estimated the time and materials for job, I would most definitely be a returning customer. Seldom, though, is that the scenario.

Software development projects seem to fall into that same rut. I mean, honestly, when it starts out, the customer (in my humble experience) enters the project with some set of expectations of the work to be done, sometimes with an idea of cost as well, but almost always receives feedback throughout the project that is not at all inline with any of those expectations. The other side - the Team - does not go unscathed to these effects either. Changes to the project, either set-forth by the Customer or some other external influence, upset the expectations of the Team and the project thus altering its outcome.

However, I believe the important difference between the rest of the world and software development is this: the customer should not bare the brunt of the effects changes have on the project. The Team shouldn't either, don't get me wrong; however, it seems that this is far more seldom the case.

Both stakeholders need to be able to react throughout the project accordingly as it changes. If the Team discovers that it can complete the work with the designated resources ahead of schedule and under-budget, the customer should only be responsible for the cost of that work and nothing more. Period. However, if the project becomes more volatile, greater risk discovered, or any other turn that a project can take that either or both stakeholders do not see it in their best business interest to continue, the project should terminate under conditions acceptable to all stakeholders.

To me, this is true agile software development. Communication is a unrestricted and all stakeholders are provided with sufficient knowledge in order to make valuable business decisions. Change is accepted and embraced allowing everyone to respond and react accordingly since everyone is kept "in the loop". And...it's ethical. There's no sneaky, dirty, behind-the-scenes plotting on either side to outsmart or gain over the other. The interests of everyone are constantly kept in check so that, in the end, everyone wins.

Contracting an Agile Software Project

Man, if that isn't worthy of a book, I don't know what is...I got thinking this afternoon (the bride was a napping so my mind was wandering) about how a company needs - or should - adapt to employ an agile methodology. My main predicament is how proposals and/or contracts are written.

Currently, under a waterfall methodology, countless hours are spent devising requirements, system(s) documentation, Gantt charts and time-lines, and other various artifacts that become out of date and out-of-sync when one thing changes. All that work is all-but lost. However, it seems as though customers have almost come to expect this. An unfortunate side-effect of all this is that, in turn, the projects that are put in motion this way are extremely resistant to change and, by the time the actual development begins, problem the project was intended to solve has changed many times since the initial discovery, requirements gathering, etc...

While agile methodologies counter this problem by performing each of the phases in a waterfall methodology in iterations, it seems difficult to establish the basis for a contract that could be used between the "vendor" and the customer. Taking Scrum as an example, I realize that the Product Backlog is, in essence, the requirements document and the Sprints make up the iterations, which lead to a release. But since requirements are discovered in depth prior to and during each Sprint, they aren't as detailed as the proposal or contract that is delivered prior to starting a project employing a waterfall methodology. Sure, the argument exists that there are no guarantees that the requirements document delivered is anywhere near as accurate as what an agile methodology could produce, but it sure seems as though customers want this kind of paper work in-front of them before kicking-off the project.

I guess, as with everything else, there's a tradeoff that has to be made. The Customer has to be willing to accept that the items they've defined and prioritized in the Product Backlog (or equivalent) will be produced by the Team. However, it seems as though everyone needs to have the understanding that the Backlog is not, by any means, a requirements document. It states the functionality the Customer desires of the system and that the Team and the Customer are responsible for discovering what is required of the system to deliver that functionality. The Backlog can also serve as a rough time-line for the Customer as it will include estimates for each Backlog item and during which Sprint (iteration, etc.) it is intended to be developed. And, depending on the terms of the project, it may also serve as a gauge as to the cost of the functionality.

While I will be honest and say that I feel that this is a better approach, I'm skeptical about how a customer will react to it. There have been a lot of scenarios recently at work where a potential project exists and it's also known that the customer has a more restrictive budget...although, I guess, like everything else, it becomes the company's job to determine whether there is value in attempting to acquire a project at lower rates, etc. in order to have the source of revenue.

What a tangled web we weave...

A Look Back - "Halo: Combat Evolved" E3 2001 Coverage

My brother and I were arguing today over the quality of the Xbox 360 materials from E3 this year. He brought up some interesting points, mainly, the argument that "Halo: Combat Evolved" looked like "Video Games: Graphically Dissolved" - at least from the previews presented at E3 around 2001. His argument is that the majority of the games presented, with exceptions like Gears of War and others, look like the original Halo did at its E3. While games like Gears of War look very, very impressive, the majority of the games presented do not seem to have a lot more to offer than what's available now on the current Xbox. In fact, he brought up that Half Life 2 for Xbox looks astoundingly close to the PC release and it runs on hardware that's far from the specs proposed for the 360.

I have to admit that, looking back, I feel really, really stupid realizing that I was completely dumb-founded by those "graphics". In a way, I agree with him that some of the 360 titles were not as impressive as the may appear; however, that allows for light at the end of the tunnel as many of the games were early betas and the hardware for the 360, supposedly, has not been completely finalized yet so things can only get better...And "Halo: Combat Evolved" is a perfect example of just that...

But I digress...

Mono for Everyone

I'm in the process of downloading Monoppix as reported by Darrell. The biggest benefit is that since it's distributed as an ISO, you don't even need to reboot if you have Virtual PC!!

This is absolutely awesome! Tutorials, built-in web server/ASP.NET...I really, really hope to have an opportunity to play with this professionally...Absolutely awesome...

BBB Update: Feature List (incomplete)

Here's the start of the list of features I want to incorporate into my Bare-bones Blog application. By no means is this an exhaustive, ordered, or complete list; it's very much still in progress. Eventually, this list will become the Product Backlog for the project and I will prioritize the functionality into the appropriate Sprints. At that point, the coding will begin...

Functionality thus far:

• Create blog
• Create category
• Create post
• Create Setup bootstrap/configuration page
• allow rich text editing
• upload images
• track referrals
• add comments to posts
• subscription via RSS
• subscription via ATOM
• dated post publishing
• assembly-embedded resources (images, templates, style sheets, etc.)
• security
• generate permanent link for posts

As always, comments and feedback are always welcomed and appreciated!

Lesson 1: Process Does not Make Project

My previous post permitted me to learn something just in determining how to begin. I was struggling how to describe my use of Scrum. Scrum isn't driving the project; the customer(s) and stakeholders drive the project. Scrum isn't "behind" the project either - meaning, it's not supporting it as if Scrum did not exist, the project could not exist or would not be feasible without Scrum.

This may very well be a simple, given principle, but I feel it's important to identify. I think by better understanding the application, "role" in the project, and use it allows for more discovery of the methodology and how it may/not impact the project.

BBB Update: Scruming Away

If the title for this post didn't provide any hints, I'm choosing to attempt implementing Scrum while developing the BBB project. My choice came about, primarily, because of my interest in how the process could benefit my professional work. Also, the only other agile methodology I'm remotely familiar with is XP and, since I'm the sole developer, I don't have a pair to pair with during my code sessions.

I'm not sure that I'll learn that much from this project, especially since I will, essentially, be filling all the roles: Product Owner, ScrumMaster, and Team. I have not received and requests from anyone but myself for this project, making the Product Owner and sole stakeholder. I also fill the role as ScrumMaster as it will be my sole responsibility to ensure that Scrum is implemented accurately and as smoothly as possible to keep productivity high and ensure that the Team keeps its focus, remaining on track. And, finally, I am the Team. Probably one of the few, extremely rare times I will ever say "there is an 'I' in Team".

Interestingly, to me anyway, I am also viewing my blog (and blog audience -- anyone out there?) as the customer as well - to a degree. As ScrumMaster, I have the duty of reporting regularly the progress of the project. These reports are presented to the customer and, as Ken Schwaber describes, any chickens interested in the project.

My next step will be to produce the Product Backlog for the entire project. The Backlog will be published in a format that complements the data. Once the Product Backlog is created, work will begin on the first Sprint. While I realize that, depending on the project, it could be acceptable not to complete all Sprint Backlog items, I'm not sure how I'm going to handle the Sprints. Because of the thirty-day time restriction and that, at the conclusion of each Sprint, functional software must be produced, the result will be to either extend the Sprint time restriction OR have lots of Sprints with few Backlog items. This is just something that I'll have to make an executive decision on and live with it.

Check back soon for the next update!

Personal Software Project Announcement

As I mentioned yesterday, I want to start talking about the project I'm directing all of my focus on currently that is completely non-work related. So, without further ado, here's the official press release:

Announcing: Project Code-name "Bare-Bones Blog"

After much frustration that I have experienced using Blogger, I've decided to have a go and dip my big toe into the blog application pool. I'm sure there's a lot of "huh?! why???" looks and shaking of heads going on right now...Allow me to elaborate.

It seems like, about 18 months ago, the topic and idea of blogging really took off - at least for me. I interested peeked when I discovered developers, hundreds at the time, within Microsoft publishing details about their work on company projects on MSDN Blogs. This seemed, to me, the primary way of discovering information about Whidbey at the time and was very interesting and intriguingly to me, especially from the view of "leaking" information out to the public. This, inevitably, led to my interest in the technologies behind the blogging sites. I began by looking at the most successful .NET blog application, .TEXT (which is now Community Server).

.TEXT, and blogging in general, fascinated me as the concept is, essentially, a content management application, with a little twist. I clung to .TEXT because of its .NET implementation and spent countless hours studying it. There's countless aspects of the application that I love...Unfortunately, countless that I don't as well - especially requiring a SQL Server 2000 license.

I felt the need/desire to join the "blogosphere" and, with all attempts to get on a site that offered a .NET-based blog application failed, I resorted to Blogger/Blogspot. I'm sure some feel that Blogger is an awesome product and, for the price, you can't beat it. However, there's a lot of functionality that is missing that .TEXT has that I miss. A great example is lack of categories. Simple, yet necessary. I need that - and more - without the SQL Server price tag.

My next couple of posts will detail my proposed functionality and, hopefully, some kind of release schedule/time-frame. I'm looking to incorporate an agile methodology so that, not only are there programming lessons to learn and discover, but also process lessons as well. The initial idea is for everything to be iterative and build up to fully functional application - as agile methodologies promote.

I'd love for feedback and just general input on how it all is evolving.

"Irons on the Horizon"

There's lots that I want to blog about, so keep checking back as I hope to discuss more of these topics in greater detail in the near future. But as a preview, here's some of things to look for (in no order):

• Test-Driven XSLT/XPath
• VS2005 announcements
• Agile development happenings at work (if permissible)
• MyPSP - or My Personal Software Project, name TBD

I hope to have something started on one of those topics by the end of this week...Check back soon!

If you can't test, throw in the towel

So, I've been really struggling lately keeping a balance between my personal and professional lives. My personal life, I feel, is crazy right now. There's a lot going on with the wedding, less than five months out and, on top of that, it just seems like May and June are always much more busy than November and December - which for the life of me, I can't determine why that is. I'm feeling as though something has gotta give or else I will and it won't be pretty...

Unfortunately, most of this frustration comes from having to sweat the small stuff. For example, I've asked my family to let me know when my favorite uncle is dropping by so that I (and, possibly my bride) can stop by and visit since we're normally out and about. Two weeks ago, he stops by and they don't call. It's worse when I come in at 11:30 PM and I see his car. My family is going through some big changes and, in the process, I've come to realize that we're all not going to be able to spend that "quality time" together as much as have in the past. Maybe I'm the only one to realize that at the moment, but when simple favors like these are repeatedly forgot or ignored, it hurts.

Now, knowing that my bride and I are preparing to move her into our home post-Oct15, my father dropped our van off at the shop to have the transmission fixed. He has no idea how long they're going to have it nor an estimate of anything. We've been planning and attempting to arrange this move for at least the past 2-4 weeks!! Do I need to spell it out on a chalkboard or on penmanship paper so that my parents can get it?!

If only the behavior of people was as deterministic as unit testing software:

public void testParentsKnowAboutWedding()

{

Person dad = new Person();

Person mom = new Person();

Person firstBorn = new Person();

Family family = new Family(dad, mom);

Assert.AreEqual(dad, mom.Spouse, "Mom isn't married to dad");

Assert.AreEqual(mom, dad.Spouse, "Dad isn't married to mom");

family.addChild(firstBorn);

Assert.AreEqual(1, family.Children.Count, "First-born not member of family");

Person brideToBe = new Person();

Wedding wedding = new Wedding(brideToBe, firstBorn);

wedding.InformFamilies();

Assert.IsTrue(2 < wedding.NotifiedPeople.Count, "Mom and Dad don't know about the wedding");

}

(I don't know what's worse the fact that I wrote that out or the fact that I actually thought about how I'd design an application that would do such a thing so that the test was practical and "realistic")

I digress...