The Software Manager

Leadership and Leading-Sheep

2011-02-27T20:48:00.000+02:00

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

2011-01-03T21:13:00.000+02:00

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?

2010-12-21T08:47:00.001+02:00

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

2010-12-21T08:46:00.001+02:00

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)

2008-08-05T07:51:00.003+03:00

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

2008-06-19T14:12:00.004+03:00

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

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

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

2008-06-19T01:10:00.003+03:00

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?

2008-06-19T00:38:00.006+03:00

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

2008-05-27T11:01:00.001+03:00

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

2008-05-13T08:55:00.071+03:00

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:

CEO domain and expectations from the R&D Manager

2008-04-08T19:44:00.004+03:00

In this post I mention some of the main CEO position characteristics. I do that while reflecting to the R&D manager and his relationship with the CEO.
Like in other relationships it is a good practice to put yourself in other person shoes. This practice make you understand the counterpart better and gain much better communication with him.

The CEO and R&D manager relationship and communication is very important for both parties.

From my point of view the CEO search in his managers, including the R&D manager, similar abilities and characteristics that allow him to better communicate with them and to assure his and the company success. Therefore the R&D manager should meet with this expectation, some of them on subconscious level. A good starting point is to understand what it means to be a CEO and what does his CEO is looking for in his key point managers.

Usually, people tend to expect from others the very same behavior as they expect from themselves.

A desire/passion/hunger in the eyes
The CEO as the ship captain expects, from his R&D manager, no less than a passion to meet with the company goals. No great captain will ever succeed to accomplish the sail by himself. There is, simply, to many things to operate. The R&D manager is one of the important agents to delegate the CEO vision to each and every R&D member.
Steve Milovich, chief people officer for Walker Digital West: “Passion is putting your mission in your heart not on your wall. It’s moving it off the sheet of paper into your inside.”

Constant running
The CEO position is not a 100 meter running course. It is a marathon.
The CEO never rest on one's laurels. He faces constant hurdles and he needs key holder employees to run with him for long period of time. Among others the R&D manager manages the entire products development and therefore should be committed to long period roadmaps and deliveries.
The Greek tycoon, Aristotle Onassis said about the CEO position: “…You’re just guaranteed the ability to afford good running shoes
for the rest of your life…”

Trust
The CEO have to trust the R&D manager. He is the person who delivers or not. He is the one who is committed to roadmaps and a key partner of the strategic and technical architecture. The CEO takes risks and risks are easier to take when you have copartners.

A role model – on crisis
The CEO has to act as a role model. The standards of which the CEO operates upon needs to be observed by his managers and beyond. The CEO is in the spotlight all time but one of the real tests is in crisis time. As for himself the CEO expect from his R&D manager to make an example. For an instance, If R&D members stay overtime due to a crisis the R&D manager should stay with them.
You should show your concern and compassion. You should boost you people moral, comfort the wives and show your gratitude.
The CEO usually cannot fix the problem directly and most likely doesn’t even have the technical knowledge to know what needs to be done. He trusts his R&D manager to orchestrate the whole thing. That includes taking hard decisions and work through the crisis. The R&D manager has to be in front when things get dirty.

A role model – day to day
As a manager you are being looked at. You must not, by all means, caught as an arrogant. You need to look at your people eyes. You need them to know that their opinion counts. Don’t patronize do not embarrass others. When you say bad thing about others people will suspect, and they are right, that you do the same against them when they are not in the room.

10,000 feet high perspective
The CEO can’t be involved with the details. He, simply, can’t grasp all the information. In some cases the R&D manager can‎‘t have this luxury either. What the R&D manager is expected to do is to constantly improve processes. For that matter the R&D manager have to have high level perspective and the ability to see beyond the day to day issues for the sake of the project(s).
For example when a crisis is over usually everyone continue with their mainstream tasks but it is the R&D manager job to do the follow up, assess the damages and to draw conclusions. In general, to make sure you investigate the problem and learn the lessons for the future.
In term of communication the CEO expect from the R&D manger to converse with him in high level and only when he wants details he will ask for them. The CEO is required to generate clear and not complicated picture to his chairman or and to the board of directors.

QoS and LoS

2008-03-28T00:14:00.003+02:00

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

2008-03-18T11:49:00.012+02:00

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

2008-02-27T11:39:00.020+02:00

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

Firing an employee

2008-02-22T23:30:00.010+02:00

One of the unpleasant part of holding a managing position is that occasionally it is requires to dismiss an employee.
What makes the decision hard is that people are getting hurt from it. By saying people I mean the fired employee, of course, the surrounding colleges and the manager himself.
Firing an employee is not the same for all cases. Firing an employee that harm the company directly by specific actions like stealing and not showing to the office is easier than firing an employee that try hard but lack of capabilities.
In this post I am sharing from my unpleasant events of firing employees and give tips of how it should done in my point of view.

Firing buildup
Let the employee, as much as possible, know that you are not satisfied from his performance. Everybody should receive the opportunity to improve. Ask him to improve and build a specific improvement tasks over a specific period of time where he will need to display positive changes. As a manager you have to talk with your worker about your expectations from them. In most cases people like to succeed in their job and are willing to improve.
The improvement plan memo should include:

Problem description.

Corrective actions to eliminate the problem.

The time frame in which this is to be accomplished.

Make sure to address the subject in a positive way. You want the employee to change, meaning you have to make him participate in this process and to be committed to it. Do not criticise and rest. Let him to know why you invite him for this talk, tell him what you want him to improve and embed his positive behaviours within the conversation. In most cases people tend to close their ears when they start to hear criticism. Most of them do not realize that the manager is trying to change their behaviour and that he is even bother because he like the employee to stay in the company and do better. No manager wants to fire people for the sake of firing only.
The improvement plan should be a companion with specific deadline on which the manger will evaluate the progress of the employee. The product of this meeting with the employee must be an Email that define the plan. Personally I prefer to ask the employee to write it. In this way I am sure that he understand what he need to do.
Update you manager about the plan and the conversation.
This procedure will be useful in the future where and if you will decide to fire the employee. The employee know that you are not satisfied with his job and your manager are informed. In this way the firing will not be out of the bloom and it will be more easily for the employee to understand it.

Timing
When to notify to the employee? The best time will be at the beginning of the week after lunch and closer to the end of the day. Firing notice is a very unpleasant moment. You should be sensitive. Doing it closer to the end of the day allows the employee to go home right after the notice. Some people take it very personally and cry. Given that fact they might want to finish the day and go home to their families. Some managers prefer not to notice at the end of the week because it will ruin the person weekend with his love ones, other manager think just the opposite, that firing before the weekend give the employee the time to relax and think about the all thing.
The most important thing about timing is not to hesitate to fire once it has been decided. The worst thing is that the employee that is about to get fired heard about it indirectly. You have to give the fired person at least the courtesy of letting him to know first.

Location
By all means not in the employee room. A conference or the manager room is a good choice.

The notice itself (Exit interview)
Before the notice itself you got to make sure you are familiar with the company policy about firring people. Be very practical. Do not start with small talk. Say that you have some unpleasant news to deliver. Do not put the decision on someone else. Take the responsibility on you and only you. Start with telling the employee that sadly the company will stop hiring him. Do not apologize do not make excuses. Make sure the employee understand that the decision is final. Let the employee ask you questions but do not be drawn into an argument. Be very corrective in your answers. Prepare to be asked about salary and compensations money. At the end of the conversation suggest help in finding new job. Let him know that you are still there for him for any other questions. In some companies the employee is contract to stay for one month after the notice. Let the fired employee to know what you expect from him. In my point of view, in most cases you can dismiss the employee right away. I prefer to let the employee to go home but save the right to call him if needed within the notice period.

Make sure you document the notice meeting itself.

Tell the unfortunate news to others
Some manager (depends on company culture) prefer to avoid the rumors about the firing and tell everyone about it instantly. Some do it in an Email, some call the group and announce it. Personally I think that it is a good practice to share the office about it because everyone will know about it sooner or later. I also think that the manager should consult with the fired employee about how to do it. In my experience some employees like to keep it quietly until the date of the termination arrives. Some ask to tell the others by themselves. either way you need to make sure not to drag it too long or too quietly because you might create a situation where an employee just vanished like in Russian KGB. Let the others know why and give them a chance to express their concerns.
Lastly, make sure not to spread rumors about the fired employee and let everyone to know that you appreciate what he or she done for the team/department and the company. Say kind words but do not praise.

Reference and recommendations
In some cases where the employee was fired due to bad performance it is a little bit harder to give recommendations. As a manager you should want to keep taking care of the employee but you should also avoid lying. Tell the employee that you are willing to write a recommendation paper or to talk with an employer but you are not going to make excuses. The best you can promise is not to supply actively negative information but if you come to point where an employer ask about performance you should tell him the truth. I prefer to ask the employee how he think the reasons can be soften. As a manager you should know that en employer can be angry with you if he was misjudge because of you and you probably don't want to make people in the industry angry with you because of an employee that did not meet with you expectations.

Watch out
Some manager are so reluctant from firing someone that they arrive unprepared to the event. Firing people is harsh but it is part of the manager job. You should try to foresee the response you get from firing someone. Although it is very hard to difficult to predict and in time you might learn but avoiding from surprises is always the better practice.
Few terminated employees will agree that their performance hasn't met company standards; some will become angry and a few will become belligerent.Be sure you have documented all the alerts you gave to the employee. The documentation should include dates of warnings and description of the degrading performance over a specified time. It should also include the assistance you try to give to the employee to improve his ways. Send those memos to your manager and of course to the employee. Make sure you write a dated paper of termination. Give it to the employee and sign him if necessary.
How you handle a firing might have a tremendous impact on how the employee feels about himself, you, and your company.Moreover a poorly handled firing will have a negative impact on morale throughout your entire organization.

Last but not least
While firing should definitely be a last-resort measure it is sometimes necessary to do it as soon as possible. Keeping bad a performer have a negative impact on the moral of others. Firing the person who harms the group is something the group expect from there manager.
Your best interest is to end the contract smoothly. You don't want an employee that spread false rumors out side. Fired person should receive all of he is entitled of by law and sometimes even more. For that matter on the notice stage suggest that maybe the problem was not with the employee skills but with his match to the position.
Firing someone should be a process unless the company is bankruptcy. Through all the process you should be firm but human. Most of the people I have decided to fire till now stay in contact with me. One of them invite me later to there wedding , other to her recital with one of them I talk almost every week. This mean that even when you come to the point that you are firing someone you can still do it humanely. Value the employee. Place yourself in the employee’s position. Be respectful and tactful.

The Art of Time Estimation

2008-02-12T00:00:00.000+02:00

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?

2008-02-08T22:37:00.000+02:00

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

2008-02-06T11:29:00.000+02:00

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!!

FAQ, Knowledge-Base and Troubleshoot

2008-02-04T22:45:00.000+02:00

This post deals with a comparision of FAQ, Knowledge-Base and Troubleshoot (Content, Format and Audiance)

Leadership and Leading-Sheep

2008-01-26T15:08:00.001+02:00

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.

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.

Meeting Management

2008-01-04T00:22:00.000+02:00

Meeting can be very productive. They can also be a waste of time. Here are some tips for conducting a successful meeting.

Purpose:
If you can not define a decent a purpose your meeting is hanging by a thread. The purpose should be one to two clear sentences. For example:
"This meeting is to decide which bug tracking software to choose."
The purpose serves as a measurement tool that helps you and the rest of the participants to declare whether the meeting was successful or not. Start the meeting with a statement of the overall outcome that you want from the meeting.

Agenda:The agenda is a list the items you are going to discuss. The agenda should have strong correlation with the purpose on hand. Define duration of time on which you plan to discuss each item or else you will be out of time. For example:
"1. What are our Bug Tracking software requirements?"
"2. What are the workflows (Bug life cycle)?"
"3.Demo of X and Y"

Timeframe:
The meeting duration should strongly correlates with the agenda. The timeframe and the agenda helps you stay focused. Start the meeting on time (see more below) and end it on time, even if you haven't finished it all. This is two sides of the same coin. Do not let late arrivals to spend your and others time, but also do not steal people time at the end of the meeting.

Assign organizer:
The meeting has at least one purpose and two persons at the least. Someone has to write notes and minutes, otherwise it will be in vain. The minutes should record who attended, what was discussed, any agreements that were reached, and any action items that were assigned. Soon after the meeting, usually within 24 hours, the minutes of the meeting should be distributed to all who attended, any invitees who did not attend, and anyone else effected by the discussion. Email is a great vehicle for distributing them. Distributing the minutes informs those not at the meeting of the progress that was made and reminds everyone of their action items.

Selecting Participants:
Make sure you invite only the relevant persons. Ask for preparation if required. The decision about who is to attend depends on what you want to accomplish in the meeting. Do not depend on your on judgment only, ask the participants you choose if there are other persons who might contribute.

Notice:
At least one day (unless it's an emergency meeting). If you ask people to get prepare to the meeting you should give them time to do so. If you had to cancel the meeting, do it as early as possible and apologize to the participants. Make them know if this is a cancellation or rescheduling.

Location:
Make sure you booked the conference room. Make sure that you write where the meeting is held. Try not to schedule the meeting right after another meeting in the same conference room, from time to time meeting cross the timeframe and you do not want your participants and you to wait outside the door.

Material:
Send all the required material. Ask participates to read it. Ask them to think about issues before the meetings (although people hardly do so.

Start meeting on time:
Don't wait for slow arrivals. Keep everyone know that your time is not spendable. Do not review what you have already covered. It will be unfair on behalf of those who come on time and bad example too. You should respect them. Do not try to educate the late arrivals but if one of them asks question or remark during the meeting, one that you have answered at the beginning of the meeting, tell him politely that he was late to the meeting and you already covered the issue. In case of dispute, keep the blame on you, say that you have more meetings and had to start on time. Hopefully, people will stop coming late after few episodes like this.

Opening Meetings
Welcome attendees and thank them for their time. Review the agenda at the beginning – make it short and laconic. Give participants a chance to understand all proposed major topics. Small talk can be allowed at this point only. It create nice atmosphere.

Disturbances:
Do not allow participants to be occupied with other stuff other the meeting. In case someone play with his laptop or cellular phone, politely, tell him to stay focused if he does not comply, tell him that you are appreciate his participants and most wanted him to listen. In case the behavior continues ask him to leave the meeting.

Show an example:
The most important thing is to show an example. If you come late to meetings, if you do not come to your on time, if you deals with other stuff during the meeting do not expect for others to behave differently.

Cup of coffee meetings

2008-01-03T23:15:00.000+02:00

Taking your employee to drink coffee gives you an opportunity to sit with him in a pleasant environment outside the office walls. Foremost, your employee is flatter from the fact that you have bother taking a break with him with your busy schedule. It generates a sense of impotency and significant.

The very reason the meeting is taking place in a coffee house does not mean that it is not a management tool. It is a great opportunity to learn important information about your employees both in personal and work level.

The meeting should hardly ever be interrupted; you are not in the office so close your cellular phone too. The whole point is to get away from the distractions for a little while.

Usually you sit with your employees in your room. It is your home base, your natural place where your employees does not necessarily feel open. The coffee shop is a place of good atmosphere a neutral place that can create an open conversation mainly on your employee part.

Do your best to listen instead of talking. However, be all means, do not interview the employee. Ask open questions; let him talk about him self, get to know him better. From time to time ask some questions about the work but mostly be there to listen. In specific, you should be an active listener. Get interesting about what they are saying and do not let your mind wander.

The cup of coffee meeting should be with your key employees (your champions) and it should take place now and then. Caution, at the first time the employee might get nervous about the fact you schedule to meet him all together. Do not create agenda but do tell him that your intentions.

What are the expectations from R&D Manager?

2007-12-24T22:07:00.019+02:00

1. To have a knowledge of and commitment to the business/company strategy.

-To combine and adjust the business architecture/strategy with

the technological one.

- To be able to speak in business jargon.

2. To focus on the customers/users.

3. Clear understanding of business and technological processes.

- Great knowledge in new technologic and the ability to harness

them for the sake of efficiency and selling factors.

4. To be a Leader of People.

- The ability to motivate and aspire.

- Creating a task force atmosphere and group commitment to success.

5. To practice the 80/20 law, almost, on a daily basis.

6. To be a Leader of Technology.

7. To innovate and to lead innovation processes (an agent of changes).

8. To constantly improve processes effciency.

9. To Release a Quality product on time and within budget .

10. To grasp the all picture (from 10,000 feet).

11. To have a strong professional and ethical integrity.

Yes, it is a lot to ask from one person, and this is the very reason why the R&D Manager need to build a team of people that work as a group together to accomplish the task of moving the giant mountain called R&D.

The characteristics of a good R&D Manager:

Decision making: The R&D Manager takes tens of decision on a daily basis. Significant amount of decisions are made in the present of R&D members. The people you manager wants to know that you are capable to decide within timely fashion. As an R&D manager you won't have the luxury of sitting on the fence for very long. Your staff looks to you for yes, no, left, and right decisions, otherwise you are giving the signal that you are not really in control. In this situation your staff will feel out of control too. Think in a practical way. Ask your self questions like: do we really need this? What will be the benefit?

Time, Task and Risk management: Think in a practical way; think about the result; about the outcome. Ask your self questions like: do we really need this? What will be the benefit? Plan: Any plan is better than no plan, since no plan doesn't lead anywhere. Constantly monitors progress for the duration of the project. Delegating: sharing tasks and authority with your team. Allocate the right task to the right people. Think about the risks and threats. Try to identifying the problems before they flack in your face. Investigate mishaps and mistake and correct them constructively, do not look for someone to blame. The R&D Manager is not a one man show he is the conductor of the orchestra. Concentrate on your champions they are the one who will help you to move the mountain. Embrace a developing life cycle that helps to manufacture products/releases in short intervals. In this way the project stay relevant and adjustable for market needs. Interact with the customers as much as you can.

Leader of technology: Good knowledge of the product context. Become an authority so employees can feel free to ask you questions. Be a professional, understand where does the company is going and practice and implement the vision into day to day work. Understand the business the competitors and customers. Without lowering the importance of the rest of the characteristics the only way to create real differentiation from the competitors and to be relevant to the market is through deep knowledge of the technology on hand.

Honesty and self integrity: Be humble. Think about your worker. Not a long time ago you where a simple worker too. Remember what your expectations from your managers were. Think about giving before you request for yourself. Be an example – work hard. Shows that you are really care. Seek for the opportunities to give compliment for a hard and good work done by others; even if you are the one who was deeply involved. Give credit is the best way to receive one in the future. Flexibility: The ability to bend but not break. The R&D Manager interacts with significant amount of employees within and outside the R&D department. He had to have the ability to observe criticism, bad behavior and unpleasant decisions that he doesn't agree with. The ability to see the big picture and to move on when needed is very important. When mishap happen do not look for someone to blame take responsibility and move on.

A people person – Leader of people: Listen, Listen and Listen. Direct and guide. Learn to see thing in your staff eyes. Think about their career development. No one can move the mountain by himself it can only be done with the help of group of people that do so in coordination. Make sure that every single one of your staff know the roadmap and understand where the company is going. Avoid pressure and maintain a routine where people don't work to easy and not to hard either. Encourage your staff to criticize and to put everything on the table.

Constant innovator: Think out of the box. Think about new features that creates real differentiation from competitor products. Improve workflows. Create a brainstorms team force.

Customers Always Wants Stuff Tomorrow

2007-12-19T22:48:00.001+02:00

Customers want the stuff tomorrow because they need it ASAP for their business.

One can’t blame the customer urgency.

Accept for the work they cause a real customer is fantastic for the R&D Manager.
The entire R&D department work better for features that a certain customer requested.
R&D people tends to work better if they have a context. For example: "We need to design and develop a feature for important customer named ccc...". The R&D manager then need to give information about the talk about customer, why it is important for the company and then to talk about the crucial feature that it is required ASAP.
At that point all the involved R&D members knows the big picture. They are involved and more committed for the task.
Moreover, Software Engineer love to work on a feature that they are sure that someone wants and going to use. Finish the task on time grant a sense of accomplishments. In this kind of atmosphere it is much more easy to make employees agreed with harsh deadlines and keep customers happy.

Note: Saying the above, does not mean that the R&D department must handle any customer request and in any deadline. It is a management decision what to do, when to do it and which tasks is getting out in order to let the new one get in.