Friday, February 14, 2014

Agile Horrors ...

See at Mike Griffiths site:
http://leadinganswers.typepad.com/leading_answers/2013/12/agile-horrors.html


"Frankenstein Process – This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment."

 Waterfall strike back ... An "traditionalist" PM will always want a such kind of schedule, because it is part of the Waterfall mindset.

"Vampire Scrum Masters and Project Managers – These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Process compliance & not removing impediments ... these kind of managers want an easy "safe & comfort zone" where they are fully protected: no real decision, just blindly following the rules - case when they think that will be always infallible. Right ...

Velocity ... it is in fact a Gold Rush where the only gold it is the fools gold. In fact it is just a cheap slyness. It will work for some period and then will start to fall.
In fact, these are very generic habits. The horror for Agile case is that here it are some fundamental rules such: remove the impediments and refactor (a particular case of removing the impediments).

Sunday, February 9, 2014

Agile Engineering - Refactoring: The Questions

Refactoring, TDD and Solutions Spikes are most known engineering practices that are fundamental for an Agile process.

Refactoring - "…is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." AND "Refactoring is a controlled technique for improving the design of an existing code base." (Martin Fowler)

Question 1 - Why we need Refactoring in Agile Development?

... and for the ones that have the answer to the first question

Question 2 - It is enough to refactor in order to enable agility? What other practices could help? (other then TDD and solutions spikes)

Oath of a Clean Coder (cloned from Hippocratic Oath)

As you see in the previous post, Uncle Bob has a list of expectations from the software professionals. He use also the term Clean Coder to describe a such professional. He also says that our life will depend more and more on software, and for this reasons "We need to be!" professionals.

Our life.

It is the same thing as in the healthcare domain. Even the healthcare is depending more and more on software. The physicians take the Hippocratic Oath , beyond any other rules and official laws. Why? Because it is important. What about the software used by these physicians? This Oath has no effect for the software...

We will need a similar Oath - a kind of Clean Coder Oath:
(Note - In fact, Martin book Clean Coder start (some years before this post) from the idea of Hippocratic Oath and present a code of conduct for the professionals developers. )
I swear by Apollo, the REFACTORER and Hephaestus, and I take to witness all the gods, all the goddesses, to keep according to my ability and my judgment, the following Oath and agreement:

To consider dear to me, as my parents, him who taught me this art; to live in common with him and, if necessary, to share my goods with him; To look upon his children as my own brothers, to teach them this art; and that by my teaching, I will impart a knowledge of this art to my own sons, and to my teacher's sons, and to disciples bound by an indenture and oath according to the ENGINEERING  laws, and no others.

I will prescribe DESIGN for the good of my SOFTWARE according to my ability and my judgment and never do harm to ANY CODE.

I will give no SPAGHETTI CODE to any one if asked, nor suggest any such counsel [...]

But I will preserve the purity of my life and my arts.

I will not cut for BUG, even for SOFTWARE in whom the ERROR is manifest; I will leave this operation to be performed by practitioners, specialists in this art.

In every SOFTWARE house where I come I will enter only for the good of my CODE, keeping myself far from all intentional ill-doing [...].

The main question is: how many times we have break such rules and principles? How many times the programmers start to "cut"  or build parts that are beyond their skills? How many times the programmers have delivered a (too) bad code?  How many time the programmers have harm the code?
Too often ...


Tuesday, February 4, 2014

Are we professionals? (1)

If...
... Robert C. Martin will be your new CTO, then his first question will be:

Are we professionals?

His answer is:

We need to be.

Here is a list of what the professionalism demand in his view:

I Expect...

...We will not ship shit.
...You will always be Ready.
...Stable Productivity.
...Inexpensive Adaptability.
...Continuously Improvement.
...Fearless competence.
.. Extreme quality.
...QA will find nothing.
...We cover for each other.
...Honest Estimates.
...You to say "No".
...Automation!
...Continuous Aggressive Learning.
...Mentoring.


I will post the source later. Please try this exercise:
  • try to find the motivations behind each of these sentences
  • try to find yourself the source... maybe you will find more interesting subjects from "Uncle Bob".