Improve with Humility

There is only one way to become better and better at what you do, and that is to learn and improve every day.

Many people in different professions will tell you that they learn every day. Others will tell you that they don't need to learn anymore. Then there are those who say they learn and learn and know so much more than others. Sometimes it is a mix.

I watch. I see the people who are good and who are what I want to be more like. They all possess one thing that truly does allow them to learn. It is humility.

The more you learn, the more you realise that you know nothing. There is so much more to learn and if we do not realise that, we can not extend ourselves.

Just be open to the fact that you do not know it all and have so far to go. That is the best lesson.

How To Operate

There is a lot more to agile than a bunch of practices that people claim they have been doing for eternity and someone has just put a name to. There is a lot more to agile than doing a Scrum course over a week and getting a certificate. There is a lot more to agile than reading a few blogs, buying a bunch of books and going to a conference.

I don't believe in big A agile. There is no one methodology for software construction. There is no one method for anything in life. There are however a whole lot of practices that when used in combination with others and in the presence of a certain level of awareness of the required patterns and undesired anti-patterns, you can run a successful agile project that results in emergent quality and software that business wants.

The one thing that I am seeing over and over recently is people coming to me and saying that they are doing agile but it isn't working. They have people on the team who have done agile before. They have people on the team who are trained Scrum Masters. They have people on the team who have bought in and want to do agile. All of these good things and yet, they are failing.

I freely use the word failing without it feeling like that is a bad thing. It isn't. Failing is a way of learning and people who can step back and say that they tried something and it didn't work, are the kind of people who learn and improve.

To actually achieve a cohesive agile environment and a team that can find their peak and attain that, you need the glue that is an agile coach or iteration manager. Some people call it the scrum master but that term is so easily obtained these days that I do not think it holds much credibility.

No matter what you call that glue, they are the person who keeps the the team moving and finds the sweet spot that is the practices and level of rigour that will work for that team in the specific environment they are in.

The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong.

You can not just grab a bunch of practices and call that agile. The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong. Agile is not just a bunch of practices and terms and things to do. It is the whole process of constant reassessment, learning, rigour, retrospective analysis and self-organisation. It is something that you must experience and learn before you try it yourself and then help others.

I always refer back to the method that surgeons use to train other surgeons to do an operation.

The method is that you "see one, do one, teach one".

See One
Participate in an agile team as a team member. Seniority does not matter. You can be an expert at anything or nothing and that doesn't change the fact that you take part in the team and learn how practices work together and how to see patterns and anti-patterns that let you choose what shapes the team.

Do One
This time, you organise the agile team and help propel it. Remove blockers; Suggest practices and tools for the context and team; Measure the quantifiable parts and communicate them; and be the glue. This can be done with the support and supervision of a person who knows how to teach or coach. They can back you up.

Teach One
Be the teacher and coach others to be members of an agile team. Let them learn about their environment and adapt to a changing environment. Your job is to enable and act as lubricant for others who are learning.



If you understand that this is the process that must happen before people are fully enabled to work in an agile way then you will understand why teams without this but with the best intentions still fail.

It also explains why having an agile expert on the team can be a peaceful process that makes the whole thing feel easy. When they leave, it sometimes feels a little unstable. They shouldn't hold all the information back or be in control. A coach should enable you and let you find your way, with a safety net.

I had a project manager say to me recently "Damana, the reason why what you do looks easy, is because it is". I smiled kindly and sadly watched him eat his words later when he took over and ran the project on to rocks.

The reason an agile coach makes it look easy is because they saw one and then did one and taught one, several times.

Too General

In the same way that we normalise and denormalise data in a relational database, we have to generalise and specify domain model design in the application.

Developers have a tendency to want to generalise things to an extreme but this often results in losing meaning. Whenever you see something called Object or Entity then it’s gone too far.

A co-worker and I had a discussion about creating a class called LookupItem to represent all reference data. There is no domain meaning in the term LookupItem. It is not a word that our business users would use so it isn’t a word we should use. If you find that commonality then let all your domain model classes inherit from a base class but still have their own class with a meaningful domain object name.

You will end up with lots of small classes but you retained a lot of meaning. Someone who walks in after you and goes to maintain the system will not have to read through the code and see what your named variables to see what a class is used for. It is in the class name.

There is also extensibility inbuilt in to this kind of structure. Often extensibility is required when there is an exception to a rule. Always build your generalisation so they can cope with exceptions to the rules.

Generalise but don’t lose meaning.

RIP Steve Jobs

He lived a life that changed the world so much that I can not imagine how it would be without him.

My first IT job was in tech support at an Apple Centre.
My first personal computer was an Apple IIC.
My first smartphone was an iPhone.
My first laptop was a Mac.

At thirteen years old, I had a huge crush on Steve Jobs and told my parents that I was going to marry him. I still held out hopes until now.

He made a difference. He made me Think Different.

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.

At least we have one

I posted a link to this photo on Twitter this morning. One of the first responses I got was making fun of the fact that the first incarnation of our continuous integration server is on an old laptop. They used the word "quaint".

When I asked the rude person what their server ran on, they didn't even have one. This leaves me thinking that I'd rather have a caravan in the hills than a mansion in the slums.

Excuses about not having the money or permission or a restricted network is not a good enough excuse to not have a server that is building your code, running your tests and preparing automated deployments. Get out there and start building rigour in to your development practices and hopefully finding the emergent quality that accompanies it.

If you don't happen to have one or possess the will to make it happen then shut up because you just look lazy and rude. Lazy on its own is bad enough.

Tell me a story

The story wall went up at work today. We are the not just the only project running agile, we are the only project with much of a plan at all. Working in this small city has frustrated me to no end. People here talk of things they do, without doing them. They say they are aiming for this and that and then all the aiming that is done is in the talking of it.

This project is different. We are walking the walk. The team likes the idea of agile. They are willing to try it. They are willing to find the flavour that suits them and the project.

Our goals are simple. Short deadline. Fixed budget. Huge scope.


The Story Behind It


When I joined, we had done a lot of requirements gathering and there were big solid specs being written. There were documents defining process and documents defining documents. Today, I uploaded my last documentation of the project up to the Sharepoint portal and turned my head to the story wall.

Over the last few weeks, we have been breaking down tasks. I walked them through how to do that breakdown and then how to guesstimate to the best of our knowledge at the time. We recorded effort in days and the whole team agreed on complexity and volatility. We came up with numbers and costs and best of all, a shared understanding of what we were building.

The first visible way this has been communicated is to produce a story wall from our master story list. The master story list is a list of the discrete tasks that describe functions and sub-functions in the required system. Developers will undertake one task at a time, after business analysts have described it and they have both agreed on acceptance criteria. That acceptance criteria will guide our test driven approach to development and eventuate in automated tests and the QA and then user acceptance tests for each story/task/story.




Reading the Cards


Right now, the wall is made up of different coloured cards...

• White - Story cards made up of an Id, a task description, estimation of effort, complexity and volatility ratings and space for acceptance criteria and notes;
• Green - Descriptive cards that give headings for the stages that a story goes through and other important sections that a card can belong to;
• Pink - Defects which are played like stories and require Ids, estimations and all the things a story needs. They will come out of testing stages after they have been accepted for QA and moved out of In Dev, which are two of our story stages;
• Yellow - Tech cards for technical tasks that are related to stories and need to be explicitly detailed. I personally hate tech cards but for iteration 0, they are valid. If I see too many, heads will roll;
• Blue - We haven't associated them with anything yet. We are calling them Terry cards. Terry is our project manager. We didn't want him to feel left out since he's on leave and I'm sure he'll have a good suggestion for their use. Possibly things Damana is not allowed to blog about;
• Sticky notes of random colours - These denote blockers and notes relevant to a story. They are stuck on the story card.

The Life of a Card

There are columns that represent the stages a story, defect or technical card can move through. At each stage, there is an owner of that card. A card can not be in play and not have an owner. For a card to move from one stage to another, there must be a discussion between at least two members of the team and one must be the owner handing over to a new owner.

Our stages for this project are...

• Backlog - Where all stories sit until they are played in an iteration. Everything starts here. It's a little like Munchkin Land;
• In Analysis - All stories that are being played in a current iteration will start here on the first day of the iteration, after the IKO (Iteration Kick Off) meeting. At this point they belong to the business analysts and will only move once they are ready for development. This is usually a decision made by two analysts or an iteration manager and an analyst. Remember that the analysis on a story does not need to be 100% complete. A story card is an opportunity for a conversation. It is not a spec;
• Ready for Dev - Now the story is available for a developer to pick up once they have the bandwidth to start and complete it. At this point, the decision to move it to the next stage is made by a business analyst and a developer. If you live in a perfect world then hopefully a QA is around to help establish acceptance criteria with those two;
• In Dev - The acceptance criteria is set, the estimation validated loosely by the dev and the shared understanding of what is required completed enough to start the task having occurred between analysts and developers (yes, a pair). Development starts. This does not mean running away and working in solitude. Nope. There will be more questions for the analyst and the business and other members of the team. Nothing happens in isolation on this agile team. Transparency and Conversation are paramount;
• Ready for QA - As it sounds, this is when the developer(s) think that the story has been fully implemented and can be taken for system testing. In our case, this means acceptance criteria are met and there are automated tests at all levels ready and running in continuous integration. Full integration has been made with the project code base and all compliance with agreed coding and developer standards are adhered too (well, mostly). At this point, the developer and the QA are often having a chat. Anything that needs clearing up is brought to the business analyst. Beware of slippery developers who bargain at this point. Don't pay the ferryman until he gets you to the other side. I have turned around to many QAs and said "well, you agreed I met the criteria so move that to another story";
• In QA - The story is in system test and belongs to the QA. I won't tell you how to do good QA because I'm a developer and there are better people out there to tell you such important things;
• Ready for UAT - The story has met acceptance criteria and passed system testing. It is ready to show to the client;
• In UAT - Users are testing it. The team deals with defects and waits for users to accept the implemented functionality. Business analysts, QAs and iteration managers are dealing with outcomes at this stage. We wait;
• Signed-Off - The users have tested it and the business has signed off the story as complete. We celebrate. For some that is chocolate. For others champagne.

Pwn It

Every member of the team has chosen themselves an avatar that will represent them on the wall. Some chose their photos. Some chose creatures or characters that represent them. This is how they will be seen and how they will own their current task. These are about the size of a business card. Our only rule is "no nakedness".


The Outcome

Every process is different. Every wall is different. The purpose is the same. Communicate and provide visibility to the whole team and stakeholders.

Tomorrow, we will start holding our stand ups around the story wall. That is when the team will see the true value of both the visual story wall and stand ups. It will become the most important part of our project.

It will grow and change so that it gives meaning to our particular project. Come back once in a while and check how we are progressing.

Configure your embedded YouTube video

While embedding a music video on my blog, I found that YouTube now lets you configure the dimensions of the video and a few other useful options. This makes a huge difference when you have size constraints on the host site. Blogger is a great example of embedded videos exceeding template limits and just messing the whole look up.

Again, YouTube gives me another reason to use their service for easy video sharing and embedding. It is little things like this that appeal to bloggers. Thank you.

Process

Not all processes are bad. It is process for process-sake that is painful and unhelpful.

iPassed2

For all the Apple fanboys, who will love products of Jobs until they die and long after.

Created by Peter Walker of Imagineer.

Go Dig A Ditch

People keep on telling me that I shouldn't get upset about others in my industry who simply couldn't care less what they produce.

Apparently, people have different priorities.

The thing with priorities is that you are choosing to order the importance of several things. That does not automatically imply that there is only one thing that is important to you. People with children who work a day as a software engineer and do a good job, do not implicitly hate or undervalue their children. Those of us without children don't just have lives full of work and nothing else.

In fact, people with diverse interests and hobbies are often very good at their jobs because their lives are more balanced.

You can have multiple things that are important. That is the whole point of context. When you switch contexts, the focus changes. There is nothing lost in other contexts. It is not as though you love the other less. You do not have to choose.

There is one guy in Darwin who sparked this rant. He goes to work. He goes home. He doesn't put in any extra effort. He always asks why he has to do something out of his usual routine. He doesn't see the point of collaboration, information sharing, reuse of anything, or exerting any more effort than it takes to not fire him.

Working with him was difficult because he would resist the whole way. It was passive resistance. I always came across as a French marine dragging a Green Peace supporter from a boat. It makes those of us who care look like zealots, when all we want is for people to make the effort they are paid for.

What we do is an important job. We are professionals. We get paid well .We have a responsibility to give a good service.

If you don't want to contribute then you should go dig ditches. Get the hell out of programming. You are lowering the standard.

ASP.NET Naming Containers

You have to understand that ASP.NET naming containers exist and what they change about a page. This affects client side and server side code and often kicks my a** when I forget that I am in one.

A naming container is a marker interface (INamingContainer), meaning that it does not implicitly enforce the hierarchy of controls under it but does create a naming scope for all contained controls.

Any controls that exist inside the naming container have their Ids altered at runtime with a prefix to ensure they are unique and belong to the context of the parent container. When you see a control with a name like TextBox1 change to ct100_xxxxxx then you know that it's in a naming container and has had a naming adjustment. This can make client side scripting a pain but there are many hints around on the web to help you cope with that.

The naming containers you will be most familiar with are master pages, content place holders and data bound controls like GridView.

My latest bottom kicking came when I was using fluent validators that wanted my validation specification to sit in the same naming comtainer as the controls it was validating. I chucked it at the top of the user control and the validation specification wasn't found. Not finding it as a sibling to the controls meant that validation just wouldn't happen. There was no error.

This makes sense when you are implementing server side code that looks up to a certain level in the hierachy to find an optional element on the page.

The thing is to know what your naming containers are and where you should place things.

Design for the Lowest Common Denominator

Everything is a balancing act between perfection and pragmatism.

What I do not believe is that you are supposed to drop standards to the point where you correct the mistakes of users. Yes, suggest improvements or give warnings or give options to clean up but do not just assume and make the change.

I'm using an ORM called llblgen. It is the standard where I work. I'm not a massive fan but I'm currently more for consistency than purity so it will do for now.

One thing that llblgen insists on doing is assuming a table name ending in with an 's' is a plural. It then removes the trailing 's' when generating the equivalent data model class.

For example, my 'SomethingStatus' table will be represented by an equivalent model named 'SomethingStatu'. The developer has responded to my tweets of disdain and said that from his point of view, he can't assume that people will model their databases in a way that obeys conventions for not using plurals.

This bothers me because it makes me question the point at which we will go to cater for developers or users that may be doing something "wrong". Microsoft development environments and technology stack restrictions often have this in mind. Stop bad developers being sloppy by locking down the environment and denying options because bad choices cause bad code.

I disagree. I think bad developers write bad code. You shouldn't have to correct them. You don't need to baby your users. If you are going to cater for anyone then cater for the average user.

If the assumption is that the average user has a low statu then I'm simply saddened.

Uninstall an Instance of SQL Server

If you are anything like me and you regularly forget the SA password for a SQL Server instance and then delete your own Windows user from the server then you will need to install a new instance.

Then you have two... or four instances, in my case. Don't ask.

Here is how you uninstall a specific instance since you are locked out and can't use it anymore. There are other good reasons that may bring this about but mine is far too common, so do this...

1. Go to Control Panels > Programs > Uninstall a program. This is also known as Add or Remove Programs;
2. Find the type of server you are uninstalling. In my case it is Microsoft SQL Server 2008 R2 (64-bit). Right-click and choose Uninstall/Change;
3. At this point, you may be asked to locate your installer program. That is the program you used to install it in the first place. Locate that. You will be presented with several options. Choose Remove;
4. Select the Instance you want to remove and follow the instructions to uninstall it.

You may want to write down that SA password for the new instance somewhere.