Architecture

Chapter 10 of software project survival guide. Is about the architecture of the software. During the architecture phase the architecture team interaction among system into major subsystems, specifies all the interactions among subsystems, and documents the software top level technical plans.

Easing into architecture

Architectural work should start when requirements development is about 80 percent complete. Resolving 100 percent of the requirements before beginning architectural work usually isn’t possible without delaying the project. By the time 80 percent of the requirements are known, the project is on firm enough footing to support creation of software architecture.

Characteristics of a good architecture

  • System overview. Needs to describe the system in broad terms.
  • Conceptual integrity. When you look at the architecture, you should be pleased at how natural and easy the solution is. It shouldn’t look like the problem and the architecture are stuck together with duct  tape.
  • Subsystem and organization. Once you realize that the goal of architecture is to reduce complexity, it becomes clear that the architect must focus as much on what to leave out of the software as on what to put in.
  • Strive for minimalism, simplicity, and coverage of all of the requirements, and don’t worry too much about finding the best solution.

Bibliography

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

Bend or break

This is about chapter 5 in The pragmatic programmer. The job of  a programmer is always evolving, new things come out everyday, many new frameworks come and go and that applies to many areas of programming, web programming is affected the most because the nature of how the INTERNET moves. In this chapter we dedicate some time to the best practices to keep your programs flexible and maintainable.

rglfizf

keeping a cake shop is not as bad of an idea now we envy you Stephany.

The Law of Demeter for Functions

attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object’s methods.law of demeter

Dynamic configuration

Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.

We use the term in its broadest sense. Metadata is any data that describes the application—how it should run, what resources it should use, and so on. Typically, metadata is accessed and used at runtime, not at compile time. You use metadata all the time—at least your programs do. Suppose you click on an option to hide the toolbar on your Web browser. The browser will store that preference, as metadata, in some sort of internal database.

 

Bibliography

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

You are (not) perfect

Everyone knows that they personally are the only good driver on Earth. Well its the same with codding, we go around making sure everything is perfect when we have in hand the code of another person. And pragmatism is about taking this one step further, to not trust ourself. We know that no one makes perfect code, including ourselves. Ahead well find some measures to protect ourself from what software we create.

Design by contract is about focusing in the documentation and the rights and responsibilities of software modules to ensure program correctness. Correctness is something that does what it claims to do?

Every function and method in a software system does something. Before it starts that something, the routine havve some expectation of the state of the world, and it may be able to make statement about the state of the world when it concludes. These are.

Preconditions. What must be true in order for the routine to be called; the routine’s requirements.

Postcondition. What the routine is guaranteed to do; the state of the world when the routine is done. The fact that the routine has postcondition implies that it will conclude: infinite loops aren’t allowed.

Class invariants. A class ensures that this condition is always true from the perspective of a caller.

The contract between a routine and any potential caller can thus be read as

If all the routine’s preconditions are met by the caller, the routine shall guarantee that all postconditions and invariants will be true when it completes.

All errors give you information. You could convince yourself that the error can’t happen, and choose to ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

Tip 32
Crash Early

enjuowp

with style

One of the benefits of detecting problems as soon as you can is that you can crash earlier. And many times, crashing your program is the best thing you can do. The alternative may be to continue, writing corrupted data to some vital database or commanding the washing machine into its twentieth consecutive spin cycle.

 

Bibliography

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

How to handle programming tools.

Many are the tools that have been created by programmers for programmers, we tend to have very specific tastes when it come to languages, paradigms, text editors and IDES that it is hard to track the really useful tools. But after reading this chapter I can deduct that there are some tools that never get old, vi, emacs, are the ones that stand the curse of time the better, but there are also new tools that are worth mention. For example atom, and sublime text can be very powerful on their own and can handle many kinds of language while keeping the simple plain text for everyone to use, even better atom already comes with source code control integrated in the form of github. Github tracks the files you are working on and  keeps track of the changes you make to said files. pgcif7h

Bibliography

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

Quality

We now move on the chapter 9 of the Software Project Survival Guide where we take a peek at what is inside the project to make it from average/bad to outstanding/good. This chapter made me think about the many times I have acknowledge the power of the technology that I use from day to day, some of my favorite brands are dropbox and drive, incredible easy and intuitive tools that allow me to move without fear of losing the information I carry with me, ever since I use them I know that I can change my computer without fear of losing anything and I believe that is a great quality of the product, the fact that without saying it just makes my life easier and easier. The cost of the software goes even after the software is released. Software quality has a bottom-line impact on the cost of doing business. Low quality software increases the burden on end-user support. Leading companies like Microsoft.

Survival requires a commitment to quality assurance which involves the following elements.

  • Software quality assurance activities must be planned.
  • The plan for the software quality assurance activities must begin during software requirements activities or earlier.
  • A separate group for performing software quality assurance must exist. Depending on the size of the project that group might consist of one person.
  • Members of the group must be trained on how to perform software quality assurance activities.
  • Adequate funding must be provided for performing software quality assurance activities.

An effective quality assurance plan will call for several quality assurance activities: defect tracking, unit testing, source-code  tracing, technical reviews, integration testing, and system testing.

Defect tracking runs throught these quality assurance activities. The project team keeps records of each defect found, its source, when it was detected, when it was resolved, how it was resolved.

Unit testing is informal testing of source code by the developer who wrote it. The word “unit” can refer to a subroutine, a model, a class, or an event larger programming entity. Unit testing is usually performed informally but should be required for each unit before that unit is integrated with the master source or turned over for independent review or testing.

The “V” Concept of Software Testing

e4ko42h

Life cycle testing involves continuos testing of the system dureng the developmental process.

At predetermined points, the result of the development process are inspected to determine the correcness of the implementation.

Source-code tracing is stepping through source code line by line in an interactive debugger. This work is performed by the developer who wrote the code. Many developers have found this to be an invaluable means of detecting coding defects, and my own experience bears this out.

 

 

Bibliography

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

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.

spxwmpsThe 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

xw539ea

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.

rglfizf

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.

uj09cj7

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.

bn6uf05

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.

rglfizf

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.

rglfizfStephanie 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.