Don’t Give me Rework Refusal!

Over the last few weeks I’ve seen a few comments regarding rework. One of those comments was Julie Booth’s (@uxsuccess) comment on Twitter regarding rework,

“Do not fear rework!!”

That kicked me off with a response of,

“Do not fear rework!! /via @uxsuccess so true, plz plz don’t cower before rework!!! :). Listen to @uxsuccess!

Then just recently I stumbled onto a book I’ve been meaning to read called Rework.  This book is written by the crew at 37signals.  This company is best known for SaaS Offerings Basecamp, Highrise, Campfire, and Backpack.  All of them created with high quality, solid UX (User eXperience), probably great code quality, maintainability, and the list of goodness goes on.  In addition, the other thing that 37signals is widely known for is their efforts around Ruby on Rails (created by DHH @dhh).

Rework is a fundamental requirement to actually getting an elegant solution.  It might seem chaotic or disconnected at first, but it quickly becomes a vastly superior way of doing things instead of the “Do it once, do it right the first time” nonsense.  Things need to change, doing things right the first time is almost impossible anyway.  That is why you practice playing guitar before becoming a virtuoso, you learn to hammer before becoming a carpenter, you sketch and draw before becoming an architect, and the list goes on.

Don’t expect perfection, expect creation.  That’s what I’d say.  If you can’t tell, I agree with the Ruby on Rails mindset, with a lot of what DHH/@dhh writes, and I especially respect what 37signals has accomplished and the revolutionary business ideas in the book Rework.

These types of ideas – simple rework and the open minded approach to rework – makes a business faster, more agile, and responsive to their customers’ needs.  These ideas, these mentalities are what have created great companies in the past and will build great companies in the future.  The companies that suffer the traditional approaches and mindsets are at significant risk of being eliminated from the market altogether.

There are many others out there also, that push these types of ideas and mentalities around rework, refactoring, and agile practices.  If you haven’t checked out who 37signals is, the book Rework, or Ruby on Rails you should stop whatever you’re doing and find out about this company and its products.  Especially find out how their products were built with business agility in mind, with a strong dose of Agile ideals.  With that I bid adieu for the day.  Happy coding, and don’t fear the rework.

Aggregated Web Services Pt II – Tying it Together

I’ve been working through a project recently that I ended up creating an interesting abstraction of an assembly/classes between multiple web services projects.  I wrote about it initially in Aggregated Web Services Pt I.  In this blog entry is going to cover a few things, based on a full end-to-end implementation of a project from the WCF RESTful Web Services, to the ASP.NET MVC Site, and finally the jQuery calling those same services.

Simple Architecture
Simple Architecture

Before I got started, there is one thing I need to point out.  The communication with Javascript/jQuery/AJAX has a lot of tricky bits one needs to be aware of.  One of those is the same site origin and of course the famous cross domain solution issues.  That is why in this walk through I will place the web services and the site pages in the same project, yes, WCF and MVC living happily in a single project.  🙂  You can of course, if your architecture requires it, break these into separate projects, but for this example I’ll have both in the same project.

First create a new solution.  I always like to start with a new solution because it keeps the naming structured right, just from the practice.

(Click on any of the images to see a larger full size copy)

New Solution
New Solution

Once you create all of that then add an ASP.NET MVC 2 Project.

Adding the ASP.NET MVC 2 Project
Adding the ASP.NET MVC 2 Project

You can create an ASP.NET MVC 2 Unit Test Project if you want to, but I’m skipping it for now.  (yes, I’m still a big TDD advocate, but just setting up a prototype for this example)

Next I wiped out some files I don’t use, and suggest you zap em’ too.

Get Rid of the Nasty MS AJAX
Get Rid of the Nasty MS AJAX

Setting up the WCF Parts

Now that we’ve cleaned up those nasty bits, we’ll add our basic model we’ll be using.

[sourcecode language=”csharp”]
using System;

namespace EndToEnd.Mvc.Models
{
public class Investor
{
public string Id { get; set; }
public string Text { get; set; }
public decimal Money { get; set; }
public DateTime Stamp { get; set; }
}
}
[/sourcecode]

Now add a interface for the RESTful services to the root of the MVC Project as shown below.

[sourcecode language=”csharp”]
using System.Collections.Generic;
using System.ServiceModel;
using System.ServiceModel.Web;
using EndToEnd.Mvc.Models;

namespace EndToEnd.Mvc
{
[ServiceContract]
public interface IEndToEndService
{
[OperationContract]
[WebGet(UriTemplate = "Investors/{pageStart}/{pageEnd}", ResponseFormat = WebMessageFormat.Json)]
List<Investor> GetIncidents( string pageStart, string pageEnd);

[OperationContract]
[WebGet(UriTemplate = "Investor/", ResponseFormat = WebMessageFormat.Json)]
Investor GetInvestor();
}
}
[/sourcecode]

Now add the following abstract base class at the root level also.

[sourcecode language=”csharp”]
using System;
using System.Collections.Generic;
using EndToEnd.Mvc.Models;

namespace EndToEnd.Mvc
{
public abstract class InvestorBase : IEndToEndService
{
#region IEndToEndService Members

public List<Investor> GetIncidents(string pageStart, string pageEnd)
{
return new List<Investor>
{
new Investor
{
Id = Guid.NewGuid().ToString(),
Money = (decimal) (DateTime.Now.Second*2.27),
Stamp = DateTime.Now,
Text = "Lorum ipsum 1"
},
new Investor
{
Id = Guid.NewGuid().ToString(),
Money = (decimal) (DateTime.Now.Second*1.32),
Stamp = DateTime.Now,
Text = "Lorum ipsum 2"
}
};
}

public Investor GetInvestor()
{
return new Investor
{
Id = Guid.NewGuid().ToString(),
Money = (decimal) (DateTime.Now.Second*1.27),
Stamp = DateTime.Now,
Text = "Lorum ipsum"
};
}

#endregion
}
}
[/sourcecode]

Now add a WCF Service file and remove the interface file.  Then change the WCF class itself as shown below.  The reasons for the abstract class, inheriting from the interface, is that it removes any manipulation being needed with the actual *.svc file.  It just seems, at least to me, a little bit cleaner this way.

[sourcecode language=”csharp”]
namespace EndToEnd.Mvc
{
public class EndToEndService : InvestorBase
{}
}
[/sourcecode]

For the last touches for the WCF RESTful Service we need to setup the Web.Config file.  I’ve added the section toward the bottom of the config file in the <System.ServiceModel> section.  I’ve included the full config file below, so you can easily just copy and paste it if you’re working through step by step with me.

[sourcecode language=”html”]
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
</compilation>
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>
<pages>
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
</namespaces>
</pages>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="httpBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="ServicesBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<services>
<service behaviorConfiguration="ServicesBehavior"
name="EndToEnd.Mvc.EndToEndService">
<endpoint address="" behaviorConfiguration="httpBehavior" binding="webHttpBinding"
contract="EndToEnd.Mvc.IEndToEndService" />
</service>
</services>
</system.serviceModel>

</configuration>
[/sourcecode]

One of the things I always do at this point is to setup the project properties.  I do this for a number of reasons, primarily to assure that the port number doesn’t go and change itself on me.  The other thing I set is the default startup page.  With ASP.NET MVC things get out of sync with Visual Studio, and Visual Studio tries to startup actual *.aspx files.  So what I do is just set the startup to an empty root startup.  These settings are shown below.

Project Properties
Project Properties

Setting up the MVC Parts

First add a home directory, a HomeController.cs, and then add a Core.Master master page to the project.

MVC Project Parts
MVC Project Parts

Next setup the Core.Master file with the following content sections.

[sourcecode language=”html”]
<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"&gt;

<html xmlns="http://www.w3.org/1999/xhtml&quot; >
<head runat="server">
<title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

<script type="text/javascript" src="../../Scripts/jquery-1.4.1.js"></script>

<asp:ContentPlaceHolder ID=HeaderContent runat=server>
</asp:ContentPlaceHolder>

</head>
<body>
<div>
<asp:ContentPlaceHolder ID="MainContent" runat="server">
</asp:ContentPlaceHolder>
</div>
</body>
</html>
[/sourcecode]

One of the things I’ll point out is that with Visual Studio 2010 you get Intellisense with jQuery.  The reason I don’t use the x.x.min.js version of the jQuery is that it doesn’t have the appropriate setup to provide the Intellisense.  So be sure for development to use the fully expanded version and you can go to the zipped min version when you go live in production.  Another thing I do, which may vary on how you want to develop, is use the hosted jQuery on Google or Microsoft.  I did a write up previously for using the hosted jQuery so check it out for reference locations.

In the controller add the following code.

[sourcecode language=”csharp”]
using System.Web.Mvc;

namespace EndToEnd.Mvc.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
return View();
}
}
}
[/sourcecode]

Now that we have the Site.Master and the home controller, create an Index.aspx View in the Home folder of the project.

Adding the Index.aspx View
Adding the Index.aspx View

In the view add the following code for the jQuery calls to the services layer.

[sourcecode language=”html”]
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Core.Master" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
jQuery AJAX Calls to RESTful WCF Web Services
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="HeaderContent" runat="server">
<script type="text/javascript">
var domainRoot = "http://localhost:1000/EndToEndService.svc/&quot;;
var investorUri = domainRoot + "investor/";
var investorsUri = domainRoot + "investors/10/15";
</script>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
<h2>
jQuery AJAX Calls to RESTful WCF Web Services
</h2>

<div id="InvestorUri">
</div>
<div id="InvestorResult">
</div>

<hr />

<div id="InvestorsUri">
</div>
<div id="InvestorsResult">
</div>

<script type="text/javascript">

$(‘#InvestorUri’).html(investorUri);
$(‘#InvestorsUri’).html(investorsUri);

$.getJSON(investorUri, function investor_complete(json) {
$(‘#InvestorResult’).html(‘<li>’ + json.Id + ‘</li>’ + ‘<li>’ + json.Text + ‘</li>’);
});

$.getJSON(investorsUri, function investors_complete(json) {
var builtHtml = ”;

$.each(json, function (x, y) {
builtHtml += ‘<li>’ + json[x].Id + ‘</li>’ + ‘<li>’ + json[x].Text + ‘</li>’;
});

$(‘#InvestorsResult’).html(builtHtml);
});

</script>
</asp:Content>

[/sourcecode]

Run it and you should get the following displayed on screen.

Browser Results
Browser Results

Let me know if you run into any issues trying this out.  Thanks!

Shout it

Waterfall vs. Agile

Before reading this you should know what the Agile Manifesto is and the Agile Principles are.

I’ve seen it on more than one project in my career and it always seems to happen.  Agile rarely gets credit in this scenario.  People rarely learn what was and was not effective on the project in this scenario.  Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know.  What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.

The scenario generally starts like this…

A project is green-lighted for whatever reason.  Often with some high level manager determining that a project will save or make $X amount of money.  The project is poorly defined or simply not defined at all.  The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management.  There are at least a half dozen external dependencies the project must have completed.  (Take Note Upper Management & Executives:  Six Sigma/Lean Processes can help at this level dramatically)

Waterfall Approach

In a waterfall approach all of these things will have to be documented and nothing initially gets developed.  The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with.  In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation.  To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software.  A 6th grader would study this and say, “so they write a bunch of lies right?”

When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start.  Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down.  Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.

Agile Approach

An Agile approach on the other hand would start finding the clients and consumers of the theoretical software.  These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created.  Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do.  The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated.  Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks.  A 6th grader would study this and say, “you’re building software and having fun?”

What Happens in the End, IF the Waterfall Project is Successful

There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful.  The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately.  This cleans up things and improves morale, all while getting the project back on track.  The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management.  Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.

In Summary

These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used.  I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government).  Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another.  This is something else I’ve seen far too often.  This is a complete misrepresentation of what Agile Ideals and processes are.

The Questions

I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations?  Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed?  Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?

Please leave a comment or three.  🙂

My Team is 10x Better Than Your Team

Yes, 10 times better.  That’s the difference between an average software programmer on an average software team and a rock star programmer on a rock star development team.  The difference is huge, and I’ve been reminded of this lately.

How is this different?  How is the rock star team 10x better?  How is it 10x faster?  How does the average slug along or even survive?

Simple.

The average software teams barely get by.  The average teams are almost always in a reactive mode versus a proactive mode.  Often average teams only get proactive if they build up a huge bureaucracy around themselves, which just allows them to be average.  Average teams might call themselves Agile but don’t follow any of the ideals, let alone the processes that actually enable the PEOPLE to be rock stars.

Over the years I have seen more than a few teams of 5-10 people, sometimes more, only produce what a rock star could produce alone.  5-10 people, $500k to a $1m per year, versus about $100-120k.  That’s 5-10x the cost.  When I first read about this I thought it was silly, nonsense, and generally impossible for developers to be that disparate in abilities.  I know now that I was wrong.  Developers DO differ that much in abilities.

Joel Spolsky wrote about it (and NO, even though I’ve mentioned him a number of times recently, I don’t always agree with him) and he’s spot on.  Hiring and keeping the top programmers is key to success.  Hiring average developers will sink a startup, drag an established company under, and destroy even the most stable of companies.

I’m going to cover some key points that prevent having average developers and prevent an average team sinking the ship.  These aren’t, “well maybe we’ll do these things”, these are “things that must happen, all or at least most of them, for the success and continued success of a company”.  This list is aimed at external observations of teams I’ve seen at Amazon, Microsoft, Webtrends, and others.  Some of these things are done so that the companies keep as large a part of their work force as rock stars as possible.  This is what makes these companies successful.

Successful Companies…

Successful companies encourage and perpetuate continued learning.  Not “I read a new technical book once a year”, I’m talking about rock stars that read a technical book or three per month (get a new one now @Amazon), try new languages whenever a new one crops up (re: Ruby, F#, Erlang, others…), encourage quite work areas, collaboration online, offline, and elsewhere, plenty of white boards and open workspaces, and even funds for out of company education with training courses or otherwise.

Successful companies involve themselves, specifically their technical people, with the social scene around their core technologies the company is built on.  Amazon & Microsoft have this fairly easy, as they’ve built their own social scenes around their respective technology.  Webtrends has even done so to some degree.  Smaller companies should be involved in some of these large companies scenes.  Attending conferences, training, or otherwise being involved with these companies is a great way to do just that.  This builds morale for your rock stars and rock star teams.

Successful companies provide optimal work environments.  Of course, work environments and what is optimal is up for debate.  But generally one can determine if the company at least involves itself enough to try.  Successful companies continually ask themselves things like;  are developers more productive in offices or not, do some developers work better remotely or in office, are developers different any some work better in some environments and not others?  Usually companies that ask these questions realize the later implication that developers are different from one developer to another.  Successful companies have leadership that can determine this and work with the developers to make sure they stay productive, challenged, and happy in their positions.

Successful companies push what makes their technology, product, or ideas interesting and fun to work with.  This may not be super easy for some companies, but even a trash pickup company has to have a cool back end system that uses the latest and greatest and might be migrating to the cloud or something.  Something is cool or interesting about what the company does, and that cool and interesting tech should be known and shown as a key reason the company rocks and should have rock star teams and rock stars on that team.

These are the top things that make an awesome team help build a successful company.  Do any others come to mind?  Please leave an idea or two, or disagree, tell me why rock stars aren’t 10x as productive or why successful companies may not need to focus on great development teams!  There’s always a devil’s advocate somewhere out there on the Interwebs, so light up the fire.

Those People That We’re Always Looking For…

I’ve been rereading Joel Spolsky’s “Smart and Gets Things Done”.  His writing style is entertaining.  I’m not always in 100% agreement with the guy, but who ever agrees 100% with anyone right?  However, Joel has a ton of things that are smart, well thought out, and when one pays heed can really help out during the course of a software project.  Since I’ve been writing on this topic lately, I figured it would be a great idea to give this a read and maybe even add my two cents to a few of his passages.

I didn’t get very far and I had already found one bit that I wanted to elaborate on.  This part was in remark to hiring college interns and the fact that the best college students are often already good programmers.

“The good news about our field is that the really great programmers often started programming when they were ten years old.  And while everyone else their age was running around playing “soccer” (this is a game many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux Kernal to compile.  Instead of chasing girls in the playground, they were getting into flamewards on Usenet about the utter depravity of programming languages that don’t implement Haskell-style stype inference.  Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access Wi-Fi point, all the images on the web appeared upside-down.  BWA HA HA HA HA!”

This got me thinking.  I’d like to find programmers who have started a band, chased the girls, played soccer, flipped the images, argued the Haskell points, compiled a Linux Kernal (or two or three), and more.  I don’t want the all exclusive nerd only programmer, because today they’re often not that useful on software projects.

When I’m looking for other developers to hire and work with I want a number of things.  The technical bits are of course important, very much so, but I want to work with developers who know about all sorts of things.  I want programmers that know why financial application development pays well and non-profit work doesn’t, I want them to know about the successes and losses of business endeavors within the software industry.  Most importantly, I want them to be personable, approachable, and interested in life beyond just hacking lines of code 24/7.  Nothing wrong with the later, but that is only helpful for about 20-40% of the time on a project.

Warren Buffet looks for the criteria of “integrity, intelligence, and energy”.  I’m curious, readers out there in reader land, when you’re looking to work with a team or hire a team member what do you look for?  What are some key indicators besides the white board coding questions and technical bits?