Don’t blame your cat, talk to your duck (includes chapter 1 The Pragmatic Programmer | from journeyman to master)

--Originally published at Alfonso reviews…

To be a pragmatic programmer you need to approach problems keeping an eye on the big picture, we don’t always have to create the best software, but sometimes we have to, also, sometimes we need to adapt to the changes, but that’s not always the case, the point that I’m trying to get here is that there is no static solution to all of your problems, use your criteria so you can get to a good solution.

When you make mistakes or you don’t know how to do something, speak, offer options and learn, and don’t blame others for your mistakes, be responsible. And if the need comes, talk to your rubber duck and explain it your situation, maybe the rubber duck will give you the same answer your boss would give you, and you just saved your boss from that.

When someone makes a mistake, and it’s ignored, the tendency states that more mistakes will come, even when it’s not code, a bad decision or design can also wreck a project into tiny pieces. Code follows the law of entropy, so beware and clean your mess, and keep an eye on other’s mess, see if you can help.

This two topics were part of the first chapter of the book, but I was surprised to find the stone soup story, as a reference to what I think is incremental delivery, many times people won’t give away what you need to develop a big project, unless of course you convince them you can do the thing by showing them well done mini deliveries, then you can ask for more, and deliver even more. But as stated at the start of the chapter, keep in mind the big picture, or the original idea of the project will fade away and you

Continue reading "Don’t blame your cat, talk to your duck (includes chapter 1 The Pragmatic Programmer | from journeyman to master)"

How pragmatic are you?, introduction

--Originally published at Alfonso reviews…

This post is an introduction for “The Pragmatic Programmer” from Andrew Hunt and David Thomas, and the authors said it’s intended for people who want to become more effective and productive programmers. For people who want to do, they stated that this isn’t a theoretical book, but a practical one, a way to gain experience and productivity, a way to write better software.

Authors also said that this book will help you become a pragmatic programmer, and that if you become one, you will probably gain the following characteristics, you’ll become:

  • An early adopter/fast adapter so you’ll enjoy trying new technologies to apply them in the future.
  • Very inquisitive, asking questions about how everything works.
  • Critical, you won’t take things for granted, you’ll wonder if things can be done differently than stated.
  • Realistic, if a problem is hard, you will notice, and won’t lose determination in spite of that.
  • Comfortable with many technologies, even when you don’t need them at the moment.

I thought I needed to be more confident with new technologies, so I challenged myself to read this book.

Will you accept the challenge as well?

Found it (includes chapter 15 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

System testing goes almost along construction, as you should make a system test before and after you are trying to integrate new code into the project. But, how can you test your project? If you have been following the guides from chapter to chapter, you should have a user interface and a user manual by now, and using those you can make test cases even before the code is implemented. The way you test the project is made by simply checking if it passes the test cases that you have developed.

With the approach followed on McConnell’s book you won’t find that many errors, this is because before passing by the system testing, everything has already passed by a review  during user-interface prototyping, User Manual/Requirements Specification review, architecture review, detailed design review, and code review. And everything will have been both unit tested and integration tested by its developer. Plus the daily smoke test. This will avoid entering a cycle of infinite errors.

At the start of each stage you should add new test cases, so the requirements in that stage are fulfilled. If a build doesn’t pass a test, it will go back to development. If an error is found, it should be corrected, not ignored, this sounds obvious, but it doesn’t always happen.

When many errors arise on a routine, don’t waste time on solving the errors separately, redesign that routine and reimplement it. Chances are you’ll waste less time and money.

As a developer, I both like and don’t like finding errors, it means more work, but it also means that the thing that I’m doing can improve, as a tip, I would recommend focusing on the “it can improve” part, when the error is gone, you’ll be happier, because you now know that your code won’t

Continue reading "Found it (includes chapter 15 Software Project | Survival Guide)"

Build it guys (includes chapter 14 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Construction is the stage where software comes to life. If previous stages have been done well, this will go smoothly, as features are added incrementally, the team should be able to test them and track the progress of the project. The team should keep the focus on simplifying the software.

Constructing can either be fun or disgusting, it all depends on how you planned it, if you planned it poorly, you’ll be struggling just to save your building from falling apart, but if you made the necessary preparations, you’ll even be able to choose the color of the paint for your walls.

Use code standards, they’ll help you in the task of making a code understandable to many developers, not only one. Keep the standard from project to project, that way, developers won’t have to learn a new standard each project, and they’ll be able to reuse code.

In order to add more code to the main build, the book recommends following some steps:

  1. Developer develops a piece of code.
  2. Developer unit tests the code.
  3. Developer steps through every line of code, including all exception and error cases, in an interactive debugger.
  4. Developer integrates this preliminary code with a private version of the main build.
  5. Developer submits code for technical review.
  6. Developer informally turns code over to testing for test case preparation.
  7. Code is reviewed.
  8. Developer fixes any problems identified during the review.
  9. Fixes are reviewed.
  10. Developer integrates final code with the main build.
  11. Code is declared “complete.”

I, as a developer, agree with this steps, they reduce the number of errors, and when done right, you can be sure that the code submitted is done, and the feature it covers is complete. Continuously coding without revisions will lead you to a loop where you’ll always  be searching for

Continue reading "Build it guys (includes chapter 14 Software Project | Survival Guide)"

Just as a checklist (includes chapter 13 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

On this chapter, detailed design was discussed, it can affect the whole project and it extends design work done during the architecture stage. During stage 1, detailed design  requires verifying the quality of the architecture, if it has bad quality, it’s time to correct it.

Detailed design also uses a staged approach, at each stage developers design the features that’ll be delivered at the end of that stage. A good architecture will let you focus on the current stage. During detailed design is when developers check if they can reuse components.

At the start of each stage, requirements must be clear, if a requirement is not clear is either resolved during that stage, or resolved in a later one, but the leadership should be informed about this delay. Delaying a requirement is a bad idea, if you do it too often you’ll end up delaying the project. And remember, a project is delivered a year late one day at a time.

Requirements flow from requirements to architecture to detailed design to code and test cases. Developers must continue doing detailed design until they get miniature milestones for construction. But how much does that is? It depends on the experience of the developers and the difficulty of the project, the more experienced the team, and the easier the project, the less detailed design you’ll need. Still, more is safer.

After done, detailed design should be reviewed,  and it must have correctness (will it work?), completeness (for everything we intend it to work?) and understandability(is it clear how it works?). With detailed design reviews, more than one person knows each part of the project, so if someone goes missing, you’ll have at least a plan B.

Be sure to use detailed design on your projects, a little

Continue reading "Just as a checklist (includes chapter 13 Software Project | Survival Guide)"

Stage by stage (includes chapter 12 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Staged planning is something that is done at the start of every staged delivery cycle, where the project team creates an individual stage plan for each stage. It describes how to conduct detailed design, coding, technical reviews, tests, integration, and other activities.

When doing the plan for a stage, use mini milestones, they help you track progress and reduce risks. Staged planning is somewhat a plan with many mini plans.

Remember that the project is guided by the software development plan, but each stage is guided by a stage plan, which is much shorter, each stage plan must be included in the software development plan.

In other words, each stage is like a miniature project. And smaller projects involve less risks. Big projects that are poorly planned, tend to have a shaky development and rarely get delivered. Plan for the mini, aim for the whole.

Basically a stage plan is a miniature version of a software development plan, and it should include every update to the requirements (requirements will change while you get to know better your project), revisions on the design, including the project architecture, the coding of the current stage, test cases, time for technical reviews and defect corrections, also there should be a space for designing teams coordination, like developers and testers teams. But the thing where you should focus the most is in risk management, if you keep track of the top priorities on the survival of the project at the start of each stage, you project will get higher chances of being developed and delivered. At the end of each stage you should have a deliverable product, and you should review the progress.

But, as much as you plan, plan doable things, milestones are either done or not done, don’t trick yourself. If a well

Continue reading "Stage by stage (includes chapter 12 Software Project | Survival Guide)"

Prepare for it (includes chapter 11 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

When doing the final preparations, the team is ready to create estimates and develop a plan for the critical functionality delivery. In other words, what needs to be done is this:

  • Create estimates for: effort, cost, and schedule.
  • Estimates must be written, and they should include time for all normal activities, from coding, to being sick.
  • Don’t depend on overtime, add extra time to your estimates, that way you’ll have a backup plan if anything happens, and believe me, something always happens.
  • Use an estimation software. Calibrate the estimation software with your own projects.
  • Let the developers review the estimates, you want them to be happy. Reestimate several times. Estimates must be under change control.

Manage the project with a staged delivery plan. Some perks of doing this that I noticed while reading are:

  • You’ll meet the customer’s critical needs faster.
  • You’ll be less pressured by needy customers.
  • You’ll be able to identify stages by themes, and this will help on the classification of features.
  • You’ll deliver by themes, from the critical one to the not so critical ones.

Staged Delivery Plan should be under change control.

Last but not least, I’ll list the activities that you should be doing continually; at all times you need to be managing risks, checking that the project is still following the original vision, authorities and people who can take decisions about the direction of the project need to be focused on the project goals, always help them, update the software development plan when needed and keep the team healthy, a healthy team has a healthy morale, and a team with a healthy morale will most likely be productive.

Software architecture (includes chapter 10 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Chapter ten of  McConnell’s book talks about the software architecture document, which describes the program organization, having a good software architecture means that your project will be an easy one, on the other hand, if you have a bad software architecture you shouldn’t even try it, chances are it will fail.

During this phase is when the software gets mapped through design diagrams, trying to make a clearer view of what is going to be done, it serves as a base for a more detailed design.

You should start making the software architecture document when about 80% of the requirements are known. It needs to cover topics like a general view of the project, with the major design alternatives, the reasons for those approaches, and the reasons for not choosing other alternatives.

Keep it under 100 pages, and full of diagrams. The chosen approach must be logic, because the solution to the problem needs to feel natural if you want your product to be used. Also, the document should define the major subsystems of the program. And by subsystem McConnell means a cluster of functionality, your software document shouldn’t be complex, don’t overdo it, 5 subsystems are fine, more than 9 not so much.

Take account of change scenarios, don’t make the mistake of setting all of your project with the tools provided by someone else, if that someone else disappears, you are doomed. But reuse and buy, building is not always necessary, this last thing may reduce production costs and times.

In this document you also need to keep track of requirements, if you discover new ones, celebrate, it’s better to know them now than later. With this create a traceability matrix. Make all of this in a way that you can use staged delivery, the idea is to have

Continue reading "Software architecture (includes chapter 10 Software Project | Survival Guide)"

Do it right (includes chapter 9 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Chapter 9 of the book talks about quality assurance, but, why is it important? The answer is quite simple, if you keep defects under control you’ll develop faster, and your costs will go down.

Getting support for poorly planned software costs a lot, and raising a project on a shaky base won’t work either, maintainance prices will rise higher than NASA rockets, and I think that I’m saying the truth when stating you don’t want that to happen.

As all other activities we have talked so far, quality assurance must be planned and written too, test planning comes at the same time as the requirements, and the plan must include activities like:

  • Defect tracking
  • Unit testing
  • Source-code tracing
  • Technical reviews
  • Integration testing
  • System testing

In other words, quality assurance must look for errors and document them, check every single function in the code, debug line by line, review what has been done, check interactions between functions, and check the whole system working.

Gathering all this information will speed your project and will help you make better estimates for future projects.

On a separate note, reviews help on upstream activities (since the beginning), and system testing (when you have a prototype) focuses on downstream activities, do them at the right time.

Keep testing, test at all times, why? because testing gives you a scope of the quality of the software, it won’t solve your problems, but it’ll help you identify them, and then you can plan a good aproach for those problems. It would be bad if some bug went untracked for a long time, and discovered on a critical stage of the project.

If your software will be delivered to thousands, make a beta test, this will help testing on different systems, verifying compatibility, without the cost of spending on

Continue reading "Do it right (includes chapter 9 Software Project | Survival Guide)"

What Do You Want (includes chapter 8 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

This chapter of the book talks about requirements development, basically asking the needs of the customer and transforming them into specifications. This consists of three main activities, gathering, specifying and analyzing requirements, The thing is that you don’t actually go with the customer and instantly gather the requirements, you need to help the customer realize what does he/she wants. Save time and money, and do this the right way, getting a wrong requirement will cost you from 50 to 200 more times later in the project.

To do this right you’ll need to identify some key users, interview them searching for preliminary requirements, build a prototype of the user interface, after that you should ask for feedback from the key users you interviewed. modify it, keeping it simple, and keep getting feedback, do this until your key users get excited with the product. Put the project under change control. Extend the prototype until it covers every functional area of the software, keep in mind that it doesn’t need to be implemented. Last of all, you’ll need  end-user documentation and non-user requirements to keep track of what is happening. Remember, the whole project must be under change control.

Now the real issues:

Trust, you need to trust your key users, if they say something is missing, it’s a fact, it’s missing, if they say something can be left out, just let it go, you don’t need that feature.

Keep it simple, if it’s a prototype, make it clear. It’s the best for you and your key users. And set a style for how the project will look and feel, so you won’t get changes on this matter by users at a late stage of the project.

Remember that the prototype will serve you as a guide on how to do the

Continue reading "What Do You Want (includes chapter 8 Software Project | Survival Guide)"