If you are an ALM practitioner, lead, or manager who is passionate about mastering your craft, the Microsoft Application Lifecycle Management (ALM) practitioner conference will help you gain deeper insight into your application lifecycle.

You will also discover and learn about industry best practices that address additional development challenges, and how Microsoft’s ALM Solutions enable and support those best practices. The ALM practitioner conference will provide you with insights on how to use Visual Studio 2010 Ultimate for making better design, implementation, and technology selection decisions.

Who Should Attend
TDM, IT Manager, Project Manager, Application Manager, Architect, Development Team Leader, Developer, Programmer, Test & Quality Manager

Date
21^st April 2011 (Thursday)

Time
9:00am to 4:30pm
(Registration and breakfast starts at 9am)

Venue
Auditorium, Level 29, Tower 2,
Petronas Twin Towers, KLCC

Register here.

Matt Harrison created a GIT Visual Cheat Sheet which is very useful for anyone using GIT. The actual source is located at github if you want to collaborate with him.

First up! Objective statements! Here’s one objective statement I’ve often read in various proposals that should not be followed.

To build an application that is intuitive and user-friendly.

How many of you who have read proposals ever seen these things in objectives? This is not the first time I’ve read something objectives that are similar to that effect.

So how do you write a proper objective then? Let’s first understand what an objective is, and the purpose of writing an objective statement.

An objective is your goal in this project or proposal. It can be to solve a current problem, or to create a tool to increase productivity or reduce cost, or anything along those lines. From Merriam Webster,

an objective is something toward which effort is directed : an aim, goal, or end of action.

So an objective statement is a statement about the end result. Some might argue that the statement mentioned above is a valid end result, building an application that is intuitive and user-friendly. If you can elaborate what kind of application it is, and what concrete measurement of intuitive and user-friendliness that will make your application a success, then that will be a better objective statement.

The purpose of the objective statement is to give you a summary of your problem, your success criteria and additional details that might support your claims. This becomes the “What” of your proposal. Here are some questions you might ask yourself while thinking of what you’re to write for your objective statement.

• What is your problem?
• What is your proposed solution?
• What is the aim of this solution?
• What are your success criteria?

A lot of your answers to these questions will overlap with each other, and hopefully you’ll start realizing that this is exactly your objective statement.

Here’s what an example of a better (not the best) objective statement.

To build a solution that will at the very least half the time taken to process the business accounting of the company.

Notice that there are several detailed points you can gather from this initial objective statement, which can be elaborated further in sections below the proposal. For example, now I know this project is about a business accounting problem. I also know that the measurement for success is time. Furthermore, I now understand what you’re trying to achieve and I can come up with a rough idea that can solve your problem specifically. Now, with this short statement I know more about this proposal than just the initial statement.

What do you think? Have you read any interesting proposals, or reports lately that is so ambiguous?

The biggest problem for several researchers and software engineers were  a lot of their hypothesis and conjectures are based on anecdotal and personal experience. These were seen to be true throughout several projects, but none were able to confirm or deny these without empirical data… Until now. This research was done by Nachi Nagappan, a senior researcher at Microsoft Research Redmond with the Empirical Software Engineering and Measurement Research Group (ESM). Working with Microsoft and their various (enormously huge number of) development teams, Nagappan was able to confirm several beliefs and even debunk and correct some of these hypothesis.

Some of the discoveries are shocking. Here’s a brief summary of the article:

Code coverage != software quality
You should spend more time testing complex code and more used code rather than having a high code coverage.

TDD does takes more time to release, but reduces post release maintenance cost
TDD actually produces better quality code, but takes 15% to 35% longer to complete. However, it reduces the cost after release significantly. (Realizing quality improvement through test driven development: results and experiences of four industrial teams)

More assertions and code verifications means fewer bugs
The density of assertions/contracts actually have a negative correlation to code defects. However, forcing the use of assertions will not work; building a culture will. This is a good thing because Code Contracts will be released in .NET Framework 4.0. (Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation)

Organizational metrics can predict software failure-proneness
The software system developed will usually resemble the organization building the system (Conway’s Law). This is really startling for me to find out various factors that organizational faces will actually affect the software’s quality and failure rate. It means that there is a direct correlation between organizational structure and the quality of software. The Influence of Organizational Structure on Software Quality: An Empirical Case Study

Distance does not matter
Most believe that distributed-development model has negative impact to software quality. But surprisingly enough, the impact is statistical negligible. In fact, organizational cohesiveness plays a more important role than distance or geographical location. (Does distributed development affect software quality? An empirical case study of Windows Vista)

LOC Counter can be used as a stand-alone client or as a Visual Studio 2005 add-in. The tool has the following features:

• It handles many different programming languages.
• It performs many different kinds of code counts.
• It handles comments, system-generated code, blank lines, and code churn.
• It connects to many different repositories.
• It provides an estimated defect density that is based on code churn.
• It is customizable. A user can change the kinds of objects that are counted during a counting task.
• It generates detailed reports. In addition, a user can export the report information to a Microsoft Office Excel® worksheet or to a Portable Document Format (PDF) file.
• It is fast. The tool can parse 10 million lines of code in less than one hour.

It uses a Defect Density Algorithm developed from Microsoft Research that uses the following version control history of a file to estimate the software defect density with an accuracy of 89 percent:

• The number of times that the selected files has been modified
• The time period in which the modifications have occurred
• The number of files that were actually modified

“Use of Relative Code Churn Measures to Predict System Defect Density” is a PDF document from Microsoft Research that describes this.

An IT Showcase web cast called How Microsoft IT Uses Visual Studio Team System 2005 to Measure Software Code Stability includes a discussion on how code changes, also known as code churn, may affect the code stability of a programming project.

Here’s a link of resources on MSF v3.0 and v4.0(still under beta).

MSF v3.0 Resources

MSF v4.0 Resources

I’m sure you guys will benefit more from the v4.0 resource. I’ve been trying to find stuff about v4.0 and this guy’s all I’ve got.

If anyone has more links, please feel free to post them under comments.

Analysing how a successful product/solution become successful is basically what I’ve been thinking about the last few days.

To have a successful product/solution, you’ll need to have a solid Vision for it. Vision to bring the product/solution far and wide. That means you’ll have to promote, advertise, and get people to listen to you.

Next. You need to have Passion to drive the product/solution. With passion, you can bring the product to higher reaches. With Passion, you can imagine the possibilities out there.

Next. Cooperation VS Competition. For me, I’d rather choose Cooperation. Cooperation yields almost the same result as Competition. You further your product/solution to become better, you strive to be better than your competitor. But Cooperation really brings about a whole new meaning to everything. Let me explain. Cooperating will give your users/clients a better and smoother ride along your product/solution.

Next. Don’t think of possibilities. Try out unknown possibilities and see how it can start something new. What I mean is, instead of pondering how we can work together, why don’t you think, we CAN work together, let’s discuss further how we can work together even more. During this discussion or whatever, you’ll start seeing MORE possibilities coming out than you thinking of it by yourself without the other party.

Next. Possibilities are the Key to Innovation. Don’t turn away any idea or possibility that might come into your mind. Keep it. Archive it. Store it for later use. Don’t let your mind be restricted by what you can do. Possibilities are limitless, it is you who set the limit.

Next. And I think it’s the most important point. User Experience. It’s really how your user/client enjoy using your product/solution and how easy it is to use it. Don’t restraint yourself to within the box. Think and innovate outside, and new possibilities on new ways you can create your user experience. I’m not talking about fanciful graphics and such. I’m talking about a totally new concept that’s natural, easy to pick up, and it’s just simply fun to do.

That’s about all I want to say. Summed up from my previous attempt to post. I’m going to copy this post just in case. I hope someone reads this and actually finds this useful.

Disclaimer. These are my own thoughts. And some discussion points I might like to bring up. I might be wrong.

There are alot of very wonderful and fantastic products, solutions, applications out there that alot of people do not know of. Why is that so? Because they lack the vision to promote, advertise and gain the public’s interest. Vision is very important and you have to get that straight down way before you get anything done. What do I want this product or solution to achieve? How am I going to achieve it? Not only that, which I’m going to go on to my next point here.

The next question you should ask yourself. Who and How can I cooperate with other people, companies, organisations, government? This will expand your horizons and discover new ways to improve your product/solution, and to find new ways to collaborate with your partners.

Yet another question you must ask yourself, do you have the drive to carry this out? You must foremost have the passion and the belief to carry all these out. You also need to have to come up with more plans, more ideas constantly to improve your product/solution. You will also need to think outside your box. For example, how would a totally unrelated subject/thing can help with my product/solution, or how can my product/solution help it/them/her/his?

It’s quite vague right now as it’s an idea that’s been swarming around my head. Because what I realise with Asians is that they are quite closed-minded, living in the box, and very competitive.

Another point I want to bring up also. Cooperation VS Competition. I see more sense in finding ways to cooperate than to compete. With cooperation, you co-exist and work together, helping each other in some ways or another, to improve each other’s solution/product. One must start the initiative to give first, and the other must also have the initiative to return in favour. In this aspect, each can grow in its own ways. Why compete, when you can cooperate to make something even better together? Or make the customer’s lives better by having our products/solution work together?

I’d like to bring up is to try out new ideas. Always try it. Don’t be afraid to carry it out. Don’t keep thinking of how you’re going to do it. You’ll have to solve it some day. JUST DO IT (NIKE Trademark).

Lastly, it’s to engage in new possibilities even when THERE AREN’T ANY POSSIBILITIES YET. It’s always good to sit down and discuss informally, and somewhere somehow something might come up, and we go back to the Cooperation point. Cooperate.

What I can say now is.

Possibilities are Limitless, It is Only YOU Setting The Limit.

Possibilities are the key to Innovation.

Always concentrate on the Solution, and not think about the problem.

Cheers. I hope to read this blog one day and realise what I think now is true and can apply everywhere.

Basically just drawing back on my previous blog, the idea of a User-Role-Centric Solution and Approach to the problem. Apparently it came to very good use as I subtlely veered her into that thinking, or maybe she already is thinking using that approach. Anyway, that’s really besides the point. But that approach actually made her able to come up with fantastic ideas for what she actually wants in her business or logic-wise. Note that we were actually talking quite non-technical here and more of what she wants to do, or what service she wants to provide the user. By thinking along that terms, she could come up with quite alot of business processes that she wants implemented, like her Invoice process, her Customer process, and so on.

From my point of view, this is actually quite a good way to draw out what your client actually wants for the solution, and how she wants it done. In my case, I would have never thought about enabling the invoice to be output into an excel file then making it available for printing, nor would I have known about how she wants herself to view the payment reports, nor would I have thought about how she wants to keep her customers by adding some added-value/services to her business, and so on. And she also has a better understanding and quite a clear understanding of how the solution works by us listing down the functionalities of what each type of person can do, without alot of the techy details. The most techy thing would be to describe the process of how the system works. As in, the user enters something, and the information is submitted into the system, and thus the system will inform the admin staff and send back a confirmation email to the user. Something along that lines. Very basic techy stuff. Nothing on like how it actually works.

Of course, the document must have these things available, in a bit more details, but that’s for another section. I actually have a Project Guidelines document which I’ll put up some time this week for you guys to look at. It’s quite interesting. But some things I might want to emphasize. Know your clients, and write your document accordingly. Safest way to do it, think in a business sense.

Till next time,

Cheerios.

Simply fantastic, lamenting on this crappy project. I’m going to charge her for the consultation! Furthermore, I wasn’t there during the meeting with the client to dig out information from her, and pick out everything out of her brains.

So anyway, here’s what I’ve been researching and doing for the past few days.

I finally realised when creating a solution, one MUST think about the person using the solution itself. Trying to explain this method to my friend(s), who are in on the same project as me, made me realise the importance of a User-Role-Centric Solution. While coming up with the User-Role profiles, I realised a lot of unseen features appear that’s not realised during the so-called “feature-creation” phase, which was done BEFORE creating this User-Role profile. Which was not supposed to be the case. *DEVELOPERS*

Anyway, creating a user-role profile is basically as simple as this. Determine who’s going to use the solution. For example, in my case, we came up with 4 user-roles. The “General Person”, the “Student”, the “Teacher”, the “Admin Staff”. From this, I think you’ll have a rough idea what the type of business this company I’m doing this project for are doing.

The question to ask when figuring out what user-roles there are is simply,

Who will use this solution?

So then, here are a few questions you’ll ask yourself about each user-role.

1) Who are the people who falls into this category?

2) What does the person expect to accomplish with this solution?

3) What does the person need to have to use this solution?

4) Is there any problems with the current solution that can be solved with our solution?

5) Is there any forms of information communication between another user-role? What are they?

6) What are the tasks that the person can do with this solution?

Basically these are the few questions that one would ask the client, but apparently there wasn’t a chance to do that for my case. Therefore I had to ask myself, and my other friends this question, and see what we can come up with.

In actual fact, we realised that when comparing with our original feature-list module-seperated format, which isn’t entirely non-valid and still useable in the proposal under the section “Scope of the Project” and “Solutions Concepts”, that we actually came up with more features that we didn’t think of in the feature-list, and removed quite a fair bit of features that weren’t needed and quite redundant. Which was good, in a sense that now the entire solution was based on “what the person is able to do with the solution”, instead of “what this solution can do for the person”. There are subtle differences, but when you actually think about it, your entire specification list simply changes and morphs into an almost totally different style. WHICH IS A GOOD THING(tm). So there and then, things start to change.

And I hope you guys also follow this way of thinking, instead of plunging down into feature-list.

Cheerios. Till next time.