Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

June 4, 2020

About software development methodologies

A while ago I've sent a question to James Coplien, one of the loudest voices of software development processes, methodologies and design.
Hello mister Coplien.

After some meetings regarding working processes and working methodologies for software, we've reached a point on asking what are the alternatives to the most know approaches (waterfall and agile processes).

Our group consists of people actively working on software development, testers, students, and college teachers. So, from our limited experience, we couldn't list too many approaches; we ended up with a commitment of digging into the topic and share our findings in our next meetings.

That's why I would be super thankful if you could recommend some resources (articles/books) on software development processes/methodologies.
To my surprise, he replied back with a great explanation:

Hej, Juan,Thanks for writing.

First: just to pick nits, “methodology” is a branch of philosophy which is the study of method. Technically, things like waterfall and XP are methods and not methodologies. Alistair Cockburn, who has developed a theory of software engineering, playfully likes to call himself a “methodist” rather than a “methodologist.”

A method is therefore a pre-packaged set of practices and processes suitable to design and implementation. One of the great learnings of the 20th century is that method doesn’t work. The architect Christopher Alexander has been one of the leaders of the Design Movement since about 1968, and is very familiar with the notion of method. He writes:

No one will become a better designer by ... following any method blindly... if you try to understand the idea that you can create abstract patterns by studying the implication of limited systems of forces, and can create new forms by free combination of these patterns—and realize that this will only work if the patterns which you define deal with systems of forces whose internal interaction is very dense, and whose interaction with the other forces in the world is very weak—then, in the process of trying to create such diagrams or patterns for yourself, you will reach the central idea of which this book is all about. — Christopher Alexander, “Notes on Synthesis of Form,” 1974

So it is not a matter of choosing between alternative potential approaches, but rather of transcending the whole framework of reducing design to method. No more than Michelangelo followed any method in making the statue of David or of painting the roof of the Sistine Chapel will method help any technical design activity.

Even within the framework of agile, there are those that believe that Man can triumph over the complexity of nature and that they can prevail using some method. XP is a very old example. SaFE is a newer example. The things that work dismiss this claim and open the doors to self-organization and feedback. That is true agile. True agile is incompatible with the fundamental notions of method.

This is why I am an advocate of Scrum. Scrum is not a method but rather a framework. If you want to explore the method space I’d recommend exploring Crystal and the works of Alistair Cockburn. Scrum and Crystal aren’t the only ones. But to find anything effective for complex development you must abandon method. Method is good for simple and merely complicated work — not for complex work.

What you have read is aa OK start, but I think you are exploring noise and need to dig deeper into some of the underlying theory before looking at experience reports like Scrum from the Trenches. If you want to know Scrum in depth, then get the new “A Scrum Book” (https://pragprog.com/book/jcscrum/a-scrum-book). That will help you understand Scrum. But Scrum is not a method, and I think you need to come to grips with the scope within which method works. Maybe you even need to come to grips with the taxonomy of design within which method is historically a relatively small part. Therefore, I recommend getting these books as well:

Design after Modernism: Beyond the Object, by John Thackara (https://www.amazon.com/gp/offer-listing/0500234833/)


Notes on the Synthesis of Form, by Christopher Alexander, 1974 printing (https://www.amazon.com/Notes-Synthesis-Form-Harvard-Paperbacks/dp/0674627512/ref=sr_1_fkmrnull_1)

There are many more, but this is a start. From where you seem to be at, you have many years of work to do before coming to any conclusion.
At this point, Alistair Cockburn (participant on the Agile Manifesto) got involved, and provided a lengthy response:
hi, Juan, Cope, 
I rarely like to disagree with Cope, but he is wrong twice here, and putting words in my mouth, so I feel somewhat obliged to step in. I'm afraid this is a long discussion, but one in which I have invested considerable research. Nothing of what I am about to say is "off the cuff". 
First because it is easiest : I am a methodologist, not a methodist. The "-ologist" refers unambiguously to "person who studies --".?? I study methods and methodologies (explanation of the 'methodology' in long form below).?? I am not a methodist, and never refer to myself as such. A methodist is not a studier of, he is a person who follows the rules of the method, in particular, a very rigid form of Christianity. So if I am anything, it is not a methodist :).
For those who wish to be pure, that "-ology" means "study of", I then insist that I am a "technologist" because my field is "technology", the study of techniques. Until the users of the English language repair the word "technology" to mean, as they imply from the suffix "-ology", study of techniques, then I feel no obligation to honor the false appeal to ancient Greek etymology for "methodology". But more on that in a moment. I am a "technologist" (studying techniques") or a "methodologist" (studying methods and methodologies), but not a "methodist" (a particular, very formulaic Christian religion)

For the second, "Methodology", Cope makes the usual vague reference to a false etymology based on ancient greek. For my PhD dissertation, I had to take on this question, I researched and tracked this word over a period of years and using different dictionaries. 
It is best that I don't try to re-write that research, but rather, show you that section of my PhD dissertation. 


1.1 Clarification of Words
With the word methodology being used in different ways by various writers, and often interchanged with the word method, I must clarify my use of the words in order for the rest of the thesis to make sense. 

Methodology

My use of the word comes from two sources: the Merriam-Webster Dictionaries and common usage among large contract software houses.
?????????????? The (U.S.-based) Merriam-Webster dictionaries list as their first definition: "A series of related methods or techniques." 
?????????????? When I sat in a discussion of methodology with a group of senior consultants from Coopers & Lybrand, Ernst & Young, Andersen Consulting, and the IBM Consulting Group, one of them stood up and said (words to the effect of): "Let's get clear what we mean by methodology. It is the roles, teams, skills, processes, techniques, tools, and standards used by the project team." The others in the room nodded their heads, and the meeting proceeded. As one of the senior consultants later told me, "If it is what one or two people do while working on a task, it is technique. If it is what the team uses to coordinate their work, then it's methodology."
Those two meanings of the word are congruent and match the common use of the word. 
Many British and continental European speakers dislike the above definition, preferring to use the word method instead. They cite the (U.K.-based) Oxford English Dictionary, which in the early 1990s contained only one entry for methodology: "study of methods." This explains the cultural difference in usage. However, the 1995 Oxford English Reference Dictionary includes in the entry for methodology: "2. a body of methods used in a particular branch of activity." Both American and British dictionaries now agree on the subject.

Method

The Merriam-Webster dictionaries define method as a "systematic procedure"; that is, similar to a technique. This matches the way many European speakers and European research literature uses the word method. An example, from Mathiassen (1998), is the following:
Lesson 2: Methods are primarily frameworks for learning.
The intention behind Mathiassen's word method is quite different from my intention for the word methodology. Mathiassen writes method to connote what one or a few people are learning to use, usually as a technique. This learning eventually disappears into the background skill set of the practitioner. 
In contrast, I write methodology to connote the conventions people agree to across the team (including development techniques). While the techniques disappear into each person's skill set, the conventions in play do not disappear into skill sets. 
We shall need both words to complete the discussion. This thesis primarily addresses methodology rather than method.

Shifts in Meaning

As the research took place over a ten-year period, there were several minor shifts in the way the word methodology got used, as well as some shifts in the way the practitioner community used the word. I deliberately leave in place some of those shifts, because readers will come to this thesis with their own personal interpretations, and part of the thesis topic is dealing with those personal interpretations. 
The first research question, for example, asks: "Question 1: Do we need yet another software development methodology, or can we expect a convergence and reduction at some point in time?" In this question, I do not mean just, "Do we need yet another set of team conventions, or can we expect a convergence and reduction at some point in time?" Rather, I accept the fluid way in which people ask the question, which often includes, "Do we need yet another software development technique, or can we expect a convergence and reduction at some point in time?" The answer that I develop responds to both versions of the question. Research question #2 is handled in a similarly liberal way.
However, by the time we reach the third question, "Question 3: How does the methodology relate to the people on the project?" the meaning narrows. It is quite a different question to ask, "How does a techniquerelate to the people on the project?" That question has to do with introducing techniques into groups, as well as the relation between technique-in-theory and techniques-in-practice (the latter topic being well discussed in the Scandinavian literature, see Ehn (1988) and Mathiassen (1998)). In the context of this inquiry, it is relevant to use the narrower meaning, "How do the team conventions relate to the people on the project and other aspects of life on the project?"??

I found these replies and explanations extremely good, especially to someone trying to get more information about software development processes, so, I wanted to make them public because they might be useful for someone else.

Additionally, I've never expected a reply, it's great to know that knowledge can be shared and guidance can be provided despite the name, profession, location or expectations, thank you James and Alistair for your time.
 
My recommendations:

September 10, 2014

This is where I work

Disclaimer: Draft from a long time ago.

Back in December of 2009 I was preparing my thesis work for my graduation, and somehow a very funny guy called me saying that we have talked a while ago about a job offer in a software development company.



At the beginning I was thrilled, I hadn't worked in a professional way by that moment, I couldn't talk nor understand English properly and I was very insecure about my skills against the European standards.

But then I found out something, these guys were really interested in personal values above all, they might need skillful people, but it wasn't (and I dare to say it still isn't) the most important thing.

We were a very small group, now a little bit larger, doing things I found challenging. There are several goals I have set for me in this workplace, I like working there, I enjoy the work I'm doing and the people whom I working with.

Perhaps you want to take a look at the website to know the company a little bit ;-)

June 23, 2012

Ruby disappointment

I have been trying to port some work I've done in Java to Ruby, to see how it looks and how much code it would take. But in the way I found out that Ruby might not be the best option for this kind of situations.

Let me explain it, this is my pseudo code:



As you can see, the OrderSet has a collection of Order classes, but classes!! Not instances, because in the real application I will have hundred of Orders and I don't want to instantiate a new object for each one of them.

So to keep the memory load very low I handle classes, in that way I can control them, instantiate them and destroy them as much as I want.

Now, I tried to write it in Ruby, but I found out that there's no easy way to add metadata at a class level!!
The closest approach to it that I could find is instance-oriented. I would need a new instance of every Order to make it work....sad.

March 30, 2012

Jogging for fun

As a software developer and avid reader, I tend to spend a lot of time sitting or laying down in a bed. And this is normal for my life, I would say that at least 10 hours in my normal day are based literally on my ass.

When I started working I noticed this, and I knew I had to do something to keep my body as trained as my hands and brain were. So I decided to go back to an old costume I adopted while I was writing my thesis... jogging.



Jogging is a very simple discipline where you set a target destination and run at a certain pace, fast enough to not be walking, slow enough to keep your stamina.

The benefits

These are personal facts, that might not apply to everybody:
  • Relaxation, it keeps you away from your daily problems for some hours, clearing your thoughts and mind.
  • Concentration, well... you need it, you have to control your legs, your breath, and your speed while checking what's in your way.
  • Fitness, it keeps your middle-body in a good shape, if you do it regularly.
  • Discipline, you need a lot of will to jog when it's raining, when it's cold, when it's hot. 

How much?

After some years of irregular practice, I have set my jogging sessions to 30-45 minutes, it could be longer, but definitively not shorter.

What about the speed?

It depends completely on you, when I haven't done anything for a while I have to recover the muscles and pace I start slowly and then increase the speed day by day. As a metric, use your breath, if you get too tired or just too agitated, you might need to slow it down.

How to keep it interesting?

It could get bored, specially if you follow the same route for several days in a row. What I enjoy doing is listening to some podcasts while running, or perhaps some music. For this situation a portable iPod is the best choice.

January 19, 2012

Fossil SCM

A few months ago I listened to FLOSS Weekly's episode about SQLite, and I wondered how this wonderful project was being managed.

After checking for a while, I found that D. Richard Hipp has developed his own distributed SCM based on the very reliable SQLite.


In a comparison with Git and Hg (which I have used), it is more than a SCM, it is a whole project-development space. Some of its features include:
  • Bug Tracking And Wiki, really cool.
  • Web Interface, incredibly simple.
  • Autosync, still wondering what its benefits are.
  • Self-Contained, yep, everything in one binary file.
  • Simple Networking.

As a developer of some internal projects, it's really hard to keep track of my bugs an issues, and the environment required for it costs too much. But this amazing project does it for me!

Its use is very similar to any distributed SCM and the installation/configuration is barely present. I totally encourage you to try it.

September 27, 2011

Code freeze

When you are developing something in a constant pace and everything is moving smoothly, how do you test?

Do you stop coding and then test what you've done? and then go back to code?



This may work for some people, but I struggle when I have to multi-task (this does not apply for TDD) and some of the people I know have the same feeling.

A while ago I worked in a project where there was a 'code freeze' day, in this day nobody could commit anything to the repository and everything you had to do was to test and register the bugs you've found.

This was something conflictive for us, our how development model was to produce something and to deliver as soon as possible, trying to fix the bugs as soon as they were registered.

Advantages

  • One of the advantages we found using this practice was that the bugs were found faster.
  • We could plan and estimate all our bugfixes.
  • All bugs were easily reproducible.
  • All bugs were registered and assigned properly. 
  • We switched roles, for one weekday we turned into testers (and loved the idea of relaxing while working).
Interesting links

September 26, 2011

Robert C. Martin: Programming Languages

Robert C. Martin has been an authority in computer science for many years, most of his work and publications are taken as must-do in Software Engineering.

Here we have it at RailsConf giving us an history lesson about Programming Languages and the evolution of computing science.


March 12, 2008

Fedora Transformation Pack


Via vivalinux me entero de la salida de un pack de software que nos brinda la posibilidad de cambiar la apariencia de Windows, haciendo que se parezca a la popular distribución de Red Hat, mediante Fedora Transformatio Pack(descarga).


El tiempo dirá si logrará tener el éxito de Ubuntu Transformation Pack.