I have recently started playing around with linq syntax. It can produce some very beautiful syntax. Of course, it can probably also produce equally ugly ones.

I recently played around and built this one lines for retrieving the values for all of the readable properties in a object.

var values = (from prop in value.GetType().GetProperties()

where prop.CanRead

select new { Name = prop.Name, Value = prop.GetValue(value, null) });

This allows us a single statement to retrieve name / value list for all of the properties in an object.

This allows us to skip having to write the foreach loop and the conditional on the CanRead property. Additional conditionals could be replaced by adding more elements to the where clause.

I believe that these format is much easier to follow and understand. It also puts the focus of the code back to where it belongs, which usually is not reflection or identifying which elements in a collection to work with, but the actual work being done to the identifed elements from the collection.

What are your thoughts?

As we have pieced together the components of a web application we have explored how best to structure the markup, and how to pull business logic out of the UI by following the Model View Presenter Pattern. Now let's turn our attention to the Model as we pull all the pieces together and explore what a well behaved model might look like. 

The Model will be the piece that handles storing and retrieving our data. Just as we did with the markup and view, we want to provide a separation of concerns and try to shield ourselves from the more volatile aspects of our design.

Model, Model, Everywhere

Software development is full of models. We have domain models, physical data models, logical models, process models, etc. Sometimes the terminology can be confusing and the differences subtle and often abused. Let's try to clear some up some of the confusion.

A domain model is an informal way of thinking about data and how the data components relate to each other independent of any technology or formal structure. We think about relations but not constraints. We think about associations but not inheritance, and we think very loosely about data types, if at all. The domain model is the ultimate in fluid informal discussion.

A physical data model is the implementation of a domain model in a specific database. While the domain model is independent of any technology, the physical data model is very dependent on a particular database platform. It may even be dependent on a particular version of the selected database. In some cases, it may even be dependent on a particular disk configuration with a specific operating system.

The domain model is free from any technical constraints leaving many implementation details to be resolved in the physical data model. For example, entity names in the domain model can be anything, while entity names in the physical data model are limited to what the RDMS can handle. The domain does not have to worry about performance or maintenance. Most of the details in the physical model are consumed by these concerns.

Here we will focus most of our discussion on the development model. The relationship between the domain model and the development model is similar to the relationship between the domain and physical data models - similar but not exact.

The development model is the implementation of a domain model in code.

Ultimately, the development model will be expected to store and retrieve data from the physical data model. The development model also has restrictions and extensions that the physical data model never has to deal with. The development model can benefit from inheritance and polymorphism, and encapsulation, but also has to deal with the often self-contradictory business logic.

The development model is also the last line of defense protecting the data in the database. Validations in your code protect the data better than any constraint, firewall, or the best security measures that a security administrator can put in place.

Read More ...

Many people have seen and appreciate the elegance and practicality of agile methodologies.   Sadly there is still not widespread adoption.   There is still push back from many directions and from many different sources.  

• Some people don't understand how it is supposed to work.
• Some people don't believe that it could possibly work.
• Some people mistakenly believe that it is just code for a lazy project team trying to wiggle out of structure
• Some people mistakenly believe that it can work only with a very small highly trained team
• Some people are afraid of the control that they feel they will be losing.

I have seen some people try to merge agile and water fall hoping to achieve the best of both worlds.   Unfortunately, the reality is that you end up with the worst of both worlds.   And they both can get pretty bad.

Another Sad Reality

Some people in an effort to get buy in for following an Agile Methodology have attempted to merge these two practices.   Sometimes this may stem from trying to assuage individual fears that they are not losing relevance.   Sometimes it may be to meet contractual obligations or to fulfill regulatory requirements.   Sometimes may not know better.

These two approaches to software development cannot coexist on the same project.

Let's review the main tenants of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Meanwhile the main tenants of the Waterfall Approach could be summarized as:

• Processes and procedures over individuals
• Comprehensive documentation proves that the software works
• Well defined contracts and negotiations protects the customer relationship
• If the plan is made right, there should be no change

Merging these two approaches will always end badly.

It is a horrible sight to watch a project fail. There are few things as bad. Watching a project fail regardless of the reason is almost like sitting in a room with a "Dementor" from Harry Potter. It will literally suck all of the life and joy out of the room.

Nearly every project that I have seen fail has failed because of political challenges or management challenges. Sometimes there are technical challenges that bring a project to its knees, but usually projects fail for less technical reasons.

Here a few observations about projects failing for political reasons.

• Both the client and the consultants have to be committed to seeing the project succeed. Put simply, you cannot solve a problem when the primary stake holders do not truly want it solved. This could come from a consultant being more interested in extended the engagement. It could come from a client being afraid of what will happen to them once the problem is solved. It could come from disenfranchised stake holders. Sometimes a project is beset on all sides. When you find yourself working on a project that has this kind of threat, do all that you can to constrain the disruptive influences of the bad apples. If their influence cannot be constrained, you truly have no choice but to move on to a new project.
• Tough choices have to be made to make a project successful. These choices will affect everyone involved in the project. These choices may involve users not getting a change request through that they want. Developers may not get to use the tools that they want. Everyone may have to put in more hours that they originally planned. Steps may be skipped. Compromises will be made, but if everyone stays committed to the end goal, you can still be successful. If individuals start feeling disgruntled or resentful of the compromises reached, the project can easily be derailed. When everyone is not working towards a common goal, it is like driving with one foot on the break and one foot on the accelerator. Not only will you not get to where you are planning, you will also damage the car and possibly the passengers as well.  
• It is important to always keep the end result in mind. Regardless of the development methodology being followed, the end goal is not comprehensive documentation. In all cases, it is working software. Comprehensive documentation is nice but useless if the software doesn't work.  
• You can never get so distracted by the next goal that you fail to meet the current goal. Most projects are ultimately marathons. This means that the pace must be sustainable. Regardless of the temptations, you cannot burn the team alive. Processes will fail. Technology will get outdated. Requirements will change, but your people will adapt and learn and grow. If everyone on the team from the most senior analyst to the most junior recruit trusts and respects each other, there is no challenge that they cannot overcome. When everyone involved faces challenges with the attitude "This is my project and I will not let it fail" "You are my teammate and I will not let you fail", you will in fact not fail. When you find a team that embraces this attitude, protect it at all cost.

Edward Yourdon wrote a book called Death March. In it, he included a graph for categorizing Death March project types based on the Happiness of the Team and the Chances of Success.

Chances are we have all worked on Death March projects. We will all most likely work on more Death March projects in the future. To a certain extent, they seem to be inevitable, but they should never be suicide or ugly. Ideally, they can all be "Mission Impossible" where everyone works hard, has fun, and knows that there is good chance that they will succeed.

If you are ever lucky enough to work on such a project, you will know that sense of pride that comes from the eventual success. You will recognize a profound bond with the team that you worked with. Chances are it will change your life or at least your outlook on life.

If you have not already read this book, get a copy and study it closely. It will help you survive and make the most out of your next Death March project.

I have been interested in functional programming since college. I played around a little with LISP back then, but I have not had an opportunity since then. Now that F# ships standard with VS 2010, I figured now is my chance.

So, I was reading up on it a little over the weekend when I came across a very interesting topic. F# includes a concept called "Automatic Generalization". As I understand it, the compiler will look at your method and analyze how you are using parameters. It will automatically switch to a generic parameter if it is possible based on your usage. Wow!

I am looking forward to playing with this. I have long been an advocate of using the most generic types possible especially when developing library classes. Use the highest level base class that you can get away with. Use an interface instead of a specific implementation. I don't advocate passing object around, but you get the idea.

Tools like resharper, fxCop, and most static code analysis tools provide guidance to help you identify when a more generalized type is possible, but this is the first time I have heard about the compiler taking matters into its own hands.

I like the sound of this. We'll see if it is a good idea or not.

What are your thoughts? Am I missing the mark on what Automatic Generalization does in F#? How would this work in C#? Do you see any problems with this?