Best of Old Blog

Good design is not an accident...

Madhawa Karunaratne — Sun, 25 Jun 2006 13:40:00 GMT

This is a nice post from Nick Malic although it's not talking abt peoples who are maturing in to architect.
http://blogs.msdn.com/nickmalik/archive/2006/03/10/549189.aspx

I couldnt help just posting the url only. So here is the artcle itself. :)

One potential often missed in a large IT organization is the potential for us to lift up another person's design skills. Perhaps we are competitive, or perhaps sometimes, we figure that "it's all the same anyway," but a lot of IT project designers don't want to show their designs to other folks.

But if I never look at your designs, how will I improve? And if you never allow me to offer feedback to your design, how will you improve?

Artists get this right. So do craftsmen. Emphasis is placed on being recognized. For that to happen, your design has to be in an understandable media, and has to be on display. Not on a shelf where someone COULD go look at it if they want to, but on DISPLAY, where other folks have no choice but to see it.

And then, not just to see it, but to compare, critique, appreciate, and exemplify. There need to be design competitions, and the winning of a design competition should mean something tangible, like a greater chance of moving up or a bigger bonus or even public praise and acclaim.
Smaller companies that don't have so many IT workers may not be able to participate, but they should be able to partake of the results. Acclaim should extend beyond the walls.
We do have "showcase" apps in Microsoft IT, but only where it will sell a product or illustrate how to solve a problem with MS tools. Not so much as a mandatory mechanism to bring out the best in IT design.

Otherwise, good design happens when a good designer accidentally has a good day or is accidentally assigned to a project that they would be good at. I mean "accidentally" because something is either an expression of the system that produces it, or it is an accident of the combination of skilled people and a project that suits them.

Making good design a part of the system, reinforcing it, rewarding it, and heaping public praise and acclaim on those who practice it will go a long way towards making excellence in design a normal part of life.

When should not Design Patterns be used?

Madhawa Karunaratne — Sun, 25 Jun 2006 13:37:00 GMT

1. When the application being built today will not change, the code accurately captures all requirements, and there are no planned enhancements or features. The application you are building will be the first and last release.

2. Your application’s code requirements are unique. No software engineer has ever built anything like it. The program does not deal with any of these routing issues like object creation and event notification.

3. There is plenty of time to prototype all of your new design ideas. Alternatively, you are so confident of your ideas that they do not require any proof-of-concept testing.

4. Everyone on your team has worked together for twenty or so years. If you ask Bill to try the “thing-a-ma-jig” trick, he knows exactly what to do. The team already processes a common design vocabulary, so you don’t need to learn someone else’s.

Well… I read this in a book called Professional C# Design Patterns Applied. Anyway I can’t agree with all by 100%. What do you think?

Finding Effective Leaders

Madhawa Karunaratne — Fri, 16 Jun 2006 05:03:00 GMT

I found this interesting chapter yesterday when I was dipping into some e-books I got. Thought you will really like this.

For the person in charge of putting together a project team, the first task is to decide who will work on the project. This seemingly simple (but more often complex) decision can dramatically affect the project's outcome.
Finding leaders within an organization is not a difficult process. By definition, leaders are recognized by those they work with. It's important to remember that we are talking about leaders here, not bosses. Every organization has its share of managers, directors, and so on, but the hierarchical structure of an organization does not determine who the true leaders are. Actions and characteristics, rather than job titles, identify leaders.
Why do we need leaders? Because we have so many followers. It's important to realize that labeling people as leaders and followers does not imply a value judgment. We must have leaders to be successful, but we must also have followers. Leaders provide direction for the team. Followers get the work done. The team needs to strike a balance between its leaders and followers. It must decide what to do and then must do it, so both leaders and followers are equally important and valuable. An absence of either leaders or followers will hinder the project's success.
Certain characteristics are present in many leaders. Common qualities of leaders include:

Understanding and meeting the needs of others.
Communicating well with groups and individuals.
Earning the respect of internal and external customers.
Displaying commitment to well-defined purposes.
Making a positive difference.
Having confidence in his or her abilities.
Practicing good problem-solving skills.
Helping others to develop their skills.

Many people will read this list and say, "I do those things." More people will read this list and say, "I intend to do those things." But being a leader also means knowing the difference between intent and impact. When measuring their own success, people measure their intent; when measuring other people's success, they measure their impact. The impact that leaders have on others may or may not be their intent, and leaders' intent may not have the impact they were striving for. The proper way to measure people's leadership skills is by the impact they actually have, not by their intent. We can summarize this concept by saying, "Other people's perceptions are reality."

How compiler decides a method to inline or not?

Madhawa Karunaratne — Fri, 16 Jun 2006 02:05:00 GMT

When I’m dipping into improving performance of managed code I got wondered how compiler decides a method to inline or not.

Ok, First I’ll tell you what is method inlining (to whom, think what’s the hell is this inlining).

As all we know there is a cost associated with method calls; arguments need to be pushed on the stack or stored in registers, the method prolog and epilog need to be executed and so on. The cost of these calls can be avoided for certain methods by simply moving the method body of the method being called into the body of the caller. This is called Method In-lining. The JIT uses a number of heuristics to decide whether a method should be in-lined. The following is a list of the more significant of those (note that this is not exhaustive):

• Methods that are greater than 32 bytes of IL will not be inlined.
• Virtual functions are not inlined.
But if your virtual method is sealed its candidates for inlining as well as other compiler optimizations also.
• Methods that have complex flow control will not be in-lined. (Complex flow control is any flow control other than if/then/else; in this case, switch or while.)
• Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
• If any of the method's formal arguments are structs, the method will not be inlined.

But note on, those things might be change in future versions of the JIT.
And other thing, don’t compromise the correctness of the method to attempt to guarantee that it will be inlined.
Pretty interesting? ha