Saturday, September 11, 2010

Why it is difficult to run the last mile?


I was running the half marathon last month; my third thus far, and as I advanced towards the finish line, a certain realization struck me. On all the three occasions, I had always found it difficult to run the last mile.
My marathon experience has raised some serious questions- It is not that I can’t run long distances, in fact the thrill, the pace, and most importantly the gratification of running for a purpose has always propelled me to participate. But irrespective of the distance, running the last mile has always been formidable, uncomfortable.
Is finishing a job always this difficult? And if yes, does it have to do with the expectation of outcomes? Or is it that we are too exhausted and stressed towards the end that we tend to lose focus and our sense of purpose.
As I as struggle to find answers, I will reason and ponder on each point separately and apply it to the marathon analogy.  Let me first talk about expectations of outcome. Assuming that I have already run twelve out of the thirteen miles that will lead me to the finish line, this is when I tend to become distracted. I start thinking about the post run events and it diverts my mind from the current race to future events, this in turn generates desperation of finishing the race, anyhow.
When I apply this analogy to a project situation, I realize that during the last phase of the project our focus seems to dissipate, we are low on accountability, prioritize lesser, and tend to slacken our hold because the goal appears closer. We start talking and thinking about upcoming projects, and enquiring about possible future opportunities. This diverts our attention from the current project and when we get distracted, even for a moment; it takes several minutes to regain our focus. Distractions, large or small, kill productivity and the main task i.e. the completion of the WHOLE project is hampered.
Towards the end, we sometimes feel less energetic and stressed out and when the situation demands our utmost focus and control, we seem lost.  I would probably attribute this to burning out caused by excessive stress and pressure conditions during the various phases of the project cycle. We expend energy too much too soon and feel rather snowed under as the end approaches.
In a project scenario we work overtime to control the schedules, avoid taking any leaves despite the fact that they actually help us reenergise, and fail to develop clear boundaries between work and personal life. As a result, when we reach completion, we feel enervated and helpless to handle stress and it becomes difficult to proceed with the same speed.
I think for successfully finishing a long race in a given timeframe we need to control both these factors, we need to spend our energy carefully and focus on the present rather than dreaming about future.

Sunday, July 25, 2010

Become a Generalizing Specialist or T-Shaped

A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both his or her existing specialties and other areas. A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few.

A generalizing specialist does one kind of job very well and some other jobs adequately. With generalizing specialists your teams enjoy the benefits of high productivity, while lowering the risk of bottlenecks, and retaining flexibility. There is another similar concept called T-shaped people:

We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T -- they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. - Tim Brown, “Strategy by Design”

There are many benefits of having T-Shaped people in team

  • Better communication even with less documentation, if someone has an enthusiasm or curiosity about many different subjects and disciplines, then they can be more flexible, more empathetic, and more engaged with the world
  • Better bottlenecks management, as T-shaped person can do other jobs adequately, he can contribute in other jobs if required.
  • Better solution of the problem , If the only tool you have is a hammer, you tend to see every problem as a nail. ~ Abraham Maslow , The T-shaped person can explore the problem from many different perspectives and that helps in driving better solutions.

How to become T-Shaped person? You need to find your own answer, some suggestions

  • Reading is a good method: There are some great books and Web-based resources available; you need only to invest time to take advantage of them, follow some good blog, one need to read more than just technical publications.
  • Participate in community activities, thanks to internet and many popular social media sites ,its easy to participate in online and face to face community activities , join some good groups 
  • Do some experimental projects in your non core areas, say if you are C# expert, try to make something on python.
  • Share your knowledge , if you do this other will also follow and that will help you in acquiring new skills
  • Find a mentor for a target skill, mentor could be junior to you…but he has to be expert in the skill you want to acquire  

Saturday, July 17, 2010

Avoid making people Indispensable


Every individual in a team has a important role to play, but in the interest of individual, project and organization, leaders should not allow people to become indispensable. Lots of career articles have been written about “How to make yourself Indispensable..” the tips like doing more than expectation is essential for professional growth but it should not let person become indispensable. The important part is we should motivate people to become more knowledgeable, productive, friendly and professional but not indispensable.

Indispensability can create issues like 

  • Poor Team Productivity , the person become too busy and as a result there may be many tasks kept waiting ,and because of his queue other may not be able to start their activities
  • Create Risk for project timeline, if the person is not available because of any reason it puts project timelines on risk
  • Monotonous work, as he can only do some of the work, people keep coming to him only for the same work.

Some of the measures Project team can take to avoid Indispensability
  • Continuous knowledge sharing, team should create environment of knowledge sharing. 
  • Task rotation, we should keep rotating people between modules, so there should be more than one developer who codes for one use case.
  • Educate team to become more professional, the growth in career happens by sharing knowledge not by keeping secrets.
  • Put process in place, process like one codes and other does the review, one codes and other fixes the bug, peer programming and group design can institutionalize the knowledge sharing. 

Sunday, June 13, 2010

Murphy's Laws of Project Tracking

  1. Projects progress quickly to a 90 percent completion factor, and then stay at 90 percent forever.
  2. When things are going well, something goes wrong.
  3. If the content of the project changes often, the rate of change will always overtake the rate of progress.
  4. A poorly planned project will take three times longer to complete than expected; a well-planned project only takes twice as long to complete.
  5. Members of the project team will ignore your progress reports because the reports portray the limited progress that has been made.
  6. When you know you've thought of everything, you haven't.

Sunday, April 25, 2010

Classic Mistakes in Software Projects

I am Reading “Rapid Development: Taming Wild Software Schedules”, this book talks about Four Dimensions of Development Speed
  • People
  • Process
  • Product
  • Technology
It talks about classical mistakes ; here i have list out mistakes from book and some from my own experience, do add to it..we need to learn from others mistakes

People Related Mistakes

1.   Undermined motivation
2.   Weak personnel
3.   Uncontrolled problem employees
4.   Heroics
5.   Adding people to a late project
6.   Noisy, crowded offices
7.   Friction between developers and customers
8.   Unrealistic expectations
9.   Lack of effective project sponsorship
10.  Lack of stakeholder buy-in
11.  Lack of user input
12.  Politics placed over substance
13.  Wishful thinking
14.  Lack of team sprit
15.  Communication gap , No knowledge sharing
16.  Lack of Assertive communication

Process Related Mistakes

17.  Overly optimistic schedules
18.  Insufficient risk management
19.  Contractor failure
20.  Insufficient planning
21.  Abandonment of planning under pressure
22.  Wasted time during the fuzzy front end
23.  Shortchanged upstream activities
24.  Inadequate design
25.  Shortchanged quality assurance
26.  Insufficient management controls
27.  Premature or overly frequent convergence
28.  Omitting necessary tasks from estimates
29.  Planning to catchup later
30.  Code-like-hell programming
31.  Poorly managed critical path or critical chain
32.  Poor task prioritization or Sequencing

Product-Related Mistakes

33.  Requirements gold-plating
34.  Feature creep
35.  Developer gold-plating
36.  Push-me, pull-me negotiation
37.  Research-oriented development
38.  Not using value engineering

Technology-Related Mistakes

39.  Silver-bullet syndrome
40.  Overestimated savings from new tools or methods
41.  Switching tools in the middle of a project
42.  Lack of automated source-code control
43.  Lack of Automated test tools 

Function Point Analysis, Transactional Function

IFPUG’s definition of transactional function, Transactional functions provide the means for a user to transact with the application. These functions facilitate the processing of data contained in the system, and convert and present it in a form desired by the user. Following rules can be used to identify transaction

  •          The transaction is visible or accessible to the user
  •          All transactions are identified to be outside the boundary but within the scope of the application being counted
  •          The various data elements that constitute the transaction necessarily move from outside to inside the application boundary and vice versa.
  •          The transaction could be invoked through various means of input (batch or online) or through a variety of hardware devices, sensors and more.
IFPUG defines EI, EO and EQ as follows:

External Input (EI)
An external input (EI) is an elementary process that processes data or control information that comes from outside the application’s boundary. The primary intent of an EI is to maintain one or more ILFs and / or alter the behavior of the system
External Output (EO)
An external output (EO) is an elementary process that sends data or control information outside the application’s boundary. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, or create derived data. An external output may also maintain one or more ILF and / or alter behavior of the system.
External inquiry (EQ)
An external inquiry is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, not is the behavior of the system altered.

Determining Complexity of EI, EO and EQ

Two components of any transaction decide its complexity; that us, Data Elements (DET) and File Type Referenced (FTR)

DET: A data element type is a unique user- recognizable, non repeated field. In simple terms, it is a filed in a file or a column in a database table, but the mapping of a field or column in the file should be with respect to the data element recognized from the user’s point of view.

FTR, a file type referenced (FTR) is a file, internal or external, that has been accesses by the transaction.

EI Complexity Factor
Range
1 to 4 DET
5  to 15 DET
16 or More DET
0 to 1  FTR
Low
Low
Average
2 FTRs
Low
Average
High
3 or more FTRs
Average
High
High

EO / EQ Complexity Factor
Range
1 to 5 DET
6  to 19 DET
19 or More DET
0 to 1  FTR
Low
Low
Average
2 to 3 FTRs
Low
Average
High
4 or more FTRs
Average
High
High

EI/EQ FP Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
3
Average
4
High
6

EO Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
4
Average
5
High
7

CRUD Transactions
If we evaluate the elementary process involved in CRUD transactions, we find that except in the case of a Read transactions, all others are unique, As such, while counting EI for a data maintenance transaction, we count them three EI, One each for Create, Update and Delete. The complexity of these three EIs might vary depending on the number of data element involved in each of the transactions.


Sunday, March 28, 2010

Function Point Analysis, Data Functions

Data function is one of the two most critical components of the entire FPA process. The functionality requirements of the application are met through data functions and are facilitated by means of internal and external files. The focus here is on logical storage of data in the forms of files and not the physical implementation.
IFPUG’s Counting Practice Manual broadly classifies the data function types into two categories: Internal Logical Files (ILF) and External Interface Files (EIFs). The boundary of the application being counted decides what is internal and what is external to the system. All files owned and maintained be the application being counted are ILFs and all files referenced by the application but outside the boundary of the scope of count, are EIFs. In other words, if the CRUD (Create, Read, Update and Delete) factors apply to a file in the system, it is likely to be an ILF, and if it is read only, the file is an EIF.
The CPM 4.2 defines ILF and EIF as follows:
ILF: An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application. The Primary intent of an ILF is to hold data maintained through one or more elementary process of the application being counted.
EIF: An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary process within the boundary of the application counted. This means an EIF counted for an application must be an ILF in another application.
The basic difference between an ILF and EIF is that although the ILF is owned and maintained by the application being counted, the EIF is used and referenced by the application being considered for FP counting purpose. The EIF referenced by the application being counted must be an ILF to another application.
Determining Complexity of ILFs and EIFs
IFPUG has defined a clear process of identifying an ILF or EIF as Low, Average or High and also has a fixed number of unadjusted function points assigned to each of these categories. Only two major components of any data file decided its complexity: data elements (DET) and record elements (RET).
DET
A data element type (DET) is a unique, user-recognizable, non-repeated field. In simple terms, it is a filed within a record of a file or a column in a database table (file), but the mapping of a filed or column in the file should be with respect to the data element recognized from the user point of view.
RET
A record element type (RET) is a user-recognizable subgroup of data elements within an ILF or EIF. There are two types of subgroups, Optional and Mandatory.

ILF/EIF Complexity Factor
Range
1 to 19 DET
20 to 50 DET
51 or More DET
1 RET
Low
Low
Average
2 to 5 RET
Low
Average
High
6 or more RET
Average
High
High

ILF FP Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
7
Average
10
High
15

EIF FP Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
5
Average
7
High
10

Points to Remember
·       -   An ILF or EIF may appear repeatedly in multiple sections of the same application during the counting process. Ensure that once a specific, identified ILF or EIF is defined and recorder, any subsequent appearances of the same ILF or EIF should be ignored.
·         -  The basic definition of an ILF and EIF maps them to a logical implementation of a file. Do not confuse this with the physical implementation of an existing data model in an RDBMS system. You should identify an ILF or EIF based on user view and ensure it is a logical implementable only.

Sunday, March 7, 2010

Overview of Software Estimation

Wikipedia defines “Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.”

Estimation Methods:
An estimation method is a set of process, supported by appropriate empirical formulae and backed with historical reference data,  that help derive predictable results within a decent level of accuracy. Some of the key characteristics of good estimation method are
•     Should be easy to understood and deploy
•     Allow modularization of the software application components
•     Provide predictable results with accuracy within reasonable limits
•     Be comparable across a variety of software projects
•     Provide conversion of the outputs to other project execution parameters such as schedule, cost, progress etc.

Function Point
A function point is a unit of measure for arriving at software application size. It measures the functionality. Functionality is the process by which information about an entity is fetched, stored or exported

FPA Model
The FPA model facilitates the measurement of software application size. The output of this method is function points. A function point is defined as a unit of business functionality delivered through the software.
The FPA model is based on the premise that any software application can be sized based on five key parameters: Input, output, inquiries, internal files and external interfaces.

1. Inputs: For any software application to exists, it is essential that programmers provide the means through which business information can be stored in the files.  Moving data from an external source into the application files and updating and maintaining the data are all included under the input attributes. All the CRUD (Create, Read, Update and Delete) operations are classified under the input attribute.
2. Outputs: Business information processed through the software application could be output in various forms. The outputs could be printed, stored on other media or even displayed on the monitor itself
3. Inquiries: The output of inquiry is quite similar to that of outputs discussed previously but the output generated here are in their original form. Business information is not processed; rather it is just or rearranged based on user request.
4. Internal Files: All the data that are owned and maintained within the application are stored in files known as internal files. These files belong to the application and any modification to the data contents is the responsibility of the application owner.
5. Interfaces: a software application that enables users to make business transitions with the software normally interact with other applications, either within or external to the organization. Interfacing with other application is a key attribute that contributes to the size of the application being measured.

The General system characteristics (GSC) are another set of 14 attributes that define the overall complexity of the software application being sized. These 14 GSC help the estimator define certain performance and operational aspects of the application. 

Sunday, February 28, 2010

The ISO 9126 Software Quality Standards


Function
Sub Category
DEFINITION
Functionality
Suitability
Attributes of software that bear on the presence and appropriateness of a set of functions for specified tasks
Accurateness
Attributes of software that bear on the provision of right or agreed upon results or effects
Interoperability
Attributes of software that bear on its ability to interact with other systems
Compliance
Attributes of software that make the software adhere to application-related standards or conventions or regulations in laws and similar prescriptions
Security
Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs or data
Reliability
Maturity
Attributes of software that bear on the frequency of failure by faults in the software
Fault tolerance
Attributes of software that bear on its ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface
Recoverability
Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it
Usability
Understandability
Attributes of software that bear on the users’ effort for recognizing the logical concept and its applicability
Learnability
Attributes of software that bear on the users’ effort for learning its application
Operability
Attributes of software that bear on the users’ effort for operation and operation control
Efficiency
Time behavior
Attributes of software that bear on response and processing times and on throughput rates in performing its function
Resource behavior
Attributes of software that bear on the amount of resources used and the duration of such use in performing its function
Maintainability
Analyzability
Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures or for identification of parts to be modified
Changeability
Attributes of software that bear on the effort needed for modification, fault removal, or environmental change
Stability
Attributes of software that bear on the risk of unexpected effect of modifications
Testability
Attributes of software that bear on the effort needed for validating the modified software
Portability
Adaptability
Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions or means than those provided for this purpose for the software considered
Installability
Attributes of software that bear on the effort needed to install the software in a specified environment
Conformance
Attributes of software that make the software adhere to standards or conventions relating to portability
Replaceability
Attributes of software that bear on opportunity and effort using it in the place of specified other software in the environment of that software