Rapid Development chapters 33,37,39

--Originally published at Jose Ramon Romano

Chapter 33

Well this chapter talks about reuse, although I  think we are able to reuse our code I think that it is always important to refactor it before doing the project, in case we might find that it needs something new or it can be a better code, we can find those bad smells and make our code better, this will make our code more valuable and we are going to be confident in reusing it if we know it works for sure.

Chapter 37

Okay first of all the chapter says that a project involves a lot of people, and in my experience it doesn’t, it depends a lot in the project and who are you doing the project to, it also depends on the size of your company and stuff like that, but i do i agree with the book, you have to find a way where everyone is happy, where everyone thinks they are in a win-win situation.

reuse-logo

Chapter 39

Okay in this chapter I recomend you to read the book it talks about timebox development, I just wanted to say that I’m really stunned with time, people tend to procastinate a lot and I don’t know why I just read an article with a bunch of reason on why people procastinate and I still don’t know for sure those are the right reasons, I mean I have rpocastinated too and some reasons suit but I do think there is something else.

TL;DR: I think resuing code is cool, amount of people involved ina project is highly dependent in other factors, why do people procastinate a lot?

In the book: 

  • Try to read some chapters you don’t know anything about

 


Rapid Development chapters 23, 28

--Originally published at Jose Ramon Romano

Chapter 23

inspection

Well, chapter 23 talks about inspections, i really think this is important because sometimes when people delegates work, they usually hope for the other one to do something and if they dont track their work it may not be ready for the due date, I don’t know why this happens, but it does, some people just need someone behind them to keep checking if they did their work.

Not always is the laziness of the people, sometimes someone may have understood something different, so inspections help you to correct mistakes before they happen, another thing it may happens is that if you see that the project is going slow you may try to start thinking in a solution for the due dates.

Chapter 28

outsourcing

I think this is pretty important, if you are starting your enterprise or you dont have the personal to do something you may hire an outsourcing company, they can help you reduce the work you have or they may just do something you dont know how to do it, it may imply a greater cost but it may improve the quality of the software you are trying to deliver which we have talked it is a big deal.

Currently I’m studying and i have some projects and for the design I know I can do it and win more money but to be honest someone else is better than me at that, so I rather hire someone else for that, an outsourcing to do it, this guy or company won’t be a part of my company but will help me improve the quality of it.

TL; DR: Inspection may help you avoid problems, outsourcing makes work easier and with more quality

In the book:

  • Evolutionary Prototyping
  • Daily build and Smoke Test

Rapid Development chapters 11-12

--Originally published at Jose Ramon Romano

So, while I kept reading this book, I learnt a lot of things but my thoughts on some topics are the same as in Software Project Survival Guide, this book talks about Planning, Requirements, Risk Management, etc. and the same stuff as in the other book, obviously with a different approach but if you would like to know what the book says you should go ahead and read it, my blog isn’t meant to make a summary of everything, it has the purpose to give a personal opinion about what I’m reading.

In the blog posts about this book I will be writing about the chapters I found different or I have found a different opinion

Chapter 11

Resultado de imagen para motivation

This is it, this chapter talks of what I think it is the most important factor in everything, motivation, while I was talking about this in my post about Software Project Survival Guide Ch 12-14 I said I was thinking of doing a post about this and this isn’t it, I’ll give my opinion about what the book says about it, but now I will for sure make a post about motivation.

The book talks about the general factors that move people, after that the book explains you how to use the top five motivation factors in your favor, which I think it’s awesome, I don’t want to sound like I don’t care about people and I don’t want to use the following phrase but I think that manipulating people is a great factor to everything and if you are a leader believe it or not, you have to do it, you have to manipulate them and I think that the word manipulate doesn’t mean something bad.

Another thing I found incredibly good in this book was the Morale Killers, this is

Resultado de imagen para motivation
Continue reading "Rapid Development chapters 11-12"

Rapid Development chapters 1-3

--Originally published at Jose Ramon Romano

In this section I’ll talk about this book, Rapid Development, I’ve been reading a bit now and it seems interesting, the fact that the author says that you can save up to half of your time by following what he says is pretty interesting, i was ready the index and I found some chapters pretty interesting but some others I think they will be pretty similar to some other books, or to the book Software Project Survival Guide, so on those chapters I may just write a thought or a brief opinion.

Chapter 1

Well this chapter explains us what is rapid development about and well it mainly says that there are some companies that waste our time with somethings and that there are things we can do to improve our time, this chapter mentions 3 schedule-oriented practices which are:

  • Practices that reduce your development speed
  • Practices that reduce schedule risk
  • Practices that makes progress visible

I personally think that practices that makes your software progress visible highly depend on the context, I think that if we are making a software for our company, or the client doesn’t pay much interest on how the project is going, I think that if your team if fulfilling your schedule, you won’t have any problem with that.

Chapter 2

In this chapter, the author makes an analogy with an orchestra, about how the orchestra won’t work if they don’t have his conductor, and that the same happens to software developers teams, ¿How does good software developers teams sometimes fail to develop? Well the book says we can focus on four pillars:

slide_6

Well those are the famous pillars but as you can always expect they talk about risk, development, mistake avoidance and schedule-oriented practices which is what we should be focusing on, and I

cropped
Continue reading "Rapid Development chapters 1-3"