Pragmatic approach

Welcome to my views and thoughts regarding episode 2 of the fantastic book “the pragmatic programmer”, in which a hope to share some of the already digested insight from this chapter. The main focus of this chapter is the aproach to solutions in the development plan of a project and it starts by discusing the advantages that a well though project can avoid the duplicate problem. Inside a software project information can tend to duplicate itself for many reasons, some of this reasons are.

• Imposed duplication. Developers feel they have no choice, the environment seems to require duplication.
• Inadvertent duplication. Developers don’t realize that they are duplication information.
• Impatient duplication. Developers get lazy and duplicate because it seems easier.
• Interdev eloper duplication. Multiple people on a team duplicates a piece of information.

And also, speaks about the project orthogonality, a concept taken from geometry that implies independence from code module to module or from person to person, good orthogonality can be applied even outside the programming concept. In every day’s work the orthogonality is reflected on the lack of information repetition. The advantages of this are many, but it is simplified in code reuse and little modifications in case of need of more features. On the other hand, projects that lack orthogonality are those that are really chaotic, adding new button in the AI needs the whole architecture to take a new approach.

The fact this thing can fly is pure coincidence.

Reversibility is about the simple solutions, how the simple solution is not always the desired one and how we the developers must be looking at the bigger picture. Is our project likely to be client based or server-client? even if we don’t know yet (or even if we know) we must consider that the specifications and the marketing team can change the rules of the software by the night, so is better to rest prepared than to fall back to square 1.

Last but not less estimations, estimating is the art of making numbers out of activities that are to be executed in the plan, the one very important skill I take from this activity is to ask another person who has done something similar to you and to know where he took the longest time.

 

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

(2000).

A man with a (development) plan

Requirements development

Users can have lots of ideas about what they want their projects to be and where they want their projects to be lead to. The mind of a user is fertile resource of requirements, but the project team must focus the attention of the user to its most needed function.

the most difficult is not the act of recording what the user want, it is the exploratory, developmental activity of helping users figure out what they want.

The following steps are recommended by the book as those that we the project team should follow in order to accomplish proper requirements.

• Identify a set of key end users.
• Interview the end users
• Build a simple user interface prototype
  • User paper storyboards if possible
• Develop a style guide
• Fully extend the prototype
• tread the fully extended prototype as the baseline specification
• Write the detailed end-user documentation based on the prototype
  Create a non-user interface requirements doc

Identify a set of key end users

Localizing the correct user for the project is a very important part of the project plan, to identify this kind of user you must look for that that will be in contact with the software the most and will give you correct feedback about the kind of software they expect.

Interview the end users

Not much to say, its again, you must hear the end user and its needs, the project must be focused to fulfil what the end user wants. But the user is not very good at making correct architecture about its project and so we must look further than the user. but the user knows what he wants it to look like and so you can take proper information regarding what kind of interface to craft.

Build a simple user interface prototype

End users reaction first reaction after looking at the prototype.

Prototyping is all about how the result software will look. The point of this activity is to present many alternatives to the user before commit much effort to any approach. The project team must consist of a small group of senior developers that know how to make fast interfaces that give a feeling of comfort with the less amount of effort.

and make sure the user understand that the prototype is “just a prototype” otherwise expectations may rise or go down the drain.

Paper storyboards

This technic on this approach, developers and users gather together to draw on paper what they expect the and product to look like, they draw windows, buttons, etc. This approach is useful because the user can put some effort in making the prototype, it also helps at illustrating that a prototype is a small look of what the software must look and also avoid the team to over extends with the prototype.

On the other hand, some users are not very good at knowing what the prototype must look and this defies every point of the prototyping.

Develop a style guide

The developers should set standards for the look and feel of the application. This document should be at most 6 pages long where we describe things like where is the dev team placing the buttons. This is to create standards that lead the development of the user interface.

Fully extended prototype

The project’s vision statement enables developers to align their work in a general way; the detail user interface prototype provides the detailed vision that enables them to align their work in thousands of smaller ways. Here is a partial list of the functionality

• all dialog boxes.
• all graphical input screens.
• All graphical and textual outputs.
• Interactions with the operating system, such as importing and exporting data to the clipboard.
• Interaction with all third-party products.

Prototype as the baseline specification

The organization will base its estimates, plans, staffing, architecture, designs, and development work on it. It is both appropriate and necessary that the decision makes commit to the prototype and that changes to it be systematically controlled.

Write the detailed end-user documentation

The early development of the end-user documentation fleshes out the details of the software demonstrated by the user interface prototype, filling in gaps and flushing out inconsistencies.

Create a separate, non-user-interface requirements document

Specifications of detailed algorithms, interactions with other hardware and software, preformation requirements, memory and usage, and other less visible requirements can be recorded in a separate requirements document.+

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Pragmatic mind

This is my review from chapter 1 from the pragmatic programmer. This are the very few pages that I have read of this book and I must say that I am very excited, I don’t know how exactly is the rest of this book but so far has been really entertained, not very technical and with a lot of style that keeps giving even after more than 17 years and I believe that the fact that we can keep learning from a books about software development so far from that time means that although much of the technology is changing and moving forward some old lessons must always stay as the base of the learning for every computer scientist or teach savvy or software engineer. The knowledge from this chapter can be divided in two big sections, the outsiders and yourself. The Autor talks about some issues that as a person and not only a software developer we must take care and that is the communication, and communication goes both ways, first to ourselves being critical with the many decisions we take and being careful how we judge what we hear, not taking things for granted.

The pragmatic programmer must excel at caring his creation, we must keep a quiet and steady eye in the need that arise and solve them. The programmer must also stay in constant focus learning new technologies, learning  new programming languages and different technology trends so we can take advantage and to keep us ready for change.

Hardwork and dedication makes the best cake.

On the other the programmer must stay in contact with one very important person in the software process and that is the client, and that is where I believe the duality of communication must take place, the proper software can only be tested against that  one customer that requires the software and even then sometimes he the client doesn’t exactly knows what he is asking for, some of the lessons that we have already talked about take place in here like how to handle milestones and how to make planning before even going in to the codding labor, and that communication must remain along the development of the project.

Overall I’m really liking this book and it encourages me to put dedication to my “computer crafts”, I recommend everyone to give it a try and if you want to keep reading what I have to say about further chapter  of this books stay in touch. See you soon.

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

(2000).

 

Introduction to pragmatism

Today I set a goal to start (and finish) to read the pragmatic programmer by Andrew Hunt, I first took notice of this book while looking for a list on the most important computer science books to read and it stood out to me because it was not once that I found this but many times and now I finally set the task and although this blog has been much more related to the control of project management orientation I want this space to be for every topic that is close to software and computer engineering.

A pragmatic is a person who seeks perfection and skill in his labor, and programmer have the need to be perfectionists, many times we have the power to create great thinks but we don’t always code, we also have other responsibilities like documenting our job, dealing with deadlines, making our code the easiest to understand for other in our team and keep track of the many changes in the control flow that may interrupt us.

Is a difficult job. (Hunt, 2000)

And so this books seeks to aid the one in need of help and for that we need people willing to think before doing and to think what they are doing. Of all of the characteristics listed the one that must stood the most for a proper pragmatic programmer is the next.

Care about your craft.

To begin with the process of pragmatism so we must care about what we do we must find passion where everything is doubt and we must believe that our work is well more than mere lines in a paper, it is communication and therefor an extension of ourselves, the individualism of our work will show well above and so we must be sure that what we do is well done and what we aim for is excellence. The individual beliefs must be optimistic regarding how we work.

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

(2000).

Preparations!

The same as a cooking recipe a project should have many preparations even before it is done or planned, and to make a proper cake we need a proper vision of where we are going. The successful project begins even before the planning begins, there are many things to do before even starting the plan.

• Project vision
• Executive sponsorship
• project scope targets
• publicizing plans and progress
• risk management
• Personnel strategies
• time accounting

Vision

the vision is a guide that inspires the team to achieve its goals a vision must be well established and must well be based on achievable goals. The project vision not only dictates what must be done we also determinate what must be left out of the software.

Stephanie in the famous kids show Lazy town showing how to properly cook by the book

 

Executive sponsorship

Executive sponsorship is the support given to the person or groups who has final authority over project wide decisions. Its important to make decisions with good sponsorship because sometimes is the same control board to which the project must respond.

Project scope targets

Before the project is started we must have intended of budged, schedule, staffing, and feature set of the software. In this part we are not talking about estimates but more about tentative targets. As the project progress the team becomes aware of how much of every resource is excatly needed and therefore the development process is refined.

The best organizations plan to reestimate regularly throughout the project and periodically adjust their project plans based on the re estimations.

Publicizing plans and projects

Much of the time the plans are not exactly private but also the people that are conducting this plans take little effort on making them public. Project plans must be reviewed and approved by the people that must execute them. If this phase is not taken into account is possible the project team will make its decision of approving or disapproving the plan by itself.  On a healthy project, all of the planning materials are public available and for review.

Stephanie was not ready for the last second mainframe implementation minutes before release but that is not administrations department business.

Risk management

Success at risk management consists on making the commitment to perform risk management, developing an ability to perform it, carrying out activities to perform it, and verifying that the plan for management risk has been effective.

Personnel strategies

Here we must take into account the people of the project,because losing a person or 2 or 5 can be just as much impact for the company as loosing thousands, is the people in the project the one that is actually doing the job and is part of the project and human resources to keep them satisfy with the work they are doing. Some characteristics of plans focused on peopleware are.

• Managers are evaluated based on how well they retained project personal.
• All members of the project have access to professional growth.
• Developers believe in the vision of the project and emerge from the project feeling better about the company.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Hitting a moving target

This chapter is dedicated the goals for a successful software project.

Change control procedure

The basic change control procedure involves.

1. The initial development work for a work product  (such as the project requirements) is performed without change control coming into play.
2. The work product is subjected to a technical review.
3. When initial development is complete, the work product is submitted to a “change board”.
4. The work product is placed under “revision control.” Revision control refers to a software revision control program that is capable of archiving multiple versions of anything stored electronically.
5. Further changes are treated systematically.
   1. Changes are proposed via change proposal.
   2. The change board identifies parties that might be affected by the change and distributes the change proposal for their review.
   3. The concern parties each assess the cost and benefits of the proposed change.
   4. The change board members conbine their assessments and prioritize the change proposal.
   5. The change board notifies all concerned parties about how the change proposal was resolved.

Change control benefits

The primary benefit of change control is that it protects the project from unnecessary changes by ensuring that change proposals are considered systematically. Change control combats “Mushy milestones”. One of the more subtle risks on a software project is that the project team will reach a milestone and declare that milestone to have been met even though the team’s work doesn’t really satisfy the milestone criteria.

The elimination of mushy milestones also improves status visibility. If you know that milestones are hard, the fact that the project has completed a milestone is a meaningful status indicator.

Benefits of automated revision control

Enable project members to easily retrieve any version of any major document that has been produced on the project. They can retrieve initial project plans, revised project plans, and current project plans. They can re-create any version of the product that has ever been released to a customer.

Common change control issues

When to consider changes.

How to handle small changes.

How to handle political issues.

Which work products to place under change control.

 

committing to change control

Software change control activities need to be planned. The change control plan procedure and list of work products described in this chapter should be expressed within a written change control plan. The software development plan should reference the change control plan as part of the official software process.

Project members must be given time to carry out their change control responses.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

The successful project

Uncertainty and discovery

Software projects are done with discovery and investigation, one of the best ways to organize them is by the approach called “staged delivery”in which the software functionality is developed and delivered in stages, first we take care of the most inportant functionality and afterwards add more and more features this approach is important because the client, or the manager can receive small deliveries periodically and the project is better settled after small milestones are achieved.

One think that stands out abut the internal thinking of the project is how is divided into different phases that overlap, the discovery, invention, implementation. During the first part of the project the team reaches to the client and does all of the upstream task, this involves getting to know the customer needs, or if the client already knows them interpret what he wands and create early user interfaces to get validation. In this phase its important to take into account what we have already talked about the software product, approach to minimalism and hear the client and end user.

In the middle phase we shift the focus to invention, this is the phase where the architecture is created, classes, subclasses. And to create this inventions we many times have to create smaller inventions to support them. And at last we implement what we created which basically means “to put in practice what we learned in the previous phases and applying this knowledge”.

Project Flow

In this diagram we can see that the staged delivery approach focuses project planning and risk reduction. The project team develops a software concept at first, then gathers and analyzes requirements, and the completes an architectural design.

Benefits

Some of the benefits of this project flow are the facts that the critical functions are available earlier so the users who are waiting for some particular features earlier don’t have to wait until the project is done. Also the problems become evident really fast and can be managed, this is unlikely if you are working on a project to be delivered all at the same time where many of the mistakes are discovered until production is over.

Disadvantages

Your team get tired faster because the time needed to drive the software to a releasable stage multiple times., retest already-tested features and perform version control and addressing the extra complexity of supporting additional versions and…

Some of this cost are not really extra, costs that remain hidden until the release of the software but some are, like the activities related to actually releasing the software.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.