Archivi categoria: software engineering

Non aspettiamoci grandi cambiamenti

Quale sarà la prossima ricetta per migliorare lo sviluppo software? Quali nuovi approcci e tecnologie risolveranno tutti i problemi irrisolti?

Abbandonate le speranze, afferma Bob Martin, il tempo dei grandi cambiamenti è trascorso, la nostra disciplina è maturata. Possiamo aspettarci qualche ulteriore miglioramento, ma non più le rivoluzioni del passato.

Progress in software has followed a logarithmic growth curve. In the early years, progress was stark and dramatic. In later years the progress became much more incremental. Now, progress is virtually non-existent.

Look: Assembler was massively better than Binary. Fortran was much better than Assembler. C was a lot better than Fortran. C++ was probably better than C. Java was an improvement over C++. Ruby is probably a bit better than Java.

Waterfall was a whole lot better than nothing. Agile was better than waterfall. Lean was a little better than Agile. Kanban may have been something of an improvement.

Every year. though we apply massive effort, we make less progress than the year before; because every year we get closer and closer to the asymptote.

Ora, aggiunge, è semplicemente ora di mettere in pratica quello che si è imparato. E soprattutto di farlo in modo professionale.

We need to realize that we have hit the asymptote. It’s time to stop the wasteful churning over languages, and frameworks, and paradigms, and processes.

It’s time to simply get down to work.

We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.

The Churn, di Robert C. Martin.

Agile, con disciplina

Processi agili e CMMI possono integrarsi? Quando è opportuno farlo? Un numero monografico della rivista sul software dei militari USA discute quando, come e perché: http://www.crosstalkonline.org/storage/flipbooks/2016/201607/index.html (Crosstalk, Jul/Aug 2016).

Dall’articolo introduttivo:

“CMMI and Agile can be used together successfully. CMMI provides the ideal framework for managing and continuously improving our organization’s processes.

Agile Scrum provides a new lifecycle development model that yields a better fit for many of our projects over the traditional waterfall model, driving greater customer interaction and employee investment.

Both frameworks have provided value to the organization when we embraced them intelligently. When the best practices from both models are thought- fully applied to the right project, it is possible to do CMMI the Agile Way.”

Microservices

Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:

  1. Rapporto tra microservices e SOA (Service Oriented Architecture). I microservices sono solo uno dei modi in cui la SOA può essere organizzata: senza bus centrale (Enterprise Service Bus), autonomi ed indipendenti.
  2. Organizzare lo sviluppo per microservices significa, prima di tutto, definire e attuale un modello organizzativo in cui ogni team lavora in modo indipendente. A occhio, maggiori sono le dimensioni del team di sviluppo, più questo modello organizzativo è sensato.
  3. I microservices hanno senso per fornire servizi di business completi. Avrebbe meno senso definire microservices puramente infrastrutturali.
  4. Per lavorare a microservices bisogna avere già una forte competenza sulla materia, sul dominio applicativo. Se questa manca, meglio sviluppare prima un monolite e poi, se opportuno, ristrutturarlo estrapolandone i microservizi.

Persone, prima dei processi

Crosstalk, rivista software dei militari USA, notevole.

Sul numero Mar/Apr 2016, in “People-driven vs. Process-enabled Software Development: a 21st Century Imperative”, c’è la motivazione più chiara che io abbia letto sul perché è più importante la scelta delle persone rispetto al processo di sviluppo. Che al massimo può evitare di rendere difficile la collaborazione tra chi partecipa al lavoro.

Lo diceva già il Manifesto Agile del 2001, sono più importanti “gli individui e le loro interazioni, più che i processi e gli strumenti”.

E prima ancora l’ottimo “Peopleware” di DeMarco e Lister (mai tradotto in italiano!) aveva spiegato che il fattore più importante nello sviluppo software sono le persone, e il modo in cui interagiscono tra loro.