Skip to main content

Daily Meetings - Coordinate and Communicate Every Day


Using daily meetings for frequent course corrections. However, you should keep the meeting short because time is burn rate.
Though good collaboration doesn't guarantee a project's success, poor collaboration almost always guarantees a project's failure
What benefits does the daily meeting bring to you?

- Keeps inexperienced developers and experienced ones on-track.
- Avoids reinventing the wheel.
- Limits tumbleweed developers' damage.
- Leverages the entire team’s experience to solve problems quickly.
- Improves team communication.
- Helps every people have a big-picture
point of view.

Who are tumbleweed developers?

We’ve all worked with a few tumbleweed developers. These developers lose direction and drift through their days. They wade through the random code and “improve” it, cleaning up method signatures, polishing algorithms, and reformatting brackets. Tumbleweed developers lack the discipline to finish any task you ask them to do and generally cause more harm than good.

Tumbleweed developers will retool your algorithms for speed, but their changes cause the code to generate wrong results. They’ll spend hours reformatting code to suit their preferences. Tumbleweeds have a collection of habits that they practice because it’s the “right thing” to do.

(I all cited the above fun description from the reference book below) 


Reference
[1]. Jared R. Richardson &  William A. Gwaltney Jr. | Ship It! A Practical Guide to Successful Software Projects.

Comments

Popular posts from this blog

BIRT - Fix the size of an image

I use a dynamic image as a logo my report in pdf. At the beginning, I use table to align the logo in left or right. I meet a problem with some images with a large width or height. My customer requires that the logo should be displayed in original size. These following steps solves my problem: 1. Use Grid instead of Table 2. Set Grid "Height" is 100%  and "Width" is blank 3. Set "Fit to container" for images are "true". Download the the template here .

The HelloWorld example of JSF 2.2 with Myfaces

I just did by myself create a very simple app "HelloWorld" of JSF 2.2 with a concrete implementation Myfaces that we can use it later on for our further JSF trying out. I attached the source code link at the end part. Just follow these steps below: 1. Create a Maven project in Eclipse (Kepler) with a simple Java web application archetype "maven-archetype-webapp". Maven should be the best choice for managing the dependencies , so far. JSF is a web framework that is the reason why I chose the mentioned archetype for my example. 2. Import dependencies for JSF implementation - Myfaces (v2.2.10) into file pom.xml . The following code that is easy to find from  http://mvnrepository.com/  with key words "myfaces". <dependency> <groupId>org.apache.myfaces.core</groupId> <artifactId>myfaces-api</artifactId> <version>2.2.10</version> </dependency> <dependency> <groupId>org.apache.myfaces.core<...

When we don't see the sun, we see other stars

What are your motivations for creativity? - I want to make a change. - It makes me happy! It is a need of my mind. How to be creative for a thing? There are two steps: - See the thing as every people see it - Think about a new different thing from it How to think about a new different thing? There are two ways: - Forget all things you have already known. - A whack on the side of your head. ;) This was what I have learned from the following great book: source: Amazon.com Well! A physical whack on the side of your head is needed sometimes but the meaning behind is that you need to break these 9 following locks on your mind. Remove them! The lock #1: "The correct answer" We all learn from schools that there is only one correct answer to a question. For example, a proposition is only true or false in Algebra. In reality, there are always some answers to a question basing on a point of view. For example, number 6 becomes number 9 if you look it ...

Avoiding Time-Wasting Pitfalls in Agile Estimation

If you do Scrum at work, you might be very familiar to the estimation in Planning 1 . My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated. I give you some advice from my experience: Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement. The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you do...

Why Functional Programming Matter

What issues do we concern when implementing and maintaining systems? One of the most concern is debugging during maintenance: "this code crashed because it observed some unexpected value." Then, it turns out that the ideas of  no side effects  and  immutability , which functional programming promotes, can help. Shared mutable data is the root cause Shared mutable data are read and updated by more than one of the methods. Share mutable data structures make it harder to track changes in different parts of your program. An immutable object is an object that can't change its state after it's instantiated so it can't be affected by the actions of a function. It would be a dream to maintain because we wouldn't have any bad surprises about some object somewhere that unexpectedly modifies a data structure. A new thinking: Declarative programming There are two ways thinking about implementing a system by writing a program. - Imperative programming: has...