Leadership and Leading-Sheep

Leadership and Leading-Sheep

A lot of words and lines of words was and will continue to be written on the leadership topic.
You might have read about the "fact" that leadership is not something that you can learn, either born with or don't. I don't agree with that statement foremost because it is too deterministic.

Leadership qualities can be developed, up to a certain Level
From my point of view, leadership qualities can be developed, up to a certain level, by anyone. It is only depends on a complex formula of what are the collective aspects that impacts a person through out his life (parents, school mate, teachers etc.) and the current surrounding where he operates. Meaning it is related to internal and external variables. An internal factor example: A low self esteem that was generated due to parent or teacher(s) behavior, can lower the probability of the certain person to become a leader. An external factor example: A person can start new position in a company where other leader(s) are already in the premises, his coworkers or employees may not grant him the leadership.

Leadership is granted by the people themselves
The only deterministic aspect that one can set on the leadership phenomena is that, by all means, the leadership is granted by the people themselves. You can't force someone to accept you as his leader. Even if you have the right internal qualities you will only become a leader if coworkers or your employees see you as such. This part is very elusive because every people can define a leader a little bit different. Even if a group of people may define a common list of leader qualities they may not agree about the weight or impotency of each quality.

Why is it important?
The origin of leadership, is claimed to be in the Evolution. The ancestors of the very best leader exist in plant earth was an ape. Studies show that leadership also exists within apes groups, as well as in other primates (Richard Wrangham and Dale Peterson, in Demonic Males: Apes and the Origins of Human Violence). The leadership among ape group grants order and stability. In some studies it was claim that a grown up ape is emotionally equivalent to a human child.
All grown up people was once children that looks upon their parents and extended family for directions. Everything is new for a new born baby and there is lot to learn. Having someone to guide you is extremely important. This very early unconscious need stays with us forever. The difference between grown up people is the level of this need.
When someone is hired as a manager to manage an existing team or group of people he will be seen by them, almost immediately, as a manager as is title implies. They will see him as a leader only after a significant period of time, if ever.
In the Hi-Tec field, as well as in other, the leadership is important. The harsh competition create, occasionally, crazy deadline and enforce people to think out of the box in order to achieve differentiation against the competitors products. The manager can not move the "rock" up to the tip of the hill without the help of others. In order to achieve harsh complex work within pressure the manager should also have some leadership qualities. It may not be important in short term but it is surely critical in long term perspectives.
Example:
Two shepherd need to direct their herd back to the pen. The distance to the pen is very far and a storm is getting close. The sheep must arrive to the pen as soon as possible.
A shepherd that acts as manager with low leadership qualities will shepherd his sheeps to follow a certain path and to accomplish it within. From time to time he will "yell" to get back to the path or to hurry up. A shepherd that acts as manager with high leadership qualities will shepherded his sheep quite the same, only he will gather them before the long walk, explain what it is to accomplish and why. The shepherd will inspire the herd; "tell them" that he believes in them and together they will achieve the great task.

Leader qualities
There are many leadership qualities. The following is a list of the most important ones, as I see it.

Humility
o A leader does not give orders he asks and share.
o A leader does not take credits but give it to others.
o A leader looks at his coworkers and employees in their eyes not from above.

Accountability
o The leader will take the blame on him and not drop or include the collective in to it.

Integrity
o Say the truth all the time

Carrying
o A leader really cares about his coworkers and employees. He asked and listens. He really knows his people.

Role model
o A leader shows example.

Initiative and entrepreneurial drive
o A leader considers any problem as a challenge.
o Any challenge holds prospects to achieve wonderful progress.
o A leader has a clear vision that he shared with other.

Clarity
o A leader set clear goals
o Direct focus

Confidence
o A leader can take harsh decisions with mumbling
o A leader can take accountability and responsibility with no fear.

Why Software Projects Tend to Fail

Introduction
It is a sad statistical fact that software projects are scientifically fragile and tend to fail more than other engineering fields."A Standish Group research report shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates" (1)
The statistics also show results for different software company sizes and types:
"…such failures occur far more often than they should. What's more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation…" (4)
Scope
This article describes several reasons for software project failures.
When Can a Software Project be Defined as a Failure?
The failure mark of disgrace is quite arbitrary and subjective. Ask the project manager of a failure project and he will tell you that it is not. The intensiveness of the failure also varies from project to project. In a commercial software company, a failure will be related to the software consumer. For example:
The software did not meet with the consumers need.
The software release was later than scheduled (deadline violation).
The software had too many bugs.
Sad Statistical facts
According to research conducted by the Standish Group in 2005:
"… only 28 percent of software projects in 2000 succeeded outright …" (2)
"… Some 23 percent were cancelled, and the remainder were substantially late …"(2)
Why Do Software Projects Tend to Fail?
Note: The following list of software project failure reasons is not prioritized. Some of the reasons are claims that were measured by researchers. I have tried not to add my own judgment; it is left to the reader.
The maturity of the software engineering field
The software engineering field is much younger than the other engineering fields and that, in time, will get more stable
The field is young and therefore most of the field engineers and managers are also young. Young people have less experience and therefore tend to fail more
Young people are more optimistic and tend to estimate badly
Shortage of knowledge base
As a relatively young engineering field, software engineering is short of accumulative knowledge bases. For example, the famous gang of four book "Design Patterns: Elements of Reusable Object-Oriented Software" was first published in late 1994. The book suggests design patterns to common software design problems and it is one of the famous knowledge base materials in the software engineering field. "Software engineering has evolved steadily from its founding days in the 1940s"(5), but it is still short of accumulative knowledge base as opposed to other engineering fields. Another example is OOP (Object Oriented Paradigm). OOP is considered to be more successful than the previous procedural paradigm. OOP was only embraced by the Software industry in the 1990s. "Even though it originated in the 1960s, OOP was not commonly used in mainstream software application development until the 1990s."(Wikipedia)
Software is not tangible
As opposed to other engineering fields like civil engineering, the software engineering building blocks are much less tangible and therefore hard to measure and estimate. "Software is abstract"(2)
Competition: harsh deadlines
The competition in the software industry is harsh. The Time-To-Market (TTM) is crucial and the drive to meet harsh deadlines is enormous. This characteristic, along with other methodological anomalies like "Code first; think later" and "Plan to throw one away; you will, anyhow," makes competition harsh. The hard competition in the software industry causes not only the need to deliver ASAP, but also the requirement to catch as many potential customer eyes as possible. Firing in every direction causes disorganization, fast coding and projects that are not well planned.
Technology changes rapidly
"Software development technologies change faster than other construction technologies."(2) Until recently, Microsoft was frequently bombarding the industry with new technologies. Rapid technology changes introduce liability for software manufactures. For example, new Operating Systems obligate a company like Ahead to release a new adaptable version of Nero. A few years ago, Microsoft had decided to change the way it introduced new technologies to the software industry. It introduced the wave methodology. In this methodology, Microsoft agreed to release a bundle of technologies (tools, Framework, programming languages etc.) in waves, every several years and by that, let the software industry adapt and digest the new upcoming technologies. Lots of popular software like Ulead Video Studio and Nero that used to run on Windows XP do not run on Windows Vista.
Change is tempting
A building architect will not decide to add additional floors during the building construction. The result would be dreadful, as the building foundations were not constructed for it. The software architect's hand, however, will be much more loose on the trigger. Irresponsible changes like adding new features and redefining existed ones may cause deadline violations and/or bad planning and coding (patch). Given the harsh competition (see item 6), it looks like changes are inevitable.
Bad time management
Estimating the development time should correlate to the employees ("resources") on hand. In some cases, managers estimate and then enforce a time table as if they were the ones who were going to do the developing. This type of enforcement yields pressure on development and may harm it. Moreover, violating deadlines in this condition is common.
Bad or no managing skills
It is common that software managers are used to being excellent, successful and professional software engineers. Unfortunately, the skills are not the same when it comes to successful managing. Great engineering skills do not guarantee great managing. Newborn software managers do not receive the right, or any, guidance.
Wrong or no Software Development Life Cycle (SDLC) methodology
Developing life cycle methodology must be part of software project management. Nevertheless, it should not be forced into the R&D environment. The software engineering field is relatively young (see item 4), but still there are already well-known developing life cycle methodologists (Agile, Crystal, Spiral, Waterfall, etc.), successful stories and case studies. Software project managers may adopt one of the existing methodologies, but usually there is also a need to adapt the methodology to the company on hand. The adaptation includes: company culture, employees, marker, managers, etc. This is the Waterfall Model:
Bad or no documentation
Documentation should be considered as a "must have" and not "nice to have". Documentation is an integral part of developing the life cycle process. It should not be caught as a nagging tedious task, done for the sake of some strict QA manager. There are various types of software project documentation, each related to a certain stage in the development life cycle of the project. For example:
Statement of Work: preliminary requirements and project frame, usually written by the customer
Marketing Requirements Document (MRD)
Software Requirements Specifications (SRS)
High Level Design (HLD), written by R&D
Low Level Design, written by the R&D
Project Schedule
Software Quality Assurance Plan (SQA)
There are lots of templates and different names to the above documentation. Nevertheless, the important thing is that their existence requires the position holder to think before working on the project. The documents need to be stored and updated during the life of the project as it is done in a source code case (out of date document is a bug). Badly written or no MRD or SRS document can cause project failure (See item 11 bad SRS document).
Bad or no software requirements
As much as it sounds bizarre, in some software projects SRSs (Software Requirement Specifications) do not exist or are badly written. There are many types of SRS formats and even if it was only one common template, the content would vary from company to company. It is a question of how well-defined the requirements are. I have never heard about a well-defined SRS that caused projects to fail, but I am familiar with the opposite. A laconic requirements document affects the ability to break the software complexity, generate tasks and estimate time. Moreover, inadequate definitions cause misunderstandings and wrong implementation. Changes to the project during the development become inevitable and, in time, project deadlines will be missed.
Lack of testing
Those who develop the software should not test it. The developer should run unit testing, but it is not a replacement to an objective QA test.
Testing only at the end of a long milestone raises problems due to the load of testing and inherent problems that should have been caught at earlier stages.Moreover, managers tend to rush the testing period at the end of the milestone in order to release on time
QA that does not bite and has no real power does not have the right effect on the R&D department and is there for the project itself.
QA should be started as soon as the software project starts. Hence, even in the planning stage. QA participation in early stages is important for its preparation for the software. For example, QA should also check the SRS document and make sure that the software was implemented according to it.
The following Professor Brooks rule of thumb might seem radical, but being given no proportional time for planning and testing is indeed problematic: "1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing."(3)
Tester to developer ratio: there is no rule of thumb that defines the number of QA engineers per software engineer. The reason for that is that it depends on many variables and more specifically on the characteristics of the software. For example, if "multilingual" is a software requirement, then the number of tests increases. Another example will be the number of supported Operating Systems. The number of testers required to test the software requires estimation. Bad estimation can cause project failure. There are several models that help with Tester to developer ratio (see reference number 7). According to a recent informal survey held at QAI's 20th Annual Software Testing Conference in September of 2000 (8):
Poor communication among the "Holy Triangle": customers, R&D and marketing
The "Holy Triangle," as I define it, describes the important relationships between the customers, marketing and R&D. As seen in the picture below, the marketing side combines the Customer and R&D. Marketing interviews the customers and picks at their needs constantly. Then it brings the important knowledge to the R&D department. Strange as it may seem, in some commercial software companies, the customer requirements and needs are not gathered. This anomaly can happen if the company suffers from "Hero base project." In this case, a certain persona, usually the company CTO, enforces the project requirements without taking into consideration the market and the customer's real needs. The result of this behavior might be the creation of software that lacks the market needs and, in time, is a project failure. "… The communication of requirements from customers to developers is a common source of problems, as is the communication from developers to customers of the repercussions of those requirements…"(2)
Human resources management
It is a given fact that lots of software project managers start working without the basic guidance of how to motivate people to succeed. Software managers tend to manage their software engineers only in the professional engineering aspects. However, software engineers are people too. Learning what motivates them requires time and will from the manager side. No two men are alike, both in terms of management and motivation.
No version / source control
Surprising as it may sound, some software projects are not backed up in source control. Sources get lost; versions cannot be regained; products on customer's side can not be reconstructed.
No or bad risk management
"…A project risk is an uncertain event or condition that has consequences for the project…The purpose of risk management is to identify, analyze, and respond to project risks…"(2). Given the above items and the fact that software projects tend to fail, it would be absurd not to manage risks. The Risk Management Document is the foremost design to enforce the software company to think about what can go wrong. The thinking process itself can solve problems before they even happened. Examples of risk:
Incomplete or badly written requirements
Choosing a technology that is not known by the current developers
Relying on complex third party software
The Risk Management Document needs to be updated during project life cycles. It should not be too general or vague, but address real details of problems that might occur.
Summary
"…Software development isn't just a process of creating software; it's also a process of learning how to create the software that is best suited for its purpose."(2) The article describes some of the answers to the question, "Why software projects tend to fail?" I encourage the reader to keep reading on that topic for two main reasons:
Knowledge: knowing why software projects fail is a good start to preventing your own software project failure.
Incomplete: the information in this article is incomplete; I consider it as a promo to keep reading.
Bibliography and References
The CHAOS Report Standishgroup web site, 1994
Software Project Secrets Why Software Projects Fail George Stepanek, Apress, Sep 2005
The Mythical Man-Month Essays on Software Engineering 20th Anniversary Edition, Frederick P. Brooks, JR, Addison Wesley, Aug 2002 Why Software Fails, spectrum IEEE Online, Robert N. Charette
History of software engineering, Wikipedia
Theory and Problems of Software Engineering David A. Gustafson, McGraw-Hill.
Estimating Tester to Developer Ratios Kathy Iberle,Sue Bartlett
The Elusive Tester to Developer Ratio Randall W. Rice
Templates and Guidance
Project Reference
Recommended Requirements Gathering Practices Dr. Ralph R. Young, Northrop Grumman Information Technology

Time management - excuse me, do you have the time?

You have probable already know that time is limited, right?
By now there are thousands of books and articles about this topic. All saying time is a limited resource use it wisely.
But can you really manage time? Time is not a dog that one can train.

While it is a physical fact people tend to misinterpreted the philosophy behind it.
As Marshall J. Cook write in his book: Time Management : Proven Techniques for Making the Most of Your Valuable Time
"Contrary to popular belief, effective time management is not based on doing more things in less time. That's just not going to happen. Time management is about doing the right things better."

Another example is Richard Koch: "Living the 8020 Way - Work Less, Worry Less, Succeed More, Enjoy More":
"We Have All the Time in the World" here is a very philosophic story from his book:
"At the age of 30, an extremely successful Wall Street trader decided to go to Tibet, enter a monastery, and undertake rigorous spiritual studies.
On his first day, while his fellow trainees were hanging back, the extrader marched up to the top Zen master and asked, “How long does it normally take to become enlightened?”
“Seven years, ” the Zen master replied. “But I was top of my class at Harvard Business School, I made $10 million at Goldman Sachs, and in preparation for entering the monastery I’ve taken all the best time-management courses. How long will it take me if I study intensively and try extremely hard to cut the time?”
The Zen master smiled and said, “Fourteen years. ”

I read quite a lot of books on that topic and tend to agree that time do need to be manage.
The R&D manager should allocate time to think about what it is important to do. He should follow the Pareto principle: "80 percent of results come from only 20 percent of causes or effort" this is the most excellent time management tool - although it is not easy to be mastered.

A software architecture toolset for choosing the right type of Client Application

Introduction

The article deals with an important question, one that raises a lot of debate in the .NET software architecture world.
What to choose: "Web-Application" or "Desktop-Application"? Rich-Internet-Application or a Smart-Client?
The reason why this question is asked so frequently recently, is that both technologies are getting closer and closer and when the distinctions becomes fuzzy the decision is harder to make. For example, Smart client introduces smart deployment and diminishes one of the biggest cons of Desktop-Application. With Ajax, Web-Applications run faster and with enhanced user experience.
Before we get started it is important to say right here and now that the define question above must always depends on the business problem.
It will be an obscene act for a developer or architect to choose a technology based on a whim. Technology should not be chosen on stuffy professionalism either. Many companies choose technology because this is what the current developer knows and good at. Choosing the right application type is crucial in many businesses. The end users and the business problem on hand, are the ones who should take the lead in the decision making.
This article does not deal with a certain business issue. It discusses the common pros and cons of each methodology.

The Dialog

I choose to face with this question in a dialog form. The Dialog is conduct between two software architectures.
Socrates: a Web-Application advocate and
Plato: a Desktop-Application advocate.

The dialog format allows me to not take a stand. In a matter of fact I don't have a stand. I think both technologies are great and when there is a need to choose one of them it should be according to the business problem.
You are most welcome to join to their (imaginary) debate held in modern Greece in one of the Tech-Ed .Net seminars.

Socrates:… But Plato, your claim about the needs for constant software upgrades only strengthens my argument that Web-Applications are the best technology. In a Web-Application the application is actually located on a remote server which you can upgrade when ever it's needed and it reflects to your users online. In other words, when all the code is in one place everyone sees the latest release.

Plato: Well, with ClickOnce technology a Windows-Form-Application can be deployed and launch from the Web. With this type of technology software upgrades have never been easier to maintain.

Socrates: Oh, I heard about what it is capable of, but isn't it too cumbersome to accomplish? You do need to make all the assemblies strongly named and the amount of folders and files it creates on the web server is quite…well… cumbersome. Moreover, who wants to install a Desktop-Application on his hard drive if he does not have to?

Plato: Well, I guess this technology will be improved by the Redmond fox in the future. Right now, the user can choose between offline and online executions. In both modes the application is installed on the machine. The difference is that in offline mode the application can be jump started and get updated from the desktop while in online mode it can be run only from the web link as before. Please also know that ClickOnce is not the only solution. A "home made" solution like using a Web-Service that the Desktop-Application communicates with, checks and install updates are easy to develop.

Socrates: So you are basically saying that in online mode, which is closest to running a Web-Application, the application is reinstalled again and again in each run. What if it is a big application in term of Mega bytes? Well, my dear Plato I rest my case.

Plato: No, you haven't, because there is some kind of caching mechanism that improves this behavior. I guess, the .Net Framework only downloads the required files.

Socrates: Hmmm…, .NET Framework you said. Well do I smell a software perquisite in the air?

Plato: You do smell well, but do understand that the user must not have the .NET framework on his computer or must preinstall it manually. The deployed ClickOnce application can be easily defined to support the installation of the .NET Framework (bootstrapper). Dear Socrates, as you well know Web-Applications commonly require ActiveX installations? Those requirements often scare users because they are commonly causing the web browsers to display intimidating security.

Socrates: Well, you are right; today's web browsers do make us lots of headaches. But, Windows firewalls often do the same for Desktop-Applications.

Plato: In Desktop-Applications as opposed to web-browser the application has rights that are granted from the logon user. It can access system data like IP Address, Registry, Files, Windows Shell integration etc. In a script mode the Web-Application is very limited and the ActiveX technology is one of the last resorts. Web-Applications cannot leverage local resources like CPU or installed software either. Moreover, isn't true that ActiveX is also being used in Web-Applications to enhance graphic capabilities like Charts, Maps etc.

Socrates: Well, it depends on what the Web-Application is obligated to do. But, yes it is often use for more complex and some kind of fancier UI controls.

Plato: I guess you will also agree that Web-Application will never be capable to support GUI and visualization functionalities like Desktop-Application. For example, the user interface must travel back and forward across the web in order to be refreshed.

Socrates: I wouldn't say always. AJAX, for example enhances the UI capabilities.

Plato: AJAX also added tons of client-side script code and that hurts performance and harms the user experience. With AJAX, Web-Applications stop being a thin application and start to get fat. Speaking of scripts, isn't true that debugging capabilities of client and server side scripts languages like VB and Java script are impossible. Isn't also true that developing in this kind of script language is klutzy?

Socrates: With today's ASP.NET technology, server code (code behind) can be written in a high level language (any .NET aware language) that can be of course debugged. As for client and server side scripts I am afraid you are right.
Plato, with you permission I would like to talk about application availability. As you recall, in Web-Application the application is available and can be access from anywhere without installing anything on the client machine. For example, Gmail is a web-based Email application. You can enter to your Inbox no matter where you are. In case, you are entering an Internet-Café you surly be permitted to enter to Gmail but not to install any application on the machine.

Plato: Yes, I see your point. But what if I am in my home or at the office and I want to see my Emails but the Gmail server is down or I have temporarily lost my Internet connection. I will not be able to see my Emails right? Web-Application must be connected to the server all the time. In other words Desktop-Applications offer better offline and caching capabilities. There is no need to waste time waiting for screens to refresh or networks to become available

As opposed to:

Socrates:Well, if you need smart caching and offline capabilities you are right. Another thing that I would like to mention is a cross-platform capability. If your Desktop-Application is targeting to a world wide use will you be able to install it on Linux and on Windows OS. Even if you have decided to support only Windows OS family you will still need to support and test your application on lots of versions like: 98/ME/NT/2000/2003/XP/Vista.
Not including sub versions like Home and professional editions. You will soon notice that the above OS supports different APIs and acts differently. In case of a Web-Application you are running within a well tested application (like IE) that was already tested on those OS. Web Browsers are also committed to standards like HTML and Java scripts interpretation. Therefore, as long as you stick to standards you will have no problems.
Plato:At the beginning, you have almost convinced me, but then I have figured there are a lot of web browsers vendors and lots of web browser versions. Also there are a lot of technologist like ActiveX and Flash that will not work on Mac web browsers. Nevertheless, you are right if the Web-Application is simply enough will be easier to support world wide users.
Socrates:Well, working with a markup language like HTML also holds lots of simplicity and flexibility capabilities.
Plato:It is true! But at the same time it is also very limited. With XAML markup language, Desktop-Applications also enjoy the flexibility like HTML plus much more enhanced UI capabilities.
Socrates:OK, Plato we are not even close to end this debate, but I do need to go. I have a meeting with Xenophon at the local SPA.
Plato:Adio! Socrates. Send my regards.
What does the future hold?It is hard to say what to future holds. One should be a profit to tell. My guess is that we are going to face with the article question for a long time, at least for the near future.
Looking at brand new developing styles like SmartClient and AJAX, makes you think that no new revolutionary progress have been made in the last years.
"…AJAX is not a new programming language, but a new way to use existing standards." (http://www.w3schools.com/ajax/default.asp)
"…Smart client isn't a technology, and it isn't any specific architecture. It is a style of application that combines the best of both Desktop-Applications and Web-Applications." (http://msdn.microsoft.com/smartclient/community/scfaq/default.aspx)
Some of the common use technologies are really very old:
ActiveX in 1990 (http://en.wikipedia.org/wiki/ActiveX) VB – 1991 (http://www.startvbdotnet.com/dotnet/vb.aspx) MFC -1992 In 1994 the very earlier version of HTML was introduced (http://www.w3.org/MarkUp/historical). JavaScript in 1995 (http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html) Flash - In 1996 Smart-Client vs. Rich-Internet-Application (RIA)"Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e. maintaining the state of the program, the data etc) back on the application server. (http://en.wikipedia.org/wiki/Rich_Internet_application)
Rich Internet Applications are already here. Google is one of the world leaders in Rich-Internet-Application. Here are some of examples: Gmail, Google Calendar and Google Docs and Spreadsheets.

Rich Internet applications characteristics:
Run in a web browser Typically much more responsive than a standard web applications Richer UI Has a look and feel of a desktop application Smart-Client characteristics:
Are delivered over the web Do not require installation Automatically update without user action Trends
The complexity of applications is increasing Connectivity and Network awareness- Different application types to the same source of data. Connect to the data from Mobile, Desktop application at the office adn over the web when out of the office A2A – similar to B2B only with application that can talk with each other by using standards like Bluetooth for Mobile devices. Save data online - Google Bookmarks for example and MS Messenger keep the user information like Favorits in the web. This allows the user to see the stored data from different PCs. Application recovery – return to previous state no matter what happened to the last application run. SummaryChoosing the right technology must be anchor to the business problem on hand.
You would not develop a diagram drawing application like MS-Visio as a Web-Application as you would not choose a Desktop-Application for Amazon book store.
The article describes some of the Cons and Pros of each technology. Knowing them is a good start for a decision making.

Principles (YAGANI, KISS, 80/20)

The following are worth to mention principles.
They are useful not only for Software management but also for life in general.

YAGNI Principle- You Are Not Gonna Need It
The YAGNI principle is very simple to grasp. It make you postponed the decision about stuff that you think that you need TODAY to later on.
It does not mean – be lazy!
It does not mean – don’t plan.
What it is mean is that you can take stuff into consideration NOW but you should postpone the implementation to later on.

The YAGNI principle emphasis TIME and CHANGE
- It helps you understand that things might changes during the time. It helps you avoid doing something that you won’t need eventually or when the time of implementation arrives you understand that you need something else.

- The principle save you time twice. First, you don’t spend it now on something that you might don’t need. Second, when you reach the time when you need it, you don’t spend time in rewriting and refactoring but write once and well.

Challenge
“If you don’t do something now, then it will take much longer to do it later on”. I disagree, first of all the statement is too deterministic, secondly, the YAGNI principle don’t implies not to plan or to think in advance. It is sure important to do it. What it states is that you don’t need to implement stuff now because you will need it later. Do plan/think/design/take into consideration; don’t implement it, yet!

More reading
http://c2.com/xp/YouArentGonnaNeedIt.html

Wink
If you are not going to start implementing YAGNI today, then you are already violating it by reading this far :-).


KISS principle – Keep It Simple Stupid

The Kiss principle helps you avoid complicating problems. Overcomplicating problems blocks your mind from seeing the simple working solution.
When we grow up, we tend to shed the ability of simplicity. A child looks at the world in a much simpler way. This is why we often dazzle from children questions or remarks about day to day stuff.

Implement the KISS principle is really easy. Foremost, when you are challenge with a problem start by asking yourself why it is a problem anyway. This allows you to understand the problem, well. Later on you should break the problem into several pieces. This will help you identify where exactly the problem is. Maybe the problem consist several small problems. Smaller problem are easier to solve. When you have a solution always challenge yourself with the question – is it really the simplest way to do it?

More reading
http://people.apache.org/~fhanik/kiss.html

Wink
If you did not understand what KISS is, then I did not follow the principle well :-).


The Principle of least effort
The least effort principle helps you do stuff simpler. It directs you to find the most effortless paths to solve problems.

More reading
http://en.wikipedia.org/wiki/Principle_of_least_effort

Wink
I didn’t write a lot about this principle because I have chosen one of the effortless paths to explain the principle :-).

The Partew law of 80/20

The principle helps you to focus about what is needed the most. It emphasis efficiency and stress out that time is a very precious commodity.

The principle implies that 80% of your user will use only 20% of your Software. Therefore you should focus and give 80% of your effort for the specific 20% features. Given that you save time by not implementing something that the majority of users don’t need, you free your time to excel the very specific 20% and to create new other software. In other words, the 20% effort will give you 80% of your result.

The Partew law of 80/20 is not easy to implement. It requires practice. Foremost, when you need to do something you need to think/imagine what will the less effort way to do it? How to do more with less? The challenge is, of course, to identify those 20% percent.

The advantage of the Partew principle is that it reminds you to focus on the 20 percent that matters. It means that not only you should not work hard but smart and on the most important things.

More reading
http://management.about.com/cs/generalmanagement/a/Pareto081202.htm

Wink
Following the Partew law I could have write this explanation in 20% effort and still make you understand it :-).


Principles correlation

• YAGNI principle allows you to focus about what you currently need and by that blends very well with the Partew law of 80/20.
• YAGNI principle is easier to implement if you practice the KISS principle, because if you think in a simple manner you don’t enter yourself to fiascos for stuff you won’t need eventually.
• The KISS principle blends very well with Partew law because it let you focus on what is important. It saves you time and energy because you can do things faster and better.
• The least effort principle blends well with KISS because it directs you to things simpler not only for your sake but also for the sake of the users. The principle itself is an implementation of the Partew law of 80/20 because it implies of doing only the very necessary stuff in order to achieve the needs.
  

Multi-processes versus Multi-threads

Since the most impact is related to CPU and Memory usage the following questions should be ask before deciding Multi-processes or Multithreads:

1. What is the amount of data that it is to be shared between the different executing tasks?


2. How frequently the separate tasks needs to converse with each other?

Notes:

• Threads have almost no overhead in sharing data. It is a built in feature. processes however have a considerable overhead in regards to sharing data.
• There are less context switches per threads than per processes. When a process accessing a resource (FileMapping) two context switches occurs from user mode to kernel mode . The additional context switch increases the execution time.
• Kernel object that is used in Multi-processes constelation is ought to be Named. Named Kernel Object adds additional overhead (the OS use additional global handles tables that correlate between the handle table of each process).
• Sharing memory between processes is more complex to achive in term of development time (RAD).
• Shared memory between processes produce less readable code.
• Shared memory code between processes is harder to debug.
• Since processes are isolated from each other by the OS, an error in one process cannot bring down another process. Multi-processes is more robust than multithreads.
• In Multi-processes there is a chance that code will be duplication and additional utilization of the memory (RAM) and pagination (HD) will occurred.
• Process may run in different user context and have different permissions.

Code review: a chance to learn and to progress

When done it a professional way code review is a great opportunity to progress not only the code
but the professionalism of the participants.
When I saying in a professional way I mean that the attitude of the participants is in favor of the process.
This opposed to:
- "Here is my chance to show you how much better I am than you"
- "Here he come again like he have something to offer"

How to create the proper motivate:
One should explain the purpose:
- QA does not check your code only its functionality.
- It is always a good thing to have additional two eyes.
- It is a chance to learn something and to progress
- It is not a stupid unnecessary step it is really important.


Nominee the right people for the job:
- Great Software Engineering background.
- People see them as professional.
- A high people skills.
- Holds a positive attitude to code review
- Have patient and know how the guide


How to conduct the code review?
First of all schedule a meeting with all the code reviewer and ask them how they think it
should be done. Sharing the process with them increase the chances that they
will be more cooperatively.

The reviewer should be very positive about the process:
- Not to criticize the person who wrote the code.
- Focus on the code and not on the coder.
- Do not use criticism intonation.
- Suggest improvements in a question form: what do you think about doing it like this?
- Remember that there are another ways of implementation.
- Say some good stuff about thing that was done right. When you praise someone first, his ears are opened to here constructive advice.


What to check?
Here are some examples:

- Does the code do what is supposed to do?
- Allocations, release of memory.
-Close KO (Kernel Objects) handle.
- Reuse.
- No duplicate code.
- In condition using "==' and not "="
- WaitForMultipile and not WaitForSingleObject
- Input validation.
- Not using INFINITE in wait methods
- Use of code log (debug...Fatal)
- Use of comments.
- Effective code (Performance)
- Too many or too few placeholders: Like string.Format("{0}{1}",m_a); this code will be compiled but crash in run time
- Finally usage when using try catch and allocate resource that have to be released
- Check code notation.
- Readability.

Performance tests: why? when? where? and what?

When to do the performance tuning?
In short. Always!

From the PRD stage - Benchmark and performance requirements are must. It is the only way to validate the architecture/Module/Functionality of the system against the users and the system goals.
From the SDLC point (Software development Life Cycle): In the very beginning and in each stage of the iterations. Performance as other requirements should be validate in design time. It is the mean to change the design and choose the right technologies from day 1.
From the QA (Quality Assurance) point of view: In the very beginning and not only for TDD (Test Driven Design)


Methodology / Criterion
The performance tests should be done in a methodological way. Meaning with the same actions/procedures and on the same machine configuration (SW and HW). This is important for regression detection scenarios. The tests should be done against well defined criterions. Have you ever heard your PM (Product Manager) saying: "It should run As-Fast-As-Possible). It is not a joke it is a-crying-shame situation. Without proper criterions one can not do performance tests. Ask your potential or existing customers. If you can't set performance criterion then start with exaggeration - it is better than nothing (although it is not the best practice).


Performance get bad over time
Performance issues are rarely related to one function or code snippet.
It is usually an accumulation of issues gathered overtime. This is the reason why the performance should be checked against valid criterions all the time.

The phrase that the strength of the chain depends on its weakest link, have much truth in performance issues.


The right Tools
It is does not matter how and with which tool you check the performance as long as it done right.For example if a developer check how long it takes to run a certain code flow it is better to use thread Time (::GetThreadTimes) rather than enddatetime - startdatetime. The reason for that is that it is the only way to calculate how long the execution took in CPU time, without IO and context switches. Using date time subtraction can yield different result in each run (methodic).

The right environment
The performance should be checked with the Hardware and Software environment (as exist in the field). This is a very important information that should be collected from the field. Machines with the exact environment should be bought and test against. For example:

HW (CPU, RAM, HD etc.)
SW (OS type, anti virus, Firewall)


Code Coverage
In order to make sure that the code performance is good you have to test all the code flows. This can be done only by code coverage. There are good code coverage tools that you can use or to do it yourself. Be sure that some of the customers will run the most esoteric flow and run into problem. The lab is never a correspondent of the field.


Load tests
Benchmarking criterion should be define for Idle, Normal and Load cases.


Datasheet
Since your customer will ask for a datasheet is it a good practice to think about one from the very beginning. Customers want to know what is the performance hurt and latency you bring to their system. They do that because they run comparison tests with your competitors and because they are obligate to. You can not avoid from such information. It is not a bad thing ; it is good. For that reason you should be caring for performance. Since you have criterion and you are doing your best to meet with them and beyond you are in good shape.


Iterations
The performance should be check in each stage and iteration. The PM should bring all the frequent type of customer system configurations. System architect should validate the performance in the existing architecture and also against the future extension as the system evolves. Prototypes should that simulate the system should be created in the early stages. The developer should do it a part of their unit tests and the QA should do it for the specific part and the whole system.


Which of the system parts to handle?
In short. All!
Have you heard in the past someone says: "It is the GUI application and not the server so why bother." or
"It is the Audit service - it is not in the critical path of execution"
Those thought are wrong. Each part of the system between tires and within must be pass through a performance glasses.


Performance process
The performance process includes iterations of testing and tuning. Code coverage, memory, CPU and IO profiling should bu conduct.

Performance is an important factor. For some systems, customers consider it as one of the high measurements of criteria. Customer, therefore, can choose to buy a system on that basis along.

Requirements – The RnD Manager Oxygen

Good requirements are one the important building blocks of Software Product (probably every product).The question is what makes a requirement worthy for the title: “Good” and why it is so important in the first place.From my point of view, good requirement comes from the field (e.g. customers), excellent requirement comes from several customers. Running a successful Software product is not an easy task (see my previous post about Why Software Project Tends to Fail?).

The success formula is easy to define but not to implement:
(Gather, as much as possible, requirements from the customers) + (Design proper architecture, implement and test the product) = Happy/buying customers.

There are many reasons why this basic sheer formula is not so easy to implement. In this post I will deal with some of the hurdles and what should be done to tackle them.

Gather requirements
The stage of requirement gathering is one of the critical paths in the process. If you have a lot of customers or potential customers then you are lucky. In some extreme cases the company do not, even, have an existence market for the Software. In all cases requirements existence is a must.
What to do?
- Try to deploy the Software to as much as many beta-sites (if it is not risk future sell). In this way you receive real industry feedback.
- Make your customer a partner. Make them feel and think you are there for them.
- Do depth competitors analysis (if exist and relevant). Try to figure out not only what are the advantages of their product and which features your Software is short of, but also what they are planning to do (type of BI: Business Intelligence).
- Order or try to find market(s) analysis papers.
- Do whatever it is requires – you have to have requirements!!!

Requirements analysis
If you can gather the information above then you are partly done. Before you rest, you might face with another challenge to consume and analyze all the information.
What to do?
- In order to digest the requirements you can use Pareto Law of 80/20. Try to figure out what it is the most important stuff to do. How they fit together. Which effort (20%) will yield the 80% selling factors?. Another approach is to use the bucket sort algorithm. Try to identify repetitive-asked-requirements by putting each requirement in a bucket with its definition. If you end up with lots of filled buckets then continue and assign weight for each requested customer. This modus operandi fine tunes the priority of each bucket/requirement. At the end if you still have a lot of buckets with the same weight then you need to analyze the dependencies, resources on hand etc.
- At the very end of the process turn back to some of the requirements feeder (e.g. customers) to make sure you understand everything correctly.
- As seen the figure above the analysis and part of the gathering of the requirements are the job of the Business Architecture. In most companies this job title does not exist. Ignore the title ; the important thing is that one person spread his umbrella over the entire process. This character is a master in business/product management and has lots of knowledge in Marketing and in IT too.
- This is the guy who coordinates between customers (field needs) and the IT department.
- The Business Architecture have a very complex job. He need to analyze the requirements while taking into consideration the past, present and the future. In other words he need to know what exist right now, how it will combine with the features and how it reflects near and far, even imaginary, future.

Requirements documentation
It does not really matter what type of document format your company is used to write and maintain. PRD, MRD, SRS whatever! The only important thing is the existence of the document that cause the writer(s) to think about it all.
What to do?
-Foremost, understands that requirements documents deals with what the Software should do and, by all means, not how it will do it. It means that the requirement is described in UCD (User Centric Design) from the user point of view. For that matter, requirement can describe the functionalities in term of GUI it can also includes definition of user experience in terms of response time. It is the IT department domain to define how it will be implemented;therefore this kind of information should not exist in this type of documents.

The Business Architecture is responsible to steer the product manager stuff to write requirements documentation.
- The format and content is changed between companies in some cases the R&D department receive general requirements characteristics and in others it get all the nitty gritty. The important thing is that after few iteration the all parties understand the requirements in the same way - Follow the KISS (Keep It Simple Stupid) principle. The document worth nothing if it not understandable to all parties.
- Make sure to keep update the document along the way. One common mistake is not to control and treat requirements document as it is done with source control.

System Requirements
This stage includes the implementation/integration of the Business Architecture and the new requirements with the Software architecture.
What to do?
- The IT Architecture receives the documentation by the Business Architecture. In some companies there is no job title like IT Architecture. In some companies the job is done by the CTO or and the R&D Manager. This IT Architecture is a master of Software architecting and designs, he also have a lot of knowledge in the company business and system analysis. This type of characteristics allows him to communicate well with the Business Architecture.
- After the IT Architecture and the Business Architecture understand the current and future needs there is a better chance that not only the requirements on hand will be implemented as planed but also, and not less important, the Software architecture will keep support the future business.

Keeping a Desktop Application Up-To-Date - design proposal

Why?

Make all the users around the world to use the latest up-to-date version of the application.

Easier the support (All bug fixes and new features are deployed to the customer ).

Phone-home: Learn what the customer does by detecting who download updates how often, who use the application and how.

How?

Installshiled or equivalent package (Macrovision Notification Server:
http://www.services.installshield.com/).

Click Once: for .Net 2.0 Applications (http://en.wikipedia.org/wiki/ClickOnce)

In-house solution (homemade).

In this post I concentrate on the In-House solution because I have found out that the other two are cumbersome and has significant cons. Foremost, I can say that there is no industry solution that it is perfect because only a Homemade solution is tailored to the company/project needs.


Web updater characteristics

1. Communicate with remote server to send and receive data like: Update management, Report a bug, Suggest a feature and Phone home (http://en.wikipedia.org/wiki/Phone_home).

Update management includes the following: Check for update, Download updates (Silently / Actively) and Install update.

2. Checking for update can be done implicitly on application startup and explicitly whenever the user wants. In case update is available a proper message should be displayed. Here are some characteristics of the message:

*Message can be display as a pop up notification near the toolbar clock)
*It is a good idea to send the entire message from the server side where it can be adjust to user culture.
*The Message should contain information like: Main Application name, Current version, new version, link/button for download the updates etc.

3. Update operation:

The Main Application should be of course close before the update. It should be validate as closed too (e.g. name event)
The client side web-updater should not run from the Main Application folder. The reason is that the a certain update procedure might also replace it. A good practice for that matter is that the Main Application copies the web-updater to a temp directory and run it from there.

4. Some UML diagrams:

QoS and LoS

QoS (Quality of Service ) and LoS (Level of Service) refers to provisioning of resource utilization mechanisms.
The terms are used by various type of fields such as Road traffic and Hotel accommodation.
In this post I, naturally, concentrate on the Software Engineering field and in particular to Data Flow across Networks.

Foremost, QoS and LoS are not related to quality assurance in the pure sense of the term. High QoS is not necessarily correlated to high performance.
The QoS is build on mechanisms that takes, in advance, into consideration that the quality will be varied along the time.

For Network data flow the LoS is important because usually the Network bandwidth is limited and insufficient.
In QoS the best quality achieved at a given time, must take two main conjunction factors into consideration:

• Human Factor: Assure that the supplied services, supplied to the user, are the best at the given time.
  
• Technical Factor: Assure that the resources utilization like CPU, Memory and Network are within the configured, low and high, capacity (resource reservation)
  

The QoS is achieved by provisioning the resources utilization over time. For example: An RPC Server that stream video to cellular device should support QoS mechanism that it is guaranteed by encoding the rendered clip in different level of bitrates and FPS. In this way the clip will be continue to rendered in the device even when the cellular Network is loaded or interrupted.
The well known cons of QoS & LoS mechanisms of Network Data Flow are:

• Data looses
• Data quality degradation
• Delays and Gaps

Web 2.0 and 3.0 a new way to do business

web 2.0 introduce revolution in term of new emerged business that embraces new technologists to support it.
The main change is the users participant in this business. Users are active and not passive.
The network is the platform. On this platform the business rules are different. Users are the engine.

The business is how to attract users to enter and to contribute. Fascinating example is Facebook and YouTube.

“…the philosophy of mutually maximizing collective intelligence and added value for each participant by formalized and dynamic information sharing and creation” (Overview of business models for Web 2.0 communities, Högg, R. Meckel)

Web 2.0 applications address the following:

• Harnessed Desktop application capabilities
  Brings Desktop applications capabilities to the web, both in usability and graphically.
  Rich Internet Application (RIA) is available by technology like Ajax that enables web controls to act as desktop one with more
  data refresh capabilities, drag and drop etc.



• Connectivity with services
  Utilize 3rd party services to leverage the web application capabilities and to allow RAD (Rapid Application Development).
  By using web services, web2.0 application can expose themselves and connect to other services.
  Buzz words and Examples: SOA, Ebay and Amazon use of PayPal



• Attract the user to participates
  The web as opposed to desktop application is far more reachable by users. This basic fact introduce new business potential that is based on commercials.
  The web2.0 introduce the social web or social networks. The user is a participant. The web2.0 application is based on users that are willing to contribute: blogs and wiki are good example. I guess it fulfill the needs to leave something that we have created in the written as type of legacy and influence (is this is the reason why I write this blog??).
  Web 2.0 application leverages the users knowledge into global sharing information. The web site is enriched by the users(community) and not mainly by the owner (company that create it) Users communicate with users rather than with the application publishers

• Move "page functionality" to client site as much as possible. Implements via Javascript/CSS2.) No-Tables html layout3.) No page refresh for content updates (Ajax actually)4.) Search engenies friendly URLs & entire html code

Examples:
YouTube (social video network)
Picasa web and Flickr(social photos network)
del.icio.us( social bookmarking network)
Wikipedia
Blogger
Feedback (Social friends and groups network)
RSS
Mash-up
GMail
NetVibes (services)
Yahoo

Web 3.0
The main concepts of web 3.0 are:

• Platform and device independent (can run on wide range of devices)
• Application are pieces together (advance mash-up).
• Aplication are relatively small in size
• The data in the cloud/network
• Very customizable
• Distributed by social email, social network. you do not buy in the store. you download it, you send it to a friend etc.
• Semantic web – adding AI (Artificial Intelligent) to the web.

Good reading material

Software Engineering

• Debugging Applications by John Robbins
• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, ichard Helm , Ralph Johnson and John M. Vlissides
• Effective C++ by Scott MeyersThe C++ Programming Language by Bjarne Stroustrup
• Introduction to Algorithms by Thomas H. Cormen
• Operating System Concepts by Abraham Silberschatz
• The Pragmatic Programmer: From Journeyman to Master by Andrew HuntWriting
• Secure Code by Michael Howard
• Art of Computer Programming by Donald E. Knuth

Software Architecture

• The Art of Software Architecture: Design Methods and Techniques by Albin, Stephen
• Software Architecture in Practice by Bass, L., P. Clements, and R. Kazman
• Designing Hard Software: The Essential Tasks by Bennett Douglas
• Evaluating Software Architectures: Methods and Case Studies by Clements Paul
• Documenting Software Architectures: Views and Beyond by Clements Paul
  Patterns of Enterprise Application Architecture by Fowler Martin
• Large-Scale Software Architecture : A Practical Guide using UML by Garland Jeff and Richard Anthony
• Essential Software Architecture by Gorton Ian
• Applied Software Architecture by Hofmeister Christine
• Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives by RozanskiNick
• Code Complete by Steve McConnell
• Computer Architecture: A Quantitative Approach by John L. Hennessy

Project Management

• The Little Black Book of Project Management by Michael C. Thomsett
• Rapid Development, Steve McConnell's
• The Art of Project Management - Theory in Practice by Scott Berkun
• Project Management ToolBox: Tools and Techniques for the Practicing Project Manager by Dragan Z. Milosevic
• Agile and Iterative Development: A Manager's Guide by Craig Larman
• Agile Software Development Quality Assurance by Ioannis G. Stamelos and Pagagiotis Sfetsos
• Productive Objects: An Applied Software Project Management Framework by Robert J. Muller
• Software Project Management: A Unified Framework by Walker Royce
• A Guide to the Project Management Body of Knowledge by Project Management Institute
• Applied Software Project Management by Andrew Stellman
• Managing Software Deliverables: A Software Development Management Methodology by John Rittinghouse
• Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software by Bijay K. Jayaswal

Risk Management

• The Essentials of Risk Management by Michel Crouhy , Dan Galai and Robert Mark
• The Fundamentals of Risk Measurement by Christopher Marrison
• Risk Management in Software Development Projects by John McManus
• Quantitative Risk Management: Concepts, Techniques, and Tools by Alexander J. McNeil ,Rudiger Frey and Paul Embrechts
• Applied Software Risk Management by C. Ravindranath Pandian

Cost Management

• Cost Management: Measuring, Monitoring, and Motivating Performance by Leslie G. Eldenburg and Susan K. Wolcott
• Software Cost Estimation with Cocomo II by Barry W. Boehm
• Estimating Software Costs by Capers Jones

Product Management

• The Product Manager's Handbook by Linda Gorchels
• Expert Product Management: Advanced Techniques, Tips and Strategies for Product Management & Product Marketing by Brian Lawley
• Managing Software Development from Idea to Product to Marketing to Sales by Dan Cond

Building a Successful Software Business

• Secrets of Software Success: Management Insights from 100 Software Firms Around the World by Cyriac R. Roeding
• Software Measurement: Establish - Extract - Evaluate - Execute by Christof Ebert and Reiner Dumke
• My Start-Up Life: What a (Very) Young CEO Learned on His Journey Through Silicon Valley by Ben Casnocha
• The Pharmaceutical Management Team: The Roles, Responsibilities, and Leadership Strategies of CEOs, CTOs, Marketing Executives, and HR Leaders by Aspatore Books Staff
• Working with the Board of Directors: Leading CEOs on Developing a Shared Vision, Establishing Expectations, and Leading Board Meetings by Aspatore Books Staff
• Software That Sells : A Practical Guide to Developing and Marketing Your Software Project by Edward Hasted
• Discovering Real Business Requirements for Software Project Success by Robin F. Goldsmith
• Leading Chief Technology Officers: CTOs from GE, Novell... by Aspatore Books Staff
• Creating a Strategic Technology Plan for Your Company: Leading CTOs and CIOs on Budgeting, Analyzing Financial Goals, and Developing a Companywide Vision by Aspatore Books Staff
• Building a Successful Software Business: Top CEOs on Software Product Management, Growth Strategies, Sales, & More by Aspatore Books Staff
• Best Practies for Executive Search Firms: Leading Executives on Developing Benchmarks, Evaluating Potential candidates, and Helping Clients Suceed by Aspatore Books Staff
• The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad by Michael A. Cusumano

Usability

• Usability Engineering by Jakob Nielsen
• The Design of Everyday Things by Donald A. Norman
• Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug
• Built for Use: Driving Profitability Through the User Experience by Karen Donoghue and Michael D Schrage
• The Essential Guide to User Interface Design by Wilbert O. Galitz
• Usability Engineering by Jakob Nielsen
• Human-Centered Software Engineering - Integrating Usability in the Software Development Lifecycle by Ahmed Seffah, Jan Gulliksen and Michel C. Desmarais
  

Localization

• A Practical Guide to Localization by Bert Esselink
• Developing International Software by
  
• Internationalization and Localization Using Microsoft .NET by Nick Symmonds

Human Resources Management

• Fundamentals of Human Resource Management by David A. DeCenzo and Stephen P. Robbins
• Human Resource Skills for the Project Manager: The Human Aspects of Project Management by Vijay K. Verma
• Human Resource Management in Construction Projects: Strategic and Operational Approaches by Marti Loosemore
• Next Generation Management Development by Robert D. Cecil and William J. Rothwell

System Architecture

• The Engineering Design of Systems: Models and Methods by Buede Dennis
• The Art of Systems Architecting by Maier Mark W. and Eberhardt Rechtin
• Systems Architecting: Creating and Building Complex Systems by Rechtin E
• Systems Architecting of Organizations: Why Eagles Can't Swim by Rechtin Eberhardt
• Product Design and Development by Ulrich, Karl and Stephen Eppinger

Windows Internal

• CLR Via C# by Jeffery Richter
• Advance Windows by Jeffery Richter

Quality Assurance

• Customer Oriented Software Quality Assurance by Frank P. Ginac
• Software Quality Assurance: Principles And Practice by Nina S. Godbole
• Software Quality Assurance: From Theory to Implementation by Daniel Galin
• Testing and Quality Assurance for Component-Based Software by Jerry Zeyu Gao
• Software Quality and Software Testing in Internet Times by Dirk Meyerhoff

The Art of Time Estimation

Time estimation is considered as a frustrated task. Personally, I tend to disagree. Time estimation is a very important task, one that the R&D Manager is often address to do. From my point of view, the frustration is based on wrong state of mind. I considered the time estimation as it is. As an estimation. I try my best to analyze the task(s) on hand and give estimations in range.
You have probably asked, at least once in the past, to give your most accurate estimation. While the combination of the words sounds like a joke the people who ask you this question are often dead serious. The only truth about time estimation is that you know that your estimation was right or wrong only when the task ends or very close to that stage.

There are many causes: requirements are not firm enough, managers and developer did not understand the requirements well, new technologies adoption, third party components integration etc.

I use the word ART in the post title to emphasis that time estimation is not a sheer science. Moreover, the word estimation is usually under estimate as well. CEO's understand that the Gantt is full of time estimations but, oddly, overtime, they is tends to forget all about it. Sadly, but it is true, that after the project is approved the R&D Manager actually sigend on a contract (the Gantt) and the clock start to tick.

Estimation in ranges
In order to avoid the time estimation to take as a promise the high level estimation should be defined as a range. For example 20-50 weeks is better than 30 weeks estimation. Estimating within a range also reflects the Risk Management and gives the right answer to poorly defined requirements (e.g. 20-180 weeks). The lowest figure represent all-went-well scenario while the highest represent the worst-case scenario. As the project progress this two figures should be converge (usually in the middle of the range). Another example is a Conceptual estimation (very high level), it should be look like this: 60-180. If it looks like this 104-124 then you need to re-estimate because estimation in this level can't looks too accurate.

Lately, new tools for project management address this requirement for range estimation: LiquidPlanner: http://www.liquidplanner.com/


Buffer Estimation
In his book, Rapid Development, Steve McConnell's writes about time estimations. Here is some of his insights:
"...your estimate could easily be out by a factor of 4. After you have firm requirements this reduces to a factor of 1.5. So even with totally fixed requirements (an unusual scenario) what you think will need 100 days of effort could require as much as 150 days but may only need 67."

The whole picture
One of the crucial error is to estimate without considering an overall factors. For example:
> Vacations, illnesses
> Integration
> Testing

Match the effort with the people in charged
An estimation of 3-5 weeks is right for developer A but wrong for developer B (2-4 or alternatively 4-7). You should refine the estimation in a way that considered the quality of the developers on hand.

Dependencies
Make sure you understand the relationships between tasks. Un-notice decency can disrupt plans.

1-2 days sub tasks
As opposed to high level estimation, detailed estimation requires well defined requirements. The project manager in this case should split each requirement to task and sub tasks. Some project managers define sub task in granularity of one to two days top. This tedious task is usually done by the team managers.

advantages:
> The time estimation is more accurate
> You get to know the status of the project on a daily basis
> You can raise red flags quickly and take measures sooner
> you build the self confidence of the team members
disadvantages:
> Can be considered as annoying Micro-Management
> Can be yield to a broken Gantt on daily basis. When one day sub-task in not completed it start to drags the entire task, at this point the developer may start to be frustrated
> Strong developer will be offended. They work great when they have flexibility. Beside some strong developers are quite bad in time estimation and usually finish their work before their own estimation.

From my experience their is no rule of thumb. People are different and should be manage accordingly. In cases where the 1-2 days sub task works both for the manager and the developer then OK.

What to choose: "Web-Application" or "Desktop-Application"? Rich-Internet-Application or a Smart-Client?

Introduction
The post deals with an important question, one that raises a lot of debate in the Software architecture world (I will consentrate in the .Net Framework).

What to choose: "Web-Application" or "Desktop-Application"? Rich-Internet-Application or a Smart-Client?

The reason why this question is asked so frequently recently, is that both technologies are getting closer and closer and when the distinctions becomes fuzzy the decision is harder to make. For example, Smart client introduces smart deployment and diminishes one of the biggest cons of Desktop-Application. With Ajax, Web-Applications run faster and with enhanced user experience.

Before we get started it is important to say right here and now that the define question above must always depends on the business problem.

It will be an obscene act for a developer or architect to choose a technology based on a whim. Technology should not be chosen on stuffy professionalism either. Many companies choose technology because this is what the current developer knows and good at. Choosing the right application type is crucial in many businesses. The end users and the business problem on hand, are the ones who should take the lead in the decision making.

This post does not deal with a certain business issue. It discusses the common pros and cons of each methodology.

The Dialog
I choose to face with this question in a dialog form. The Dialog is conduct between two software architectures.

Socrates: a Web-Application advocate and

Plato: a Desktop-Application advocate.

The dialog format allows me to not take a stand. In a matter of fact I don't have a stand. I think both technologies are great and when there is a need to choose one of them it should be according to the business problem.

You are most welcome to join to their (imaginary) debate held in modern Greece in one of the Tech-Ed .Net seminars.


Socrates:
… But Plato, your claim about the needs for constant software upgrades only strengthens my argument that Web-Applications are the best technology. In a Web-Application the application is actually located on a remote server which you can upgrade when ever it's needed and it reflects to your users online. In other words, when all the code is in one place everyone sees the latest release.

Plato:
Well, with ClickOnce technology a Windows-Form-Application can be deployed and launch from the Web. With this type of technology software upgrades have never been easier to maintain.

Socrates:
Oh, I heard about what it is capable of, but isn't it too cumbersome to accomplish? You do need to make all the assemblies strongly named and the amount of folders and files it creates on the web server is quite…well… cumbersome. Moreover, who wants to install a Desktop-Application on his hard drive if he does not have to?

Plato:
Well, I guess this technology will be improved by the Redmond fox in the future. Right now, the user can choose between offline and online executions. In both modes the application is installed on the machine. The difference is that in offline mode the application can be jump started and get updated from the desktop while in online mode it can be run only from the web link as before. Please also know that ClickOnce is not the only solution. A "home made" solution like using a Web-Service that the Desktop-Application communicates with, checks and install updates are easy to develop.

Socrates:
So you are basically saying that in online mode, which is closest to running a Web-Application, the application is reinstalled again and again in each run. What if it is a big application in term of Mega bytes? Well, my dear Plato I rest my case.

Plato:
No, you haven't, because there is some kind of caching mechanism that improves this behavior. I guess, the .Net Framework only downloads the required files.

Socrates:
Hmmm…, .NET Framework you said. Well do I smell a software perquisite in the air?

Plato:
You do smell well, but do understand that the user must not have the .NET framework on his computer or must preinstall it manually. The deployed ClickOnce application can be easily defined to support the installation of the .NET Framework (bootstrapper). Dear Socrates, as you well know Web-Applications commonly require ActiveX installations? Those requirements often scare users because they are commonly causing the web browsers to display intimidating security.






Socrates:
Well, you are right; today's web browsers do make us lots of headaches. But, Windows firewalls often do the same for Desktop-Applications.

Plato:
In Desktop-Applications as opposed to web-browser the application has rights that are granted from the logon user. It can access system data like IP Address, Registry, Files, Windows Shell integration etc. In a script mode the Web-Application is very limited and the ActiveX technology is one of the last resorts. Web-Applications cannot leverage local resources like CPU or installed software either. Moreover, isn't true that ActiveX is also being used in Web-Applications to enhance graphic capabilities like Charts, Maps etc.

Socrates:
Well, it depends on what the Web-Application is obligated to do. But, yes it is often use for more complex and some kind of fancier UI controls.

Plato:
I guess you will also agree that Web-Application will never be capable to support GUI and visualization functionalities like Desktop-Application. For example, the user interface must travel back and forward across the web in order to be refreshed.

Socrates:
I wouldn't say always. AJAX, for example enhances the UI capabilities.

Plato:
AJAX also added tons of client-side script code and that hurts performance and harms the user experience. With AJAX, Web-Applications stop being a thin application and start to get fat. Speaking of scripts, isn't true that debugging capabilities of client and server side scripts languages like VB and Java script are impossible. Isn't also true that developing in this kind of script language is klutzy?

Socrates:
With today's ASP.NET technology, server code (code behind) can be written in a high level language (any .NET aware language) that can be of course debugged. As for client and server side scripts I am afraid you are right.

Plato, with you permission I would like to talk about application availability. As you recall, in Web-Application the application is available and can be access from anywhere without installing anything on the client machine. For example, Gmail is a web-based Email application. You can enter to your Inbox no matter where you are. In case, you are entering an Internet-Café you surly be permitted to enter to Gmail but not to install any application on the machine.






Plato:
Yes, I see your point. But what if I am in my home or at the office and I want to see my Emails but the Gmail server is down or I have temporarily lost my Internet connection. I will not be able to see my Emails right? Web-Application must be connected to the server all the time. In other words Desktop-Applications offer better offline and caching capabilities. There is no need to waste time waiting for screens to refresh or networks to become available





As opposed to:




Socrates:
Well, if you need smart caching and offline capabilities you are right. Another thing that I would like to mention is a cross-platform capability. If your Desktop-Application is targeting to a world wide use will you be able to install it on Linux and on Windows OS. Even if you have decided to support only Windows OS family you will still need to support and test your application on lots of versions like: 98/ME/NT/2000/2003/XP/Vista.

Not including sub versions like Home and professional editions. You will soon notice that the above OS supports different APIs and acts differently. In case of a Web-Application you are running within a well tested application (like IE) that was already tested on those OS. Web Browsers are also committed to standards like HTML and Java scripts interpretation. Therefore, as long as you stick to standards you will have no problems.

Plato:
At the beginning, you have almost convinced me, but then I have figured there are a lot of web browsers vendors and lots of web browser versions. Also there are a lot of technologist like ActiveX and Flash that will not work on Mac web browsers. Nevertheless, you are right if the Web-Application is simply enough will be easier to support world wide users.

Socrates:
Well, working with a markup language like HTML also holds lots of simplicity and flexibility capabilities.

Plato:
It is true! But at the same time it is also very limited. With XAML markup language, Desktop-Applications also enjoy the flexibility like HTML plus much more enhanced UI capabilities.

Socrates:
OK, Plato we are not even close to end this debate, but I do need to go. I have a meeting with Xenophon at the local SPA.

Plato:
Adio! Socrates. Send my regards.



What does the future hold?
It is hard to say what to future holds. One should be a profit to tell. My guess is that we are going to face with the article question for a long time, at least for the near future.

Looking at brand new developing styles like SmartClient and AJAX, makes you think that no new revolutionary progress have been made in the last years.

"…AJAX is not a new programming language, but a new way to use existing standards." (http://www.w3schools.com/ajax/default.asp)

"…Smart client isn't a technology, and it isn't any specific architecture. It is a style of application that combines the best of both Desktop-Applications and Web-Applications." (http://msdn.microsoft.com/smartclient/community/scfaq/default.aspx)

Some of the common use technologies are really very old:

>ActiveX in 1990 (http://en.wikipedia.org/wiki/ActiveX)
>VB – 1991 (http://www.startvbdotnet.com/dotnet/vb.aspx)
>MFC -1992
>In 1994 the very earlier version of HTML was introduced (http://www.w3.org/MarkUp/historical).
>JavaScript in 1995 (http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html)
>Flash - In 1996


Smart-Client vs. Rich-Internet-Application (RIA)"Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e. maintaining the state of the program, the data etc) back on the application server. (http://en.wikipedia.org/wiki/Rich_Internet_application)

Rich Internet Applications are already here. Google is one of the world leaders in Rich-Internet-Application. Here are some of examples: Gmail, Google Calendar and Google Docs and Spreadsheets.

Hiring employees: The interview

Hiring good people is a supreme task and no one is free from making mistakes.
One of my CEO told me once that approximately 20% of the recruits turn out as a mistake. 1 out of 5 people, it is quite a lot.
Making the right choices is extremely hard because there is no magic formula and maybe it will never be because the "problem" is multi dimensional.
Nevertheless, there are some insights that can help you hire better. In this post I am concentrating in the face to face interviewing process (personally, I think phone pre-interviewing is a waste of time). Some of the "Interviewing-Tips" are from my own experience while others are success stories I have heard from colleagues and manager during the years.It is important to note that the interviewing "Interviewing-Tips" may not be applied as is because it depends on context.


Matching and Competency
Prior to the interview make sure you know what kind of qualities you are looking for in the interviewee. You cannot have one standard. You do not want a brilliant, fast learning and fast employee to do a tedious job. You may recruit him but he will soon ask replace the job in or out of the company.
A CTO that I have worked with told me a story about his first employer a very eccentric manager that was looking to hire people that have strong self confidence, have the ability to separate the important thing from the insipid and to get the job done.
His MO was as followed:
When an interviewee came to the office he was turn by the secretary to the manager office.
When he entered, the manager was looking busy reading stuff, then with his head looking on the desk he just pick up his hand, holding few papers, and ask the interviewee to photo copy the papers twice. The manager added that the Xerox in the fifth floor is broken and that the one in the sixth floor can be use. Eventually, he signed, the interviewee with his hand to leave the room.
Not knowing that they are actually being tested, most of the interviewees where quite in shock. Another surprise was waiting for the candidates that were regaining their composure – there were no photocopier machine in the sixth floor because the building was only five stories.

There was only one way to progress in the job quest and that is to get to job done and bring the papers photo copied twice.
All the successful interviewees copied the papers in the shop outside the office building. Some of them ask the secretary or one of the employees but all came back with the copied paper.
The talk about manager was indeed eccentric but the employees he recruits were a success story. The moral of the story is that even if the technique might be odd, if it serves the needs of recruiting a component employees then it ok.

Confirmation, confutation and confrontation
Starting an interview in a calm and inviting atmosphere is very important, but this does not mean that the rest of the interview needs to be the same. Asking only pleasant questions is not a good practice. Sometimes shaking the interviewee may lead to situation where his true personality is discovered. No matter how badly you want to recruit you should consider each candidate as not the right one. You should dig to find out why he is right. With this kind of negative approach you learn much more about the candidate and get a strong impression how he deals with difficulties and how badly he or she wants the job.
Ask questions like:
>Why do you think you are the appropriate person for the job? Give examples from what you did in the past.
>Do you even know what the job is? If yes, tell me; If not then why do you think you are qualified for a job that you don’t really know about.


Compatibility through Practicability, ability and capability
In my career I have encountered interviewer that was so egger in some point to hire me that the interview was just too easy. It was great for me but it seems back then like it was very superficial. In some cases interviewer ask a question (mumbling) in give them self answers to at the end of each question.
The only way to increase the probability of hiring good employee is to make sure that you are getting the most reliable information from the candidate.
Make sure you search for the employee compatibility to the job not by asking do you know to do X? Or do you have experience with Y? Those are close questions that answer for them is Yes or No. You don’t learn from this type of answers anything.
Ask questions like:
> Can you please describe a case where you were practicing X? Add difficulties you have encountered with? How did you face with them?

You must make sure that the interviewee has the capability to do the job. Even if he does not have practical experience you can learn how he deals with problem, if he resourceful or not etc.


Recommenders
In some countries the recommenders is the most valuable tool to decide if to hire someone. A rule of thumb is that you should use this tool but not in the normal way. That is not to call, only to the recommender in the list but also to someone else in the company. For example, if the candidate list his team leader, ask him the permission to call also the manager of his team manager or alternatively to the R&D Manager or CTO.
In this mode of operation you eliminate the chance that the listed recommender is biased.
When talking with a recommender always makes sure he or she has the time to talk with you. Try to check with the recommender information that the interviewee told you. Do not search for positives qualities but for the negative ones. Prepare to get disappointment.
In some cases the interviewer likes the interviewee and therefore not asking hard questions. This is a mistake.
Ask questions like:
> Would you recruit the person again in the future? If yes why? If not why?
> Can you tell about mishaps that the employee was involved with?
> Does, from your point of view, the employee can fit into the position on hand? If yes why? If not why?
> What are the employee most significant weaknesses?

Good luck!!