A Process for creating an MVC View of Partial View

Developers were adding New MVC Views to the web application project manually and that is an anti-pattern. We want to make sure that Controllers own Actions that own Views that are bound to strongly typed view models.

This is where this process comes from. ReSharper is required in this process.

A Thousand Words

When I find myself explaining a concept over and over again to the same or different members of my team, it is a signal that I need to draw a picture.

Often, I draw the picture for a few people before it clicks that I should put it on an A3 piece of paper and stick it on a wall or take a photo and send it around in an email.

In the case above, I was explaining mapping between model classes coming out of different layers of the application. All sorts of words were being used to refer to these objects and it was getting confusing.

This image has given us an explanation of where mapping classes exist; what models coming out of different layers are called; namespaces to be used when creating or referring to mappers and models; and a common language for technical discussion.

To write that in a document would be long and cumbersome.

When you aren't explaining it in code, explain it in pictures.

The Check-In Procedure for my team

This is an email I sent out to my team yesterday. What do you do before checking in code?

---

Hello rose petals,

I’ve put a stuff to do before you check-in procedure on the wall.

In case you do not look on the wall (even though you should try to each day), here is a summary of the summary…

1. Merge all your code locally by doing a Get Latest Version from TFS;

a. Resolve any conflicts by trusting what is on the server and moving your changes in to that code. If anything can’t auto merge or conflicts seriously with your code then find the dev who wrote it and have a chat about how to make it work. This is a life skill, grasshopper.

2. Run all the tests (not just your own) and make sure they are all still working. This process is regression testing and stops you introducing a bug that causes something else with a dependency to fail;

a. Functional, Integration and Unit tests should be run.

b. If you do break something and fix it then write a test around that area because it seems fragile and may happen to someone else. Tests are security blankets. I’ve always wanted a teddy bear called CI.

3. Ensure all compiler errors and warnings are fixed;

a. Warnings exist for a reason. They speak of great tales of possible performance errors and sagas of linking and runtime optimisation. They are not there for the entertainment of the devs who wrote Visual Studio or .NET, they are for us.

b. Use ReSharper to make the little green box at the right top of each code file green. Ask me what I mean by this if you aren’t sure.

c. Use fxcop to ensure static analysis rules are complied with. Yes, even the ones you don’t love but we have decided are standard for our project.

d. Retro Steve will cry if you check in without these warnings resolved. I will look disappointed. Puppies will die.

4. Check it in!
5. Show another developer your code for review and check out the code and run the tests on their machine;

a. This means you have someone else to blame share your future bugs with.

6. Be happy. You are a good human being.

This is why I should not take pseudoephedrine during work hours. Damn cold or hayfever or something.

The Knowledge Gap

Anyone who has had a glass of wine with me at the end of a long work day will have listened to me complain about the technical level of the people playing IT professionals.

Yes, "IT Professional" is a broad group of people now with lots of different specialised roles. This happens as a profession grows and as it grows, we start to see the holes in the entry level criteria that are leaving us with inexperienced professionals producing what can only be inexperienced code.

That's fine, right? You throw in a senior engineer to vet what they produce before it hits source control or worst case production. You give them bench or training allowances to go off and take courses, read books and teach themselves.

This is where it falls down. Teaching yourself something is a highly developed skill. Universities do not teach higher grads exactly how to develop a case management system with a specific tech stack with the exact restrictions and requirements as they will need for a specific client. No, they teach concepts and they teach you how to learn on your own and do it fast.

The ability to understand complex software concepts improves with time and experience. So does the ability to pick up a concept and hone it based on reading, watching talks and trying it out. Both of these skills come quickly to good developers. There are many non-degree qualified engineers that I have worked with who are brilliant. The one thing they do better than a lot of others is to pick up a concept and actually learn and understand it.

Going and reading about something and implementing it does not mean that you have done it properly. The eternal error I see in software engineering is that a developer learns how to build one thing and as they change technologies or languages, they build exactly the same thing.

They miss the intricacies, beauty and benefits of the language they are using. They even miss the point completely when they solve different problem domains with the same solution. It won't work. Everything I have built is slightly different than everything else I have ever built. There are shared patterns and solutions but they are unique and require bespoke solutions. I'm not saying they need the wheel invented each time. In fact, I'm the first to argue that unless you are in R&D or seriously cutting edge, then almost everything you need is already done or the pieces exist to allow you to solve the problem quickly.

Recently, I'm seeing developers walk off and read about something and try it out. They then come back and tell me they understand it and have solved all the problems that us senior devs have been thinking through for the last few days. At first, I was super pleased. Yay, they have saved me time and given us a new perspective then I hear the explanation or solution and it's not quite right.

The concept has been explored and the idea implemented. It uses the right terms but in the wrong ways. It sets out the process or structure but only in a superficial way. It is so specific that it can not be generalised because instead of giving a solution, it has gotten to a solution without the understanding of the problem or the solution.

Now, I'm left trying to work out what was missed and I'm coming up with two things that are shining above everything. There is a lack of understanding of the problem being solved and a massive misunderstanding of the underlying pattern or technology being used to solve it.

There is no lack of enthusiasm or effort expressed. It is instead a knowledge gap.

At this point, I have to stop and start at the beginning again explaining what we are doing, what we want to do and how we might go about coming to a way of solving it. I don't want to say they wasted their time but maybe there is education in learning that throwing it away and starting again is also a skill. The big problem is that I can explain it to a person but without the foundation then I can't understand it for them.

There are basic concepts that you should have when you walk in to a software job. Liking tinkering with your PC at home is not enough. You need to understand computer science concepts. We need to have a common language. I have zero issue to helping a juniour understand a concept but I can't be explaining things to them that they should have found out about in first year computer science.

As our industry matures, we must start accepting a certain entry level of competency. Enthusiasm and over-confidence is not going to compensate for not understanding polymorphism or the difference between a has-a or is-a relationship between classes.

I can teach that too you but I shouldn't have to.

My head is in the cloud

At my current location, each work day feels like stepping back in time in to a world where we fought for hardware to run the simplest things on. In Sydney, Canberra and Melbourne I could walk up to my IT guys and ask for this server for that job as I built my application. With dedicated data centres employing high end funky virtualisation, it would take hours or days worst case.

That is what I expect at least from the IT guys in the company I work for. Especially the big guys.

Unfortunately, in Darwin I am more likely to get what I want in a small office where I can run down to Harvey Norman and grab a machine and combine that with a good MSDN subscription. There is at least a possibility of me achieving isolation of environments, added servers and more space to play in that world.

Where I am now, we are too big to allow anything to run on our network without the restricted, locked down and encumbered SOE. We are also too unimportant to get a place in our private or public clouds. It's a lose-lose situation.

There are many reasons for businesses to go in to the cloud but it is not being sold as a place for software development services to take place. At least, it is not being sold that way to the mid-sized companies who really truly need it. They can benefit the most without the hassle, price and justifications that they are making now. Sys admins will still be in jobs but they won't be racking machines in meatspace.

The scalability and elasticity of the cloud is perfect for software development. Even the benefits of highly automated behaviour that will allow the management and clustering that we need without knowing what we need ahead of time.

Right now, I have to predict all my development needs and then beg "please sir, can I have some more" if for some reason I missed out on something. We have to adapt and cater for the unpredictable. In the same way that we talk of agile software, we need adaptable and agile infrastructure for producing software applications.

Those of us inside mid-sized organisations can sell the business value or suggest cloudy solutions until the cows come home but until the big providers like Amazon, Microsoft and Google start selling the software services then the big wigs won't really listen.

Hurry up already. I am sick of begging for servers.

Quality Assurance is a myth

Anyone who stands before you and tells you that they can assure quality in your application is talking rubbish.

There is no way to achieve assured quality. Quality can not be assured. I was taught this by some of the best QAs in the world. Let me explain to you what they explained to me.

The first thing that people seem to tout when they instigate continuous integration, X driven development or employ a QA is that they can now assure quality in everything they build.

Let me break the truth to you. There is absolutely no way of ASSURING quality in anything you build. Ask the guy who forgot to used the metric system and caused the Mars Orbiter to crash. NASA has the strictest of all environments to assure there are no mistakes.

The way I build software is to ensure rigour. To ensure that the practices that are used in managing a team, gathering and expressing requirements, writing the code and meeting the acceptance criteria are so engrained and bought in to that quality emerges.

People speak of methodologies. I speak of rigour.
People speak of best practices. I speak of rigour.
People speak of theory and practice. I speak of rigour.

There is a distance between the project management focused Scrum and developer focused XP. Companies can sell you their flavour of this and that but the truth is that you need to find the way that works best for you.

Find that way. Find the practices and methods that bring the benefits to you and your company. Hold on to them and repeat them. Do them over and over in small sprints or iterations or bursts or waves. I don't care what you call them. Just find them and correct them as you travel. Allow yourself to be wrong and fail as long as you learn from it.

It's not rocket surgery. Consultants try to tell you it is. It's not. Good software can be built in a way that allows quality to emerge. It is a craft and as such must be built by craftsman.

Companies try to undervalue the craftsman and sell their solution. The reason is because they know that software is a true craft and it must be taught by a master craftsman to a novice. Great software takes great individuals. It takes guidance and a honing of skills. It does not come from big M methodologies or style focused companies.

If you want to build good quality software then find a very good craftsman and let them build a team. Let them teach the team. Let them guide your progress. Close your eyes and take a leap of faith. You will be rewarded.

Quality comes from great team work. Great practices. Rigour. Craft. Buy in. Pride in product.

This is why it seems random. You are looking for the wrong patterns. Find a great lead who enables and cares and you will build bliss.