Would you choose webforms or MVC on a new project?

Many readers probably consider this obvious, perhaps even equivalent to the choice between punch cards vs keyboard/monitor. I suspect most people reading this consider asp.net-MVC the logical choice, and only an idiot would choose otherwise

However, I suspect most Microsoft web application developers would still chose webforms … scary as that is.

I think that right now, MVC has really separated the good from the bad, at least as far as asp.net developers go. Developers on top of their game have at least overview experience with MVC, yet most weak or lazy developers haven’t been forced to make the leap yet, as a result they either haven’t looked into it, or have been so confounded by the paradigm shift that they’ve passed it off as a trendy fad.

Please notice I said ‘choose on a new project’, not ‘currently working in’. I’m sure there are many developers who are working in webforms who would prefer to be working in MVC … I’m one of them. On the flip side, I recently met a developer working in an MVC app who wishes it was webforms.

There is a presumption in my statement, that MVC is inherently better than webforms. To most of us, this seems obvious, but there are many who disagree … and that’s fine. However, I’ve yet to find a valid argument for webforms over MVC.

… don’t get me wrong, I’ve heard people tell me that webforms is better, but I’ve never heard a rational argument. Those who have tried have basically given me buzzwords like ‘event-driven’ but fail to contrast it against, or even recognize the cost of that paradigm.

Take for example; answers to this Stackoverflow question When to favor webforms over MVC? I’m not going to argue about integrating MVC into an existing webforms app because I think maintaining technology consistency is important. But some of the other reasons include :

1. Leveraging existing training – True, but good developers usually keep their skills up to date, so is this really that big of a deal?
2. View/edit modes makes duplicate work – This is actually better than all edit pages, yes … even for enterprise apps. If you don’t believe me, just think about all the functionality you added to ensure users couldn’t ‘save’ … there’s no save button issues when they can’t even access the edit form.
3. Too many files – Don’t forget all those files allow for Single Responsibility and Separation of Concerns.  Basically they encourage a cleaner code base.
4. Issues with the master page consistency – This sounds more like an application issue than a framework issue.
5. Recognizable directory structure – You quickly get used to the MVC directory structure, and basic routing isn’t rocket science.
6. Powerful controls – True, but all that functionality will be ported to the MVC paradigm eventually. And for what it’s worth, I think partials are better than user controls.
7. Webforms is a shortcut to web development for Windows developers – True, but isn’t this the epitome of a bad dev? They don’t want to actually learn the tools they’re working with?
8. Views & controllers are combined in webforms – True, but separating them makes good programming practice like the Single Responsibility principle possible.
9. Somebody even suggested the page lifecycle gives you more control – Wow. Place a delete button on a grid row, then tell me this when you have to load the grid twice in your postback; once in the Load event to wire up the event logic, and again after you delete the data.

But the biggest reason cited everywhere seems to be ‘personal choice’. … LOL … yeah, if you’re smart you’ll go with MVC, if you don’t know MVC, don’t understand it, and don’t want to learn it, you chose webforms.

BTW, it’s not even about webforms sucking. Webforms has a lot of stuff to avoid, but it’s not just about that …. MVC is an enabler. Basically the MVC paradigm dove tails with so many good practices which are difficult in webforms (at best), like; Unit Testing (and easy mocking), Clean code, Separation of Concerns, Single Responsibility Principle, etc…  I’d even venture to bet there’s a noticeable correlation between modern software development processes (like agile) in MVC teams.

There’s a possibility this is a temporary thing, but I suspect it will last a lot longer than anybody expects, because bad developers don’t move to a new platform unless they’re forced. And judging by Microsoft’s continued “MVC doesn’t replace webforms” stance, it doesn’t look like they’ll be forced for a while.

Now as far as the ‘business reasons’ for choosing webforms go, having an abundance of developers, doesn’t really wash. At least it doesn’t if you bought into my opinion that webforms projects will attract low quality developers, and repel high quality devs.

What if businesses chose MVC for ‘business reasons’? Instead of aiming for an ‘abundance’ of devs, they aim for good devs, and plan to pay their slightly higher rates with the dramatic savings in development and maintenance?

PS-I sincerely looked for a good reason to chose webforms over MVC. If you know of any good reasons to choose it over MVC, please leave a comment or send me an email.

I realize this is an extremely naive statement to make, but I’m going to make it anyway; solving the ‘non-obvious’ aspect of a software patent is simple.

… and it doesn’t involve judges learning to code.

Here’s my proposal:  Software patent proposals should include a unit test suite and a single solution implementation.  The test suite would be made public immediately, without the implemented solution.  The public would take a crack at making the test suite pass.

If there are no successful passes, then it could be deemed as a difficult problem with a non-obvious solution.

If the patent office is bombarded with working solutions, then it unquestionably fails the ‘non-obvious’ test.

It’s debatable what to do if a relative few brilliant developers solve it, while most fail.  But this would definitely eliminate laughable patents like Amazon’s 1-Click which would have bombarded the patent office in less than an hour.

Unfortunately, while other developers use the same names, they often use them in ways you don’t expect. I kind of wish everybody would use this simple convention.

So here it is:

Id – In my little world, any variable or database column including the term ‘Id’ is an integer identifier for something. Usually non-negative and non-zero. I suppose it could be negative, although I would never do it, but it should never be zero since in many languages uninitialized variables default to 0. As is conventional, this is always my primary or foreign key.

No or Number – I use the term ‘No’ or ‘Number’ for alphanumeric identifiers usually. Why am I calling a string ‘Number’? Because that’s how we communicate; Customer Number, Item Number, Vendor Number, etc… Identifiers with the word ‘Number’ in them are almost always strings, even our phone number or Social Security Number, which are made up of only digits, are usually stored as character strings by experienced developers.

Cd or Code – I use this for specific length identifiers which don’t change often. For example: State Codes (‘NY’, ‘WA’), order types, credit card types, etc…. I create enums for these values and evaluate them in the display instead of the database; I’ve just found that infrequent code changes make fewer joins on every query seem like a good trade off. Codes are also almost always displayed as drop down lists on the screen and their abbreviation makes direct database easier as well (as opposed to having a provinces table, and a province id of 3).

Key –I don’t use this term very much, but I would use it for something like an application key rather than an identifier and it would be an alpha-numeric string.

This is pretty basic, but consistency counts. Running into variables named UserId instead of UserName, and then XxxUserId for the user id adds nothing but confusion. Even after seeing it for months, it will still throw you off, and when you create a new method requiring a user id as a parameter, do you call it userId? Or xxxUserId? And when it’s named with a prefix like this, it’s not even like it comes up in autosuggest to constantly remind you of the difference. Yes, you *could* rename the variables all throughout your code, but then you’ve still got it in the database which has a lot more dependencies, many of which are undocumented. … but I digress …

I should also point out, there are times when I don’t follow these conventions, for example, I don’t call user names ‘User Number’, nor do I call ‘UPC’ (Universal Product Code) a ‘Universal Product Number’ as my definitions might suggest. But for the most part, every app I’ve designed in the past 10 years has this convention.

One more thing, if I’m generating these strings, I never use vowels, since it’s only a matter of time before something offensive is generated. You can check for the obvious swear words, but you won’t catch them all … but without vowels, nothing will get through, ever. Even something which appears as though it might be offensive, without vowels, it will be chalked up as an overly active imagination.

So, before I even wrote a line of my own code, I started writing tests for the generated code, and as you might expect, it wasn’t long before I started running into static methods which cannot be mocked with Moq (the mocking framework I was using).

Here’s an example of an action method I tested:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

[HttpPost]
public ActionResult LogOn(LogOnModel model, string returnUrl)
{
  if (ModelState.IsValid)
  {
    if (Membership.ValidateUser(model.UserName, model.Password))
  {
  FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
  if (Url.IsLocalUrl(returnUrl) && returnUrl.Length > 1 && returnUrl.StartsWith("/")
  && !returnUrl.StartsWith("//") && !returnUrl.StartsWith("/\"))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
else
{
ModelState.AddModelError("", "The user name or password provided is incorrect.");
}
}
 
// If we got this far, something failed, redisplay form
return View(model);
}

Notice, the Membership.ValidateUser() & FormsAuthentication.SetAuthCookie() methods are static and untestable.

The strategy I found for testing these methods was to create wrappers, so I created the following classes.

1
2
3
4
5
6
7

public class MembershipWrapper : IMembershipWrapper
{
public bool ValidateUser(string userName, string password)
{
return Membership.ValidateUser(userName, password);
}
}

and

1
2
3
4
5
6
7

public class FormsAuthenticationWrapper : IFormsAuthenticationWrapper
{
public void SetAuthCookie(string userName, bool rememberMe)
{
FormsAuthentication.SetAuthCookie(userName, rememberMe);
}
}

And a couple interfaces

1
2
3
4

public interface IMembershipWrapper
{
bool ValidateUser(string userName, string password);
}

And

1
2
3
4

public interface IFormsAuthenticationWrapper
{
void SetAuthCookie(string userName, bool rememberMe);
}

Not exactly rocket science.

Once I finished that, I also had to handle the Controller.Url property. I used a technique I found at @nvthoai’s site.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public interface IUrlHelperWrapper
{
string Action(string actionName, string controllerName);
 
string Action(string actionName, string controllerName, object routeValues);
 
string Action(string actionName, string controllerName, RouteValueDictionary routeValues);
 
bool IsLocalUrl(string url);
}
 
public class UrlHelperWrapper : UrlHelper, IUrlHelperWrapper
{
internal UrlHelperWrapper(RequestContext requestContext)
: base(requestContext)
{
}
 
internal UrlHelperWrapper(RequestContext requestContext, RouteCollection routeCollection)
: base(requestContext, routeCollection)
{
}
 
public UrlHelperWrapper(UrlHelper helper)
: base(helper.RequestContext, helper.RouteCollection)
{
}
}

Then I had to create class member variables in the controller

1
2
3

private IMembershipWrapper membership;
private new IUrlHelperWrapper Url;
private IFormsAuthenticationWrapper authentication;

And new constructors

1
2
3
4
5
6
7
8
9
10
11
12
13

public AccountController()
:this(new MembershipWrapper(),new FormsAuthenticationWrapper(), null)
{
}
 
public AccountController(IMembershipWrapper membershipObject,
IFormsAuthenticationWrapper formsAuthenticationObject,
IUrlHelperWrapper urlHelper)
{
this.membership = membershipObject;
this.Url = urlHelper;
this.authentication = formsAuthenticationObject;
}

Then override the Initialize method in order to setup my UrlHelperWrapper.

1
2
3
4
5
6

protected override void Initialize(RequestContext requestContext)
{
base.Initialize(requestContext);
if(Url == null)
Url = new UrlHelperWrapper(requestContext);
}

And finally, I changed the LogOn method to use the new wrappers instead of the static methods.

1
2
3
4
5

...
if (membership.ValidateUser(model.UserName, model.Password))
{
authentication.SetAuthCookie(model.UserName, model.RememberMe);
...

Ok, yeah; nothing in there is rocket science. I admit it, and when you know what to do, it’s not difficult. However, a few things become painfully obvious when you do this:

1. 100% code coverage not only isn’t practical, it’s not even possible since the wrappers cannot be tested.

2. You’ll have to create a new wrapper for every static method you ever use. I suppose you could use one wrapper for all static methods, but I prefer to keep the class names lined up.

3. I need to pass a wrapper instance into the constructor for every wrapper my testing *class* contains, as opposed to the *Action* I’m testing.

4.I have to design my code in a specific way (a way which I would NEVER do on my own) in order to make it testable.

So my test winds up looking like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[TestMethod]
public void Logon_ValidReturnUrl_ReturnsRedirectToUrl()
{
// Arrange
Mock membership = new Mock();
membership.Setup(m => m.ValidateUser(It.IsAny(), It.IsAny())).Returns(true);
Mock authenticator = new Mock();
Mock urlHelper = new Mock();
urlHelper.Setup(h => h.IsLocalUrl(It.IsAny())).Returns(true);
var controller = new AccountController(membership.Object, authenticator.Object, urlHelper.Object);
var model = new LogOnModel();
const string testUrl = "/something/inteREsting/2/ensure/test/returns/correct/url/";
 
// Act
ActionResult result = controller.LogOn(model, testUrl);
 
// Assert
Assert.IsNotNull(result);
Assert.IsInstanceOfType(result, typeof(RedirectResult));
var redirectResult = result as RedirectResult;
Assert.AreEqual(testUrl, redirectResult.Url);
}

Now when I look at that test, and especially as the number of controller constructor parameters starts growing, and I add more tests with similar ‘arrange’ sections, I feel compelled to start cleaning and organizing my test code. I suddenly want to create test class member variables for each of the mocks required by the constructor, and add other overhead … I’m unsatisfied with the above code and really, really, want to clean it up.

So after spending a weekend writing that crap instead of adding features, I was sufficiently frustrated, and spent my drive to work Monday morning thinking about it. Mostly, I wondered long and hard about if tests are considered ‘waste’ from a Lean Startup point of view. And to be honest, I was really leaning toward … ‘yes: they’re waste’.

Then when I got to work, I was tasked with the challenge of how to unit test a webforms application, which is really a question of ‘How can we mock it?’ This search led me to Ivonna, which looked great but relies on TypeMock Isolator.

Now I’ve heard of Typemock before, I’ve actually followed them on Twitter for at least a year, but never really looked into it. To make a long story short, I was a little surprised by the price, and really couldn’t understand why anybody would pay when there are so many free mocking tools.

That’s when I found out I can mock static methods … which as you can imagine, after that weekend, I was intrigued to put it mildly …. actually ‘converted to fanboy’ status is probably a little more accurate.

Here’s the same test on the original method using Typemock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[TestMethod, Isolated]
public void Logon_ValidReturnUrl_ReturnsRedirectToUrl()
{
// Arrange
var controller = new AccountController();
Isolate.WhenCalled(() => Membership.ValidateUser(string.Empty, string.Empty)).WillReturn(true);
Isolate.WhenCalled(() => FormsAuthentication.SetAuthCookie(string.Empty, false)).IgnoreCall();
Isolate.WhenCalled(() => controller.Url.IsLocalUrl(string.Empty)).WillReturn(true);
var model = Isolate.Fake.Instance();
const string testUrl = "/something/inteREsting/2/ensure/test/returns/correct/url/";
 
// Act
ActionResult result = controller.LogOn(model, testUrl);
 
// Assert
Assert.IsNotNull(result);
Assert.IsInstanceOfType(result, typeof(RedirectResult));
var redirectResult = result as RedirectResult;
Assert.AreEqual(testUrl, redirectResult.Url);
}

When you compare this test with the test using Moq, the differences are trivial, but I don’t feel compelled to ‘clean it’, and … get this …. I didn’t have to change anything in my app.

Let me repeat that, I didn’t have to change anything in my app. I didn’t have to write any wrapper classes, modify my constructors, pollute my class with unnecessary member variables, or spend 45 mintues trying to figure out how to mock the Controller.Url property, or put part of my wrapper initialization code into the Initialize method because I couldn’t initialize one of my wrappers in the constructor.

I mean all those changes just felt like a wretched code smell.

But the Typemock test was all straight forward. I felt like I sprayed my code with deodorizer.

Maybe I was using Moq the wrong way, but based on my research on StackOverflow, it seems that wrappers are the way everybody is managing this. If you know a better way, please let me know in the comments.

PS-Last week I sat in on a Typemock seminar, and the guy doing the seminar, Gil Zilberfeld, said something which really resonated with me, he said

“If you’re doing things just for testing, you’re doing it wrong.”

…. it’s as if he was talking directly to me.

I was having lunch with my friend & colleague last week and we had a disagreement about whose decision it is to make a change when you see something wrong in the client’s software.

Mechanic analogy

My colleague used an analogy about a mechanic; it was a good one, so I’ll use it here.

Let’s say you bring your car in for a $30 oil change, and your mechanic notices a problem with the timing belt.  My colleague suggests, he doesn’t just ignore it, he tells you it’s an emergency must be changed immediately (the emphasis is my friends).

Well I agree the mechanic shouldn’t just ignore it, and I was relieved my friend didn’t suggest the mechanic should simply change the timing belt, driving the bill from $30 to $930, but I’m not sure if telling the car owner they must change the timing belt ‘now’ is appropriate either.

In my opinion the mechanic should tell the customer what he found, the risk in not fixing it, outline the options to fix it, and the cost & associated risk with each option[1].  Then make a recommendation.

It’s the customer’s decision, not the mechanics, and even if the customer makes a foolish decision, it’s his decision, not the mechanics.

Fortunately, all the mechanics I’ve dealt with seem to understand this.

As consultants we’re advisors, not the decision maker

In my opinion, our role as consultants / advisors includes the responsibility to inform the client of any problems or potential problems you’ve noticed, the risks in not fixing it, options to resolve the problem, along with the costs and risks associated with each.

Unethical behaviour

To me it seems unethical to go rogue, and just start making changes the client doesn’t know about, and didn’t approve.

It’s also unethical to purposely instil fear, uncertainty, and doubt when explaining the options to the client so they make the decision you want them to; regardless of your intentions.

The client owns your time

After all, the client does own the software, is responsible for its maintenance, and they do own your time to direct as necessary.

Wait, what?  Who owns your time?

Yeah, when you’re consulting, your client (or employer) owns your time.  … you sold it to them; remember?

Every consulting and/or employment agreement is different, but if you’re charging by the hour, it probably says something like this; they bought your focused efforts to solve their problems for a specific duration.

And how they spend your time (their resource) is up to them (within reason[2]).

So deciding feature X is more important than feature Y, or bug X is more important than bug Y, is their call, not yours.

An extreme example

But what if it’s a big important issue?  What if it’s a major security flaw in the banking software you work on.  The flaw is dangerous. The flaw could potentially put users at risk. The flaw could even push the company into bankruptcy.

But your manager doesn’t want to invest the time to fix it and his manager stands behind him.  You’ve exhausted all other paths of reason, to the point of being on the verge of getting fired.

You still don’t have the right to change it … not even on your own time, because the software is their asset, not yours.

Your decision

Now I’m not saying you have no say, you can refuse.  Bottom line: if they refuse to make a change that you feel is necessary and/or potentially dangerous, you can give notice and quit.

Exceptions

Like everything, there are exceptions to this general rule.  Here are 2:

The first is if you are working on one task, notice another problem, and can fix it without seriously adjusting your time budget on the original task.  An example of this might be noticing and fixing a 1-off error in a loop.  I once had the responsibility of making manual year end changes to customer databases, with an estimated time of 3 days for each.  It took me 4 iterations working smart within the allotted time to write and test a utility which dropped that task to a 1 hour job[3].  The utility was separate, so I didn’t change the base product, and it cost my employer nothing.  So it is possible to make an impact working like this.

The second exception is you have built up a lot of trust with the client, and are completely unsupervised, making whatever changes deemed necessary to accomplish the client’s goals.  I’ve been in this situation a few times, and can honestly say, it’s a rare situation to be in.  It’s reserved for the situation where the client trusts your character and your responsibilities are so mysterious that they cannot make a decision, so they leave it up to you.[4]

In Summary

So basically, in my opinion, as consultants it’s not within our rights to make the decision to change or coerce the client into allowing you to change something.  It’s our obligation to inform them of the problem, outline their options along with the risks and cost of each, and make recommendations.

… that’s it.

I just read Seth Godin’s blog post Where do ideas come from? And in my opinion he completely missed it.

Sorry, I think Seth is awesome as do many others, but on this one, I don’t think he really answered the question; where do ideas come from?  Instead, in my opinion, what he wrote was more a list of favourable conditions

While I’m no Seth Godin, I’m going to share my understanding of ideas and their source[1].

I hope I don’t need to explain why a post about ideas and creativity is on a programming blog.

Ideas come from questions

Ideas are answers to those questions.

Although it may appear that ideas come out of nowhere while driving to work or zoning out in the shower, they are really answering previously asked questions burning in your subconscious.  There are many conditions which help answers come more easily, but they never come if you don’t have the question in the first place.

Questions need to be installed into your subconscious

A fleeting question doesn’t quite make it into your subconscious to be answered later.  The question needs to be important enough to be prioritized by your mind.

Installations depth comes from emotion

The importance of the question is largely based on the intensity of the emotion driving the question.  That’s why many innovations come during massive change and crisis.  Fear and greed inspire many ideas.

New information is assimilated to answer these questions

New questions are never installed for questions you already have the information needed to answer it.  So you need more information to answer the question and will need time to assimilate new information which is filtered against your question.

This information can be from; feedback from action, random thoughts in the shower, synergy, social media, blogs, news, conversations, books, radio, lectures, etc…  And yes, Seth even television[2]

Fear constrains ideas

Fear eliminates ideas.  Whether criticism of a bad idea, or constraint, or even a well-meaning, ‘helpful’ person who’s experienced proves it cannot be done.

When people fear criticism, ideas are never put forth which may inspire better ideas.  All ideas must be valued for an innovative environment.

Forcing ideas constrains you to existing information

You’ll hear many people say that you sit down, brainstorm, make your decisions quickly and take immediate action, which is great, when you have all the information you need.  But unless you have all the information you need, forcing it quickly usually won’t give you an awesome idea.

Synergy is creativity’s compound interest

Ideas usually require time, but they can be sped up with synergy[3].

Synergy is instantaneous compound interest for creativity.

One idea (good or bad) leads to another idea, then another, and another.  Before you know it, the feedback cycle has taken you down an entirely different path.

But Seth was right about one thing

Ideas that don’t ship are worthless

I was humbled and honoured to make the list. … actually, I was a little more excited than that, here’s a dramatization ….

… Thanks John … I’ve been dying to use this video in a blog post.

Suppose you had software which matches buyers and sellers, and new users are created via a ‘new user’ wizard[1].  Let’s say the wizard has 4 pages for Basic User Info, Review, Processing, and Completion Status Report.  And there are 5 buttons; Cancel, Previous, Next, Run, and Finish.

Cancel is displayed from the Basic User Info, Review, and Processing pages.
Previous is displayed from the Review page.
Next is displayed from the Basic User Info page.
Run is displayed from the Review page.
Finish is displayed from the Completion Status Report page.

This isn’t difficult to manage the display from the events[2] right?

Well … in reality, it doesn’t take much of a change for your simple display functionality to become …

The Problem

Manipulating application display during events quickly turns into a complex, bug riddled, difficult to maintain, mess.

It may not seem like that big of a deal when you have only a few controls and a very simple (or no) workflow.  Actually, you may argue, managing visual display in the events may even seem like the most efficient strategy.  After all, you will never display, disable, or otherwise needlessly manipulate a control, but as your application grows more complex, this approach can leave you tearing your hair out[3].  This is especially true when you have multiple execution paths leading to the same event handlers with different state.

What if you received a change request for the above requirements, where additional info is required for buyers or sellers, resulting in a new wizard page for each, and in addition to that, business sellers require a page to gather Tax Information?

Your complexity has started to grow, resulting in buyers have a workflow of
Basic User Info -> Buyer Info -> Review -> Processing -> Completion Status Report

Individual sellers have a workflow of
Basic User Info -> Individual Seller Info -> Review -> Processing -> Completion Status Report

And commercial sellers have a workflow of
Basic User Info -> Commercial Seller Info -> Tax Info -> Review -> Processing -> Completion Status Report

Notice how these changes lead to different execution paths all arriving at the Review page.  The question then, is; where does the back button on the Review page send the user?  The back button requires logic to know which wizard page to display.

It’s not difficult to imagine the need for logic to be added in more than one place[4], which can result in your display being processed differently from every event.  Not only does this lead to repeated code, but can also create bugs where buttons do/don’t display where they should.

Eventually, as this logic grows increasingly complex, simple, 5 minute, change requests will eventually take you hours to determine there won’t be any side effects.

At this point, developers usually find …

Inadequate Solutions

So how do people manage this?  I mean, beyond having the logic at the control level.

Well, you can put controls for different states on their own panel for their states.  So in the example above, you could add the buttons directly onto the wizard page control[5].  This would ensure the correct buttons, for the panel, are displayed, but it doesn’t solve the ‘Back’ button logic of which page to display.

Or you could add some kind of control grouping mechanism, like a collection of the controls, to display or hide all controls at once.  The problem with this, is what happens when you have functionality which will enable/disable a specific control, or do something else?  Do you add another grouping or another function to manipulate your control group, or do you have that one function do enabling/disabling as well?  What happens if the enabling/disabling logic is different from the display logic?  You also have the problem of one control being in multiple groups; will your groupings need to be called in the order of hide, then show, just to get the control that’s in both groups to display?  And if you do, will you let the control flicker? Or will you add extra functionality to prevent specific controls from hiding in the first place, so it won’t flicker?

Or maybe you can make a centralized function to manage the controls where the display is based on the passed in parameters.  Well this is very close, but no cigar.  Not only are the parameters needless, as I’ll show later, but this won’t completely remove logic from the events and can needlessly increase logic in that function.

The solution most have preferred is to make screens as minimal as possible, with a new screen for each piece of functionality.  This is often effective, at the cost of usability, but sometimes has its own problems like managing state while gathering data from multiple screens to persist it all in one shot.  Not even to mention that this strategy would be ineffective in our example.  Besides, in my experience, you can never really get away from at least some display manipulation.

This is a small example; imagine having a screen with 50 controls, where many of them change state.  Imagine how difficult it would be to manage the display this way.

Hopefully you can see how this can turn into a major pain in the butt.

Well, the good news is this problem has been solved …. Solved a long time ago actually[6].

The solution is ….

The UpdateUI() Method

It’s pretty simple really; just create a single function for the entire page, view, form, or screen (whatever it’s called in your technology).  All this function does, is manage the control display.  Then call this function at the end of every event, after all data manipulation.

It’s pretty simple; there are just …

5 Rules for the UpdateUI() method

1.     Fast – Don’t do anything which isn’t fast.  The state data driving the display decisions should already be calculated.

2.     No parameters – You should be able to make all decisions about display using the current screens state.

3.     No side effects – Don’t manipulate data within this method.  Not only can it slow it down, but it can also lead to inconsistent display evaluations.

4.     Manage each control individually – Don’t hide all controls, then show the controls you want displayed.  This causes flicker and adds unnecessary complexity.

5.     Call it last – call this function at the end of every event.

Code Sample

Here’s a little sample of what the wizard UpdateUI() code might look like.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public void UpdateUI()
{
 basicUserPg.Visible = (CurrentPage == NewUserWizardPage.BasicUserInfo);
 buyerPg.Visible = (CurrentPage == NewUserWizardPage.BuyerInfo);
 individualSellerPg.Visible = (CurrentPage == NewUserWizardPage.IndividualSellerInfo);
 commercialSellerPg.Visible = (CurrentPage == NewUserWizardPage.CommercialSellerInfo);
 commercialSellerTaxPg.Visible = (CurrentPage == NewUserWizardPage.CommercialSellerTaxInfo);
 reviewPg.Visible = (CurrentPage == NewUserWizardPage.Review);
 processingPg.Visible = (CurrentPage == NewUserWizardPage.Processing);
 compeletedPg.Visible = (CurrentPage == NewUserWizardPage.CompletionStatusReport);
 
 cancelButton.Visible = (CurrentPage == NewUserWizardPage.BasicUserInfo
                     || CurrentPage == NewUserWizardPage.BuyerInfo
                     || CurrentPage == NewUserWizardPage.IndividualSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerTaxInfo
                     || CurrentPage == NewUserWizardPage.Review);
 previousButton.Visible = (CurrentPage == NewUserWizardPage.BuyerInfo
                     || CurrentPage == NewUserWizardPage.IndividualSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerTaxInfo
                     || CurrentPage == NewUserWizardPage.Review);
 nextButton.Visible = (CurrentPage == NewUserWizardPage.BasicUserInfo
                     || CurrentPage == NewUserWizardPage.BuyerInfo
                     || CurrentPage == NewUserWizardPage.IndividualSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerTaxInfo);
 runButton.Visible = (CurrentPage == NewUserWizardPage.Review);
 finishButton.Visible = (CurrentPage == NewUserWizardPage.CompletionStatusReport);
}

This is quite a bit simpler than having the code sprinkled throughout the screen’s logic.

You may also want to move many expressions into their own protected properties. For example, you may want to change …

1
2
3
4
5
6

cancelButton.Visible = (CurrentPage == NewUserWizardPage.BasicUserInfo
                     || CurrentPage == NewUserWizardPage.BuyerInfo
                     || CurrentPage == NewUserWizardPage.IndividualSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerInfo
                     || CurrentPage == NewUserWizardPage.CommercialSellerTaxInfo
                     || CurrentPage == NewUserWizardPage.Review);

… to …

1

cancelButton.Visible = DisplayCancelButton;

Unfortunately, if your screen has a lot of controls, you may end up with a lot of these properties.  Because the state used to make the display decisions is usually in that screens class, it’s difficult to move these expressions into a separate class.  Or at least it is difficult to make a generalized statement about how to do it.

Where to use

This technique can be used in every GUI language or technology I’ve ever worked with.  I’ve used this strategy in Classic VB, C++ (MFC[7], Win32), Classic ASP, PHP, JavaScript, ASP.NET webforms[8] , etc…

This technique can significantly reduce Ajax initiated display adjustments.

Costs

The cost to managing your display this way is a slight increase in computing power required to calculate every display decision on every event.  However, in reality, if your UpdateUI() function causes a performance issue that’s noticeable, you’ve probably missed one of the rules stated above.

In my opinion, the increased simplicity, and cleanliness of you code, more than makes up for the slight increase in processing.

Conclusion

The UpdateUI() method is an efficient and effective way to keep your display manipulation code clean & bug free.  Even if your screen is relatively simple, you still benefit from having all your code in one place, and if it does grow in complexity, it will be manageable.  This technique has saved me countless hours of frustration.

Copyright © John MacIntyre 2010, All rights reserved

[1] These examples are really difficult to come up with, so let’s just go with this.  In reality many screens will be much more complex as well.

[2] I don’t necessarily mean ‘code behind your buttons’, but any logic executed specifically for this button, as a result of clicking it.

[3] For proof, see my avatar. 

[4] As if one place isn’t enough

[5] Wizard page controls are on their own panel of course, I mean we’ve all definitely learned that haven’t we?

[6] MFC had UpdateUI() as a virtual method on its main window class in the mid-1990s.  Fortunately, this was one of the only new paradigms Microsoft has ever added which did not undo the solution I came up with in the last paradigm

[7] The name actually comes from the CView::UpdateUI() method in MFC which was a core method for all UI related activity, before MFC I was calling it EnableCtrls().

[8] In ASP.NET WebForms, this function is called Page.PreRender.  However, this solution isn’t the greatest, since any control with an event needs to be populated in Page.OnInit just to wire up events properly.

Thanks to Cory Fowler for reviewing my post.

Earlier this week I posted What is too simple and small to refactor? about a  follow up to my first Clean Code experience where I took a very small function, and refactored it.  In the end I was truly questioning; how small is too small to refactor?  This post received quite a bit of a response, including a response from Uncle Bob Martin and several refactors from Cliff Mees, Neal Blomfield (his response), Cory Fowler,  Ben Alabaster begin_of_the_skype_highlighting     end_of_the_skype_highlighting, and even Jon Skeet.

My Twitter Worth Mentioning(?)

“..I’d explain why, but I have to, like, go put on lipstick.”-@aalear responding to a comment “females are too busy being beautiful” #gogirl 8:25 PM Sep 15th

My recent blog posts have generated a lot of feedback among my friends & colleagues. I’m glad. It’s a great conversation. 12:09 AM Sep 15th

I’m going to create a restaurant review site & call it StickyTables.com 12:51 PM Sep 13th

“Clean Code is a design philosophy more than a naming convention.” – me #justQuotedMyself #dealWithIt 12:36 PM Sep 13th

If somebody says my code sucks & they’ll redo it, I’d be hurt. But for my design, I’m relieved. #msPaintSucks 10:56 AM Sep 13th

Just saw a really cool job title on LinkedIn “Experienced Code Poet” 11:04 PM Sep 12th

When I hear “the cloud” I know I no longer understand what the other person is talking about. #widelyMisusedTerm 9:58 PM Sep 12th

Friday; I love you, but you come way too fast. #in 7:12 AM Sep 17th

Even when they score a major coup to attract & add value to users, the announcement is littered with comments like “Who uses @MySpace? ” 11:16 AM Sep 16th

Got to say; one of the biggest challenges I have blogging is coming up /w relevant examples. 8:17 AM Sep 16th

#FF @unclebobmartin not for his Clean Code msg, which is awesome, but for addressing your questions & concerns. #wayToGo about 19 hours ago

A programmer started to cuss Cause getting 2 sleep was a fuss As he lay there in bed Looping round in his head Was while(!asleep()) sheep++; 9:13 PM Sep 8th (this wasn’t mine, it was quoted from a StackOverflow question)

In my opinion ‘no written requirements’ is the biggest kiss of death a project can have. #stackexchange http://bit.ly/d3rho2 5:42 PM Sep 8th

I don’t hate technical buzzwords, only the ones non-tech people have hijacked. 4:17 PM Sep 16th

Wisdom from Twitter

@utahkay We’ve outsourced your project to a colony of bacteria. Not the best programmers, but you can get a lot of them for cheap. 6:08 PM Aug 28th

@datachick “repay technical debt as soon as possible” @drsql #24HOP #DarcVC 6:19 PM Sep 16th

@justicegray I have a dream that one day it will take more to be an “industry expert” in software development than just calling yourself one publicly. 8:37 PM Sep 14th

@BenAlabaster You had me at “Hello World!” #ProgrammerPickupLines 7:40 PM Sep 17th

@wrox Stupid password policies just make people use stupid passwords 12:01 PM Sep 17th

@MichaelKramer Sorry IE9, I can’t use you. I’m still too pissed about IE6. 4:08 PM Sep 15th

@carlosfigueroa If you can’t be replaced, you probably can’t be promoted. 12:56 PM Sep 9th

@cammerman Everyone thinks their opinions are rational, but often they’re merely rationalized. 11:07 AM Sep 9th

@KentBeck if you don’t have a good name for it, give it a bad name. a really, really bad name so you’ll fix it later. 7:31 PM Sep 8th

@_KYA “The beauty of the Internet is you can just pull a quote out of your ass and attribute it to whoever the fuck you want.” – George Washington 8:19 PM Sep 7th

Recommended links found this week

Periodic Table of the Elements (via John D Cook)

Threading in C#

Why software development metaphors always fail

Finally The Entire Interview with Uncle Bob Martin

Khan Academy

Tools and Utilities for the .NET Developer

Videos this week

This one is freakin hilarious.  Here’s a quote “Does /dev/null/ support sharding?”  Mongo DB is web scale Unfortunately, I can’t embed it.  Here’s the sequel Episode 2 – All The Cool Kids Use Ruby.  I also saw MySQL is Not ACID Compliant, which is basically the same as Mongo DB is Web Scale, but about MySQL.

Here’s a great quote from the following video:  “How many languages to you have to know to get a god damn web page up?” – @unclebobmartin
[youtube=http://www.youtube.com/watch?v=mslMLp5bQD0&fs=1&hl=en_US]
[youtube=http://www.youtube.com/watch?v=4F72VULWFvc&fs=1&hl=en_US]

Shortly after reading Robert C Martin‘s Clean Code, I refactored the data access layer from a project I was working on, and was amazed by how much the code improved. It really was night and day. My first clean code refactoring experience was an obvious improvement.

I was still on that clean code high, when a little function entered my life that I was compelled to refactor. This one left me questioning the limits of what I should refactor and if my refactor even qualified as clean.

I’d like to share that second experience with you in this post.

Original Code

Here is the original code. The code was written by and owned by Jim Holmes. Jim was kind enough to give me permission to use it in this post, as I was unable to find an equivalent example. Thanks Jim.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public static float WageCalculator( float hours,
                                    float rate,
                                    bool isHourlyWorker)
{
    if (hours < 0 || hours > 80)
    {
        throw new ArgumentException();
    }
    float wages = 0;
 
    if (hours > 40)
    {
        var overTimeHours = hours - 40;
        if (isHourlyWorker)
        {
            wages += (overTimeHours * 1.5f) * rate;
        }
        else
        {
            wages += overTimeHours * rate;
        }
        hours -= overTimeHours;
    }
    wages += hours * rate;
 
    return wages;
}

So as you can see, this simple method calculates a workers weekly pay based on hours worked, their hourly rate, and if they receive overtime or straight pay. There really isn’t much to it, is there?

So why was I compelled to refactor such a simple piece of code?

As soon as I opened this function, I felt it was doing too much. Mostly it was the isHourlyWorker parameter.

Since reading Clean Code, I’ve come to realize boolean and enum parameter types are a huge tell that they should be refactored into separate classes.*

My refactored code

So what did my refactored code look like after spending 30 minutes or so playing with it?

Well, here’s the new class diagram first, so you get some idea what you’re looking at.

And here’s the code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public abstract class WageCalculatorBase
{
    public float HoursWorked { get; protected set; }
    public float HourlyRate { get; protected set; }
 
    public WageCalculatorBase(float hours, float hourlyRate)
    {
        if (hours < 0 || hours > 80)
            throw new ArgumentOutOfRangeException("Hours must be between 0 and 80.");
 
        HoursWorked = hours;
        HourlyRate = hourlyRate;
    }
 
    public abstract float Calculate();
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

public class WageCalculatorForEmployee : WageCalculatorBase
{
    public WageCalculatorForEmployee(float hours, float hourlyRate)
        : base(hours, hourlyRate)
    {
    }
 
    public override float Calculate()
    {
        if (IsOvertimeRequired)
            return CalculateWithOvertime();
        return CalculateWithoutOvertime();
    }
 
    protected bool IsOvertimeRequired
    {
        get
        {
            return HoursWorked > 40;
        }
    }
 
    protected float CalculateWithoutOvertime()
    {
        return HoursWorked * HourlyRate;
    }
 
    protected float CalculateWithOvertime()
    {
        float overTimeHours = HoursWorked - 40;
        return (overTimeHours * 1.5f + 40) * HourlyRate;
    }
 
    public static float Calculate(float hours, float hourlyRate)
    {
        WageCalculatorForEmployee payCalc = new WageCalculatorForEmployee(hours, hourlyRate);
        return payCalc.Calculate();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class WageCalculatorForContractor : WageCalculatorBase
{
    public WageCalculatorForContractor(float hours, float hourlyRate)
        : base(hours, hourlyRate)
    {
    }
 
    public override float Calculate()
    {
        return HoursWorked * HourlyRate;
    }
 
    public static float Calculate(float hours, float hourlyRate)
    {
        WageCalculatorForContractor payCalc = new WageCalculatorForContractor(hours, hourlyRate);
        return payCalc.Calculate();
    }
}

And the code to execute this would be as simple as

1

weeklyPay = WageCalculatorForEmployee.Calculate(hoursWorked, hourlyRate);

or

1

weeklyPay = WageCalculatorForContractor.Calculate(hoursWorked, hourlyRate);

Or as flexible as

1
2

WageCalculatorBase wageCalculator = WageCalculatorFactory.Get(employeeInfo, hoursWorked, hourlyRate);
weeklyPay = wageCalculator.Calculate();

So as I said earlier, it was the isHourlyWorker parameter which compelled me to refactor. Notice how this parameter no longer exists, and has been replaced by a class for each of the potential values. isHourlyWorker has become the WageCalculatorForEmployee class, and !isHourlyWorker has become the WageCalculatorForContractor class.

Now one of the first questions you may have about the refactor is why didn’t I implement the Calculate method in the WageCalculatorBase class, instead of declaring it as abstract? Especially since both derived classes have identical methods, namely the CalculateWithoutOvertime method in the WageCalculatorForEmployee class, and the Calculate method in the WageCalculatorForContractor class.

What the hell happened to DRY?

I considered doing that, but decided that the Calculate method is such an important and critical piece of functionality, that implementation should not be left to chance. I felt an explicit implementation should be required.

And while we’re on the topic of the CalculateWithoutOvertime() method, you may be asking yourself, why this method even exists? I mean couldn’t CalculateWithoutOvertime(), CalculateWithOvertime(), and the IsOvertimeRequired property have been easily implemented in the Calculate() method?

Yes, as a matter of fact, I could have done it in a single expression, but felt it might be complex enough to warrant a comment, so I added the commenting into the structure, and kept the complexity way down.

Observations

Something else you may notice is the lack of control statements and flow branching. Notice, there are barely any ‘if’s. You may also notice the methods are very small, with the longest method being only 4 LOC, and most are 2.

You may also notice the increase in structural complexity, as noticed in Clean Code Experience #1.

But the real kicker to this refactor is that the original 26 lines of code became 74 when the refactoring was completed (including whitespace and everything). That’s a near 300% LOC increase!

This r-e-a-l-l-y bothered me, and left me perplexed as to if my refactor was foolish or wise.

Good idea?

So was it a good idea to refactor it? Is this clean code? Or was I just over stimulating myself with the refactoring? Was I partaking in refactoring masturbation?

I mean really … this wasn’t a complex function. There was nothing wrong with the function and the amount of code actually increased.

It took me a long time to wrap my head around this, but I finally decided this was good code. This was clean code. This was appropriate if creating code from scratch. This might be appropriate if working on client code.

.. Wait! .. what?

What do I mean, might be appropriate?

Would I do it in real life?

There is an ROI on business software. Unfortunately, software is not merely our art and our craft. Software is an investment. Software is a financial investment. More specifically, it’s not even our financial investment, it’s our employers.

So should you spend 30 minutes refactoring the above code? Is there an ROI worth it?
As much as I want to do that refactor, and believe later maintenance will benefit from it, I seriously question if the ROI would warrant it. I don’t think I would refactor this on its own.

…. Unless I was working on that code as part of my current task. If I’m already working on that code, then yes, by all means, it’s appropriate. It’s appropriate as part of my current task and as an act of craftsmanship to leave the code cleaner than I found it.

If it was my project, would I do it?

Yes, without a doubt I would. But that’s because I see software that I write for myself as more of a vehicle of artistic expression than a financial investment.**

What do you think?

I’d be interested in hearing your thoughts.

Is this clean code?

Is this good design?

Should you refactor code that is this small?

When should you refactor something like this?

What are the guidelines as to when it’s worth it to refactor or not?

* I don’t remember if he said this in the book or if this was my own insight. I don’t’ even know if Uncle Bob would agree with that statement
** My inability to view my own software as a financial investment is also the reason I’ve never released anything awesome and made a ton of money.

Copyright © John MacIntyre 2010, All rights reserved