Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Sunday, March 27, 2011

Developer Driven Development

Very provocative presentation about Leaner Programmer Anarchy

in a word: only the Customer and the Developers stand after we eliminate everything else. Developers negotiate and discuss directly with the Customer.

Having been a freelance developer in Italy for some 8 years, that's the way I was operating, with a much much higher productivity than normal management/analyst-mediated development model.

Who need an analyst anyway, ideas in the head of an analyst have to be transferred to a developer, and this takes time and commitment (the second is much more difficult to find).

Who needs also those unnatural "user stories", and the dissecting of an application into minute subtasks... most of the times, you conceive and implement an application in its entirety, not as small subtasts. Things are much more interrelated than can be captured in a Microsoft Plan.

Thursday, January 13, 2011

Designing and Modelling vs Coding

This is my 2 cents wisdom on the oldest topic on IT: should you DESIGN AND MODEL everything upfront, or should you just CODE IT and refactor it as you progress in the task?

I have no doubt that IT work is like LIFE - in the biological sense of it:

a LOT of microchoices made IN ACTION, a continuous adaptation to an EVER CHANGING WORLD, but with a few important principles to guide us: ROBUSTNESS, ABILITY TO REFACTOR AND RECYCLE, AGILITY IN CHANGE, ABSOLUTE CLARITY IN INTERFACES AND CONTRACTS.

Any living creature is designed with these same principles. Some strange creatures do live without any agility (PANDAS), but often they are doomed for extinction as the environment changes. The key to the success of human as living creatures is their ADAPTABILITY.

Emotions play en enormous role in a project. Enthusiastic people achieve so much more that bored, 9-5 workers waiting only for Friday 5pm to come. And NOTHING motivates people more than SEEING ACTUAL WORKING CODE, and being able to model it and improve it.

So my motto is:
while (not (dead or retired) ) {
  analyze a little; 
  design a little; 
  code a little; 
  test a little;
  thread.sleep(8 hours);
  randomly enjoy your life outside the computer world;
}


Wednesday, November 3, 2010

Agile is as old as the mountains

I have read with pleasure this article on the lives of illustrious programmers.

Also available here

I found this sentence particularly intriguing:

Most of these programmers had (and have) a programming methodology that today would be called Agile. They mostly created a prototype that worked, and kept adding functionality until it was ready to ship. They worked iteratively in small teams. And, as Bricklin's current thoughts indicate, these developers were always cognizant that at some point you have to quit adding to the software and send it out the door. I found myself wondering how many readers imagine that "Agile" is something new.

Agile Methodologists try to teach us what - when left alone to self-organize our work - we have been doing for ages, out of "professional instinct" - that is the shortest path to success.

Agile, old as the mountains.

 I have listened also this presentation, very critical and well formulated. Still, I keep thinking that all these Agile practitioners are extremely verbose and religious.

Jean Tabaka and "I don't like Mondays". It was quoted by this article on Neuroscience.

This is one of the books recommended.
And this.

Monday, October 4, 2010

Clean Code - a handbook of agile software craftsmanship

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

The PDF is also available here for free:

http://knowfree.net/2010/10/clean-code-a-handbook-of-agile-software-craftsmanship




I have started reading it and it's really enjoyable and witty - which doesn't happen very often in IT books :o(

I am reproducing on of its images, hoping  that OSNews http://www.osnews.com/ will not mind...



For a definition of Craftmanship : "emphasizes the coding skills of the software developers themselves"

Here is their manifesto, I like it http://manifesto.softwarecraftsmanship.org/

I myself believe that the main criterias to evaluate code are:
- is it readable and easily modifiable?
- are build, test and deployment fully automated with a CI tool?
- is it fully covered by multithreaded automated tests?

One more thing I have to say: I am appalled that 90% of the times automated tests are executed with a single client thread... I have seen too many times multithreading issues surface during the first phases of a live application.

Friday, September 24, 2010

Alistair Cockburn on Agile: it's the people that matter

http://www.infoq.com/news/2010/09/cockburn-interview-part2

Alistair's company is:
http://icagile.org/

These quotes are distilled wisdom! An Agile coach warning against turning Agile into a religion, and putting the focus on the Manager responsibility to knit people together, and interpersonal chemistry...

"small, colocated development team: frequent delivery, reflective improvement, osmotic communication"

"pay attention to people in the design process, and to fine-grained, end-to-end feedback (typically accomplished through shorter iterations)"

"The utility of the term "agile" is not yet done, because people still too quickly drift into process religions or mathematical dreamland and forget that our industry is built on people getting together, inventing and deciding as they go. I repeat yet and yet again: people, human people, with all their weird characteristics. Math and process are relevant, but soooo much easier than dealing with the actual people in front of us."


"All the theory in the world does not guarantee that people will work well together. Individual people have strange effects on each other – either increasing trust or trigger unexpected angry outbursts."

"We still make decisions unconsciously in our teams and organizations, we don't discuss how we come to decisions, and we don't discuss alternative ways to make decisions."

"It is all too easy for any manager to lean on a process to improve output, rather than to develop his or her personal skill in knitting together the people across departments."

Monday, September 20, 2010

The Agile Antimanifesto (or the antiagile manifesto)

Many years ago, I had the misfortune of working in a project where people spending all their day on Online Sudoku and Facebook had the guts to call themselves "Agile". It was one of the most painful experiences of my life, seeing systems being abused, and chaos and approximation rule unconstrained.

I was eventually kicked out of that project, because I was challenging the general misconception of Agility, and the firing manager told me "it's not enough to be right" (maybe he meant: you must also be a sneaky politician and a sycophant). That taught me a lesson: if you want to keep your job, always smile and say yes, even if the Titanic he heading full speed towards an iceberg.

I am not anti-Agilist, I simply believe that "Agility" require extreme competence, coordination and organization, rigorous control and discipline; too often, Agile is an excuse to be slack.

When left in the hands of the wrong people, Agile becomes a Religion, and Religion has never made a project successful AFAIK - unless your target is the transfer of wealth from the Poor to the Elites, which is mostly what religions are for.


Hence here is my Agile Antimanifesto.

We are Agile, therefore we don't send emails so at a later stage you cannot use that email against me

We are Agile, therefore if you resist to a last minute change to be put in production without any test, it means you are lazy and un-agile .

We are Agile, therefore we can change architecture every week and make you work every day until midnight re-implementing the same functionality in 10 different ways, and then blame you because you have delivered late.

We are Agile, therefore we delegate all the analysis to the developers without even providing any guidelines. Then blame them because them didn't implement according to the guidelines which exist only in our head - or don't exist at all, we are too agile to elaborate guidelines.

We are Agile, therefore we go to all meetings and you must read our brains if you want to know what was decided; we will never inform you, we are Agile which means you must be Telepathic.

We are Agile, therefore we don't need to work hard.... as we are Agile, we do all the bla bla and you do all the work. We are Agile and Smart, and Smart people work Smart, not Hard. That is, we don't need to work at all, all we need to do is to say "Agile" once in a while and delegate everything.

We are Agile, therefore we don't need to do any analysis, we will improvise everything along the way; an Agilist God will inspire us and miraculously turn Chaos into Order at the end. We don't design anything and don't publish blueprints, one day they could be used against us and this is not Agile.

We are Agile, and if we put the word Agile in every sentence we don't need to give any rational answer to your objections. Actually we don't even need to listen to you, because if you object you are not Agile.