Agile Methodology – Some comments
I couldn´t agree anymore with Agile basic concepts, as summarized
in the Agile Manifesto ( http://agilemanifesto.org/ ).
But I think that some Agile Developers underestimate the
value of Software Engineering tools, mostly Business Process diagrams and UML
diagrams. I think that this could –
sometimes should – be used not as “documentation”, as something built after the
software has been built, but as “project” – something that will guide the
development! To me, it makes as many
sense to start to code without a
project, as it would be to start to build a house without a plan!
On the other hand, the fact that Agile Methodology clearly
states that “it´s impossible to collect and specify all requirements” is a
remarkable insight. This fact must be accepted
and all software developers must learn how to deal with it. It´s up to the experienced Systems Analyst to decide when enough requirements has been defined, when the essence of the application has been defined - and start developing, leaving accessory features to be detailed later.
The concept of “frequent deliveries” is also awesome. It keeps the development team focused, maintain
users engaged, build a strong link between developers and users and avoid
deviations from the actual goals.
Some tools we learned to use – backlogs and charts, for
example – are a perfect support for this “frequent delivery” approach. I´m already using this in other courses´
projects.
The auto-managed team, working physically close and constantly
sharing issues and achievements, is a strong point of Agile methodology. This does not leads “just” to better software –
it results in more responsibility over team member´s shoulders - and in more freedom, more fulfillment, in a better and happier professional
life!
Regarding the concept of “multidisciplinary teams”: I agree that a developer must know how to
test; that a database designer shall know how to build a user interface – and vice-versa. And I
agree that a developer must be able to use more than a single language and/or
environment development.
But I think that this can lead to a team composed by “jack-of-all-trades”
technicians, who know a little bit of many things but not much of any. I do believe that in order to build good
applications, good information systems, you do need specialists. People who deeply know all features of the
tools you are using – database engine, web servers, programming language… In my opinion, none of the specialists shall
live in a “bubble”, knowledge can and shall be transferred. But a team needs highly qualified
specialists.
I´ll dare to express some personal opinions:
According DZone[1], “In
1994, Standish reported a shocking 16 percent project success rate, another 53
percent of the projects where challenged and 31 percent failed outright”.
This is really shocking.
Are we developers that bad? I
would say that, in average, yes! Some of
our failures are poor or incorrect user requirements survey and specification,
poor design, lack of technical specifications and – last but not least – lack of
knowledge of the development tools. Some
developers even claim that using software engineering tools is useless, just a loss
of time, because even using them the software will still be flawed. Yes, when they tried, this happened – because
they don´t know how to use software engineering tools correctly. The issue is not in the tool, not in the
methodology – is in the lack of knowledge of the developer!
NOTE: you can see also "The Standish Group Chaos Report" ( http://www.projectsmart.co.uk/docs/chaos-report.pdf ) for more about software projects.
NOTE: you can see also "The Standish Group Chaos Report" ( http://www.projectsmart.co.uk/docs/chaos-report.pdf ) for more about software projects.
I would say that, regarding development tools, we are
better. Most of us are good coders. But some current management concepts are also
undermining this.
The truism that “who is able to code in one language can learn
in any other in two weeks” is repeated as a truth evident in itself. It can be true if – and this is a big “if” –
the language paradigm is the
same. If not, yes, you can learn to code
“something” in two weeks. Something that
will probably fit in the 85% of “challenged” or “failed” projects.
Again – we do need specialists, we do need mastering our
tools! You can work with Oracle, or SQL
Server, or C#, or ASP.Net, or MVC .Net, for years, and do not know 100%, not
even 80%, of these tools´ resources. You
can´t call a two weeks experiment “learning” something like these! A college course, one semester using the tool
– that´s a beginning! That´s when you
are ready to start to use it professionally!
In my personal experience, mostly with some younger colleagues
(yes, there are exceptions, some young developers are amazingly proficient in
the technologies they use, I´m just talking about the “average”, the “majority”,
that I´ve seem) are able to build a new application´s framework very
quickly. And then they got stuck. Their knowledge is too superficial to enable
them to develop the more sophisticated requirements. Using again the analogy with building houses –
it´s easy to build the walls, the roof.
But you can´t live in a house without the electric wires, the plumbing… With software, sometimes our users have to
live with light of lanterns and buckets of water.
Even when things do work, frequently the developer is not
aware, or is not able to explain, how it works!
This is not a comfortable situation! I don´t think this is acceptable! Yes,
software development has a component of “art”, “creativity”, but it is also
science, it´s engineering, and an engineer does not “guesses” nor "hopes", an engineer “knows”!
The Solution?
I think we shall adhere to Agile principles, but reverse the
tendency (understandable tendency, a turn-around from extremely rigid "waterfall" was needed) to reject software
engineering tools.
We should also select one or two developers in each team to
be “the guys” for each requirement – database, web security, business process survey,
etc. Everyone must be able to do the “elementary”
work in every area – but we need Subject-Matter Experts.
We should respect our tools.
Before we start to build a new project with a new programming language
or development tool, we need to read about the basic concepts, about the paradigm. We should meet – physically or virtually –
some experts in this new tool. We should
try to develop something simple with the new tool – preferably something which
we already developed with one of our favorite “old” tools. Then, maybe, we´ll be able to start some “real life”
development.
A last word, about maintenance.
I think that in some few cases, it´s evident what is wrong
and (in even fewer cases) the error is very isolated. Those are the (rare) cases when it is quick
and easy fixing something, even if we are not familiar with the application.
I think that, as a general rule, in order to maintain an
application which with we are not familiar, we should act as physicians – “primum
non nocere” , “first, do not harm”. And
to “do not harm”, we need to understand the application. If it is not documented, we should create
some documentation. We should try to
understand how it has been built, what the developers who did build it had in
mind.
And, of course, we most domain the language (and/or
framework) which the application has been built with.
Without these precautions, we would be not software
developers doing maintenance, we would be just agents of the entropy!
No comments:
Post a Comment