>I was excited to see the announcement on Scott Gu’s blog about ASP.NET MVC v3. And I was even more excited to see that they are greatly enhancing the validation processing. Specifically, they’ve added a way to perform model level validations. And with the way it looks like it wraps the validations so that you don’t have to create Controller methods specific for you validations, this could be a huge improvement over what was introduced in v2.
Today, I read the Criminal Over-engineering entry on the coderoom blog (http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/).
I couldn’t agree more.
I believe we not only over-engineer the code, we over-engineer the solution too. We spend time adding features that aren’t needed or extending features with little bits that aren’t needed. All this extra code makes things bigger to code, bigger to test, and takes longer to deploy. I’m purposely ignoring the case where we don’t realize the feature is not needed; that’s a topic for a different blog post.
We also run into problems when these features are needed down the road. Why? Because we were usually not 100% right when we added the feature. If we got 90% of the feature correct, we need to change 10% of it. In other words, we are changing code instead of creating code. And, the code we are changing has never really been used. So we pay the price of adding the feature too early by having to change it to make it useful. And that means we are changing code which is a slower and more error prone exercise (not to mention, a whole lot less exciting too).
How much time would we have saved if we just left it out in the first place? We need to remember to code only the features needed today. Don’t code for tomorrow because we don’t know what tomorrow holds.
>So, according to the comments on the first answer in this StackOverflow post, it appears that there is nothing included to perform client-side validations of model level attributes. This seems like a much bigger oversight than the other things I’ve seen missing.
And, now, I don’t believe I can use the built-in validations. It’s just is too limited, has too many capabilities missing, and too many work-arounds feel so much like hacks that I’m going to go back to the jquery validation library.
>I’m working on a new (and simple) site in ASP.NET MVC v2 in v4 of the framework. And I’ve been trying to figure out the best way to do validations using the new capabilities. But after looking at everything, I’m thinking my old way is better.
In my previous MVC sites, I’ve put the validation logic in a service layer. For client-side validation, I used the JQuery Validation Library. This did require me to write the validation logic twice but, for the complex validations, I was able to reuse my service layer code because of the capabilities of the validation library.
I use view models in my UI. Using the definitions from Simon Ince’s Blog, I use a combination of variant 2 (Container View Model) and variant 3 (View Model and Mappers).
To get the validation messages from the service layer to the UI layer, I used the IValidationDictionary and ModelStateWrapper approach talked about in the this ASP.NET MVC tutorial.
And this approach worked well for me.
Now I’m moving into MVC v2 and am looking at the new validation capabilities with the data annotations library. I liked what I saw. Not having to duplicate the validation code in both the client and server was going to save lot’s of time.
As I started looking at implementing it, I got my first concern. All of the validations were being placed in the View Models, not on the domain models. When I found samples with the validations placed on the domain models, the domain models were being used as the view models. Sigh…
When I did some research, I discovered that the data annotation validations have MVC dependencies. So using them in a service layer seems like a bad idea. Another sigh…
But if I move away from the new validations framework and from using View Models with Mappers, that also makes it more difficult to use the templates because I’d lose the DisplayName attribute. And I find that attribute and the templates incredibly handy, helpful and time saving.
So, for now I’m thinking I will be coding validations twice and they will execute three times; once on the client, once on the server in my UI and once on the server in my service layer. Seems like a waste but I don’t see any other approach right now.
>It is time to expand on the Business Advocate project role I proposed earlier. To further explain what I’m thinking, I thought it best to go through a sample project. And before I do that, I need to go through a bit about what I like for a development process. While I like the concept of agile, I think the approach has some flaws for much business development. And, we all know well the flaws that waterfall has. So I use a hybrid approach though my approach is closer to agile than to waterfall.
The flaws I see in the agile approach is that the development team doesn’t understand the business to the extent required. And the time required from the business participants on the project can be too high; especially when the business person already has a full time position. And that’s the hole that I see the Business Advocate role filling.
So, let’s walk through a simple project. Let’s say it’s a relatively small project to build a new web application for a single business group. I would be the project manager. My initial estimate shows two developers will be needed and one business advocate.
To start, I’d assign a single, senior developer to the project and the business advocate. We’d meet with the business staff to get a good understanding of what they are looking for from the application. The developer would then start designing a prototype of the UI and the business advocate would start working on use cases. We’d have additional meetings with the business to fill whatever holes we had remaining from the first meeting.
And, both items would be available to the entire team. That is, the business advocate should be able to see and review the prototype at any time. And the developer should have the use cases available at all times.
As portions of the prototype are completed, we’d have some very thorough reviews of it internally. These will help insure that the use cases and the prototype are in sync. It will also help us identify questions and holes in our understanding of the business processes.
Once most of the questions are answered, we’d meet with the business and do a thorough review of the prototype. When we have some key portions of the work flow solidified, I’d assign the second developer to the project and we would start building.
During construction, we’d continue to refine the prototype and the use cases. We’d also push early builds out to a testing environment. And this is where the business advocate role starts to break away from the traditional business analyst role. As the early builds are made available for testing, the business advocate will start testing, looking for discrepancies from the use cases and big bugs (a big bug is one that prevents a portion of the application from being used like unable to save). Worth noting, because I’ve had questions about this, this testing is focused on the application functionality and the application meeting the needs of the business. This testing is not a replacement for nor does it cover the same things as unit testing and other types of developer testing; the developers are still responsible for that.
As more of the application completes, the business advocate role starts to move from mostly business analysis to mostly quality analysis. But it never moves 100% to quality analysis. If the testing effort is getting to be too big, I’d bring a tester on to the project, working under direction of the business advocate.
For larger projects, I’d have multiple business advocates on the project with one of them being designated as the “lead”.
The goal is to give us somebody on the project that understands and represents the business. The developers tend to get stuck in the technology. And this is a good thing; you need developers who understand the technologies and who live them. But you also need to have a thorough and deep understanding of the business for a project to really be successful.
>Why do sites keep adding those stupid security questions? They don’t add security. In fact, I believe security questions reduce the security of a site. And I’m not the only one who thinks that.
Yesterday, when I logged onto my ShareBuilder account, I was forced to pick 5 security questions and answers. It was a struggle. First, I had to work to figure out which five of the questions I could answer (sorry, but my father didn’t have a middle name). The second struggle was figuring out, of the questions I could answer, which questions could I remember the answers to?
So, for Sharebuilder now, if I forget my password, it forces me to remember five answers to five questions that I picked for a list they provided. I believe this will make it easier to hack my account. And since this account manges some of MY money, I’m not happy about that. I want to have to call them up and prove to them that I am me to get my password reset. Again, this is happening because I forgot my password. The hassle of making that call is my “punishment” for forgetting my password. On the other hand, if I am calling because somebody trying to hack my account suspended it, I’d be very happy I had to call since that might be the only way the hacking can be stopped.
ShareBuilder did add some other login security measures too. Now, they ask for your user id and then display a picture and a phrase to me when they request my password. That also means I enter my id and they validate it before I’m asked for my password. So, if I’m trying to hack accounts, I get immediate feedback on whether or not a user name I entered is valid. Is that really more secure? Or does it just feel more secure?
I really do believe these five questions make my ShareBuilder account less secure. Maybe it is time to move my money.
>After re-reading my post, I have one thing that I think is worth clarifying.
Even with the role of Business Advocate, the development team has the responsibility, or even the requirement, to talk to business staff. The purpose of the Business Advocate is not to centralize communication to the business, it is to insure that the development team considers a business-centric view of requests during all phases of development. In other words, make sure all bases are covered from a business perspective.
>One of the biggest issues facing any IT development team is how to make sure a project delivers. And one of the biggest obstacles to delivering is making sure you understand what the business group needs. Not what they asked for, not what they want, but what they need.
I believe there are two main problems that lead to the development team “missing the boat” on the project. First, most people have trouble articulating what they need. Instead, we talk about what we want. And getting what we want just makes us discover two things. We discover other things we want and we start to discover what we really needed. In other words, getting something that we wanted but didn’t need isn’t really viewed as a problem; it’s just part of the path of getting there.
Second, we, as techies, sometimes start to believe we fully understand the business and the problem even though our understanding is superficial at best. After all, how can a “simple” business process be as complex as building an application. We can’t see that many business processes are complex in many different ways. And when we start sounding like we understand things, the business staff likes this because it means less time spent explaining basic things to us and more time spent doing their job.
For me personally, one of the first things I had to learn was not to start designing a solution in my head after I’d heard 10 minutes (or less) of the problem. I found, through some painful projects, that I needed a much more thorough understanding otherwise it was easy to make some major and fundamental mistakes in the project. And that many times, the business staff didn’t know what I needed to learn because they would assume I understood the business much better than I really did.
As I’ve moved along in my career, I’ve experienced these two problems many times. Based upon what I know, I do many things differently now than in years past but I find these problems still happen. Especially since it’s a fight against nature. As developers, we want to concentrate on designing and building quality solutions; we don’t want to concentrate on learning how to do somebodies (non-IT) job so that we can help automate something.
And that’s where I came up with the idea for a Business Advocate. This is a person with the skill set required for a Business Analyst and a Quality Analyst. But the most important piece is that this person needs to be business centric, not technology centric.
The Business Advocates responsibilities are:
- Represent the business within the project. Stand-up and make sure that what is best for the business and the impact on the business is considered with every decision.
- Become intimately familiar with the business process(es) being automated. Gain a thorough understanding of who does what when. Gain an understanding of how critical the data is used.
- Identify how things pass between people and, more importantly, between groups.
- Help the project manager set the project scope and the relative priorities of the project requirements.
- Help work changes from the business perspective.
- Test the delivered system(s) and/or system changes focusing on the flow of the systems within the various business areas.
This role might sound a lot like the Business Analyst role. But I believe it is a bit different. First, the job is not to document the business process; the job is to understand the business process and to communicate that understanding to the rest of the project team. Second, the role is on the project from start to finish and the Business Advocate should be in charge of system testing from a business perspective (the step before UAT). Third, and most important, the Business Advocate should be viewed as the project owner. This person must be able to identify impacts on the business so that they can be addressed as early in the project as possible.
The real goal here it to make sure that the project team is spending 80% of it’s time working on the functionality that will be used 80% of the time.
In future posts, I’ll go into more detail on some aspects of this role.
>Today is the last day for six co-workers of mine, five from my IT team. I’m very sorry to see them go but business is what business is. I wish them all the best.
Last week, I deployed my first ASP.NET MVC application at work. Besides being our first ASP.NET MVC app, it is also the first app where we are testing for multiple browsers; IE7 (using IE8 emulation), IE8, Firefox and Chrome. And that has taught me a number of things to watch for between the browsers. The most recent item to catch me was a difference between IE and Firefox in handling “empty” nodes.
If you have a div named “node” and you have the opening and closing tags on separate lines, the jquery statement $(‘#node’).html() will return different results in different browsers. IE returns an empty string while Firefox and Chrome return the carriage return and any spaces that might be present. Since I was checking for an empty string to trigger some processing, it wasn’t working in anything but IE. Putting the open and close tags for the div next to each other fixed Firefox and Chrome.
I get why Firefox didn’t work. In fact, I would argue that Firefox & Chrome worked correctly and that IE should not have worked. My point is that just because you test and have the site working, it doesn’t mean the site works. If you want true cross-browser compatibility, all web interface tests have to be run against all browsers.
And that begets the real problem. How do you figure out what browsers and what versions to test? The list will get very big very quickly and that gets expensive. While unit tests will help with some of this, they do have limits when it gets to exercising the interface through multiple browsers unless you buy some very expensive tools. And that’s before even considering the problem of multiple versions of IE or Firefox running side-by-side.
It shouldn’t be this hard to build an “ajaxy” web site that is compatible with the major browsers.