A joyful programming episode

On the joy of writing a mix of code with PowerShell, YAML, .NET, XML, and XPath. It was a lot of fun.

The task at hand is to write a simple preliminary version of a PowerShell script to create some AWS CloudWatch LogGroups and related LogStreams. The input is an AWS CloudFormation template YAML file. This template file helped before to create the required CloudWatch resources, but now the need is to create the same resources by calls to the AWS CloudWatch Logs API. At execution time, at an AWS EC2 instance, the required PowerShell 7 script will call AWS CloudWatch Logs API by means of the AWS Tools for PowerShell already installed at such EC2 instance, which has attached an AWS IAM Instance Profile with the required permissions.

Curious thing, though, the PowerShell Cmdlets to parse and query the YAML template data were not found as quickly as the Cmdlets to parse and query other common file formats (JSON, XML, CSV, etc.).

PowerShell 7 can load and execute code in .NET Assemblies (given the proper match on targeted .NET CLR). There is, e.g., YamlDotNet package to parse YAML files, but an initial try of it directly from PowerShell was not as straightforward as expected. Nevertheless, that same package could be used from a custom .NET Assembly that would render the YAML content transposed as another serialization format already known to familiar PowerShell Cmdlets. The first use case for such custom .NET Assembly would be like the following test case in an executable functional specification:

 

The System Under Test (SUT) is the .NET class named yaml, which encapsulates the access to a YAML parser (deserial method) and to the rendition of the CloudWatch Logs resources data transposed as XML serialization format version 1.0 (AsXml_1dot0 method). This AsXml_1dot0 method can be wrapped by a .NET Console host and invoked from a PowerShell script. The output of that call to the AsXml_1dot0 method can be parsed and queried by Select-Xml Cmdlet.

Next is a general idea for the .NET Console host wrapper for the AsXml_1dot0 method:

 

Before getting into the general layout for the required PowerShell script (Create-CloudWatchLogs.ps1), first let’s see next a basic layout for its invocation and its output:

 

Also, next is the related input file CloudWatchLogs.yml (an AWS CloudFormation template YAML file) with the data for the resources to be created:

 

Now, the executable functional specification, so far, includes the case to transpose from a YAML map data type to XML. The YAML file in this case contains only map type instances, but for the case of YAML seq data type, next is an initial test case into the executable functional specification:

 

And, next is an initial test case for the case of YAML str data type:

 

Furthermore, next is a test case for YAML map and YAML seq data types combined:

 

Next is the general layout of the required PowerShell script Create-CloudWatchLogs.ps1:

 

I especially enjoyed the craft of those XPath expressions; it has been a while since my last time with XPath.

Finally, next is the current initial implementation of the yaml class with the parsing and transposition of YAML into XML:

 

Know your design tools — The Performing Half-baked object case

Among other important paradigms in software design, object orientation is a common set of design techniques these days. Hierarchies of classes, derivative class instantiations and virtual calls can be often found on software codebases. Hence, the relevance of the Performing Half-baked object case while designing object-oriented software.

The Performing Half-baked object case occurs where a virtual call is executed onto an unborn or uncreated or uninitialized class instance: the actual behavior can be unexpected, of course.

A couple of examples.

Consider the output of this Windows/Visual C++ code:

#include <iostream>

class AA
{
    public:
    AA()
    {
        std::cout << "AA()\n";
        f();
    }
    virtual void f() { std::cout << "AA.f\n"; }
};

class BB : public AA
{
    public:
    BB()
    {
        std::cout << "BB()\n";
        f();
    }
    virtual void f() { std::cout << "BB.f\n";}
};

void main()
{
	auto x = new BB;
}

For another –different– behavior, consider the output of this .NET/Visual C^# code:

using static System.Console;

class AA
{
    public AA()
    {
        WriteLine("AA()");
        f();
    }
    public virtual void f() => WriteLine("AA.f");
}

class BB : AA
{
    public BB()
    {
        WriteLine("BB()");
        f();
    }
    public override void f() => WriteLine("BB.f");
}

class Program
{
    public static void Main()
    {
        var x = new BB();
    }
}

The Performing Half-baked object is a case that designers of object-oriented languages and runtimes have typically faced. Any designer using those languages and runtimes should be aware of this and other cases during the process of object creation.

Singleton in .NET

If I need a process-level global write-once/read-many state, a global variable, a Singleton, in .NET Runtime, then I keep in mind what I said at the post: Know your design tools — The Singleton case.

It is also relevant to keep in mind:

1. the Visual C^# language specification about Static constructors,

2. the section on Static Constructors of the Visual C^# Programming Guide,

3. the description of what BeforeFieldInit does, and

4. the category (Performance) and the 'When to suppress warnings' section of the CA1810 Rule.

The observations on that old post have been useful for me over the years. Specially while designing stateful software services, where the use of locking, global state, global variables, or Singletons do not hinder throughput. On the other hand, in the context of stateless software services processing a high number of concurrent requests, whose scalability is very important, then –to be clear–, I do not prefer any explicit use of locking, any global state, any global variables or any Singleton.

Here is a demonstrative version of a .NET/Visual C^#-based Singleton derived from the sample code of such old post and a couple of MSTest test cases as evidence of its correctness, included post-conditions for same class instance and for same global value:

#region SUT
/// <summary>
///  https://docs.microsoft.com/en-us/archive/blogs/marcod/know-your-design-tools-the-singleton-case
///  https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#static-constructors
///  https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors
///  https://docs.microsoft.com/en-us/dotnet/api/system.reflection.typeattributes?view=net-5.0
///  https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1810
/// </summary>
public sealed class TimepointSingleton
{
    #region Nested static class with access to private outer instance constructor.
    public static class Timepoint
    {
        private static readonly TimepointSingleton instance;

        static Timepoint()
        {
            instance = new TimepointSingleton();
        }

        public static TimepointSingleton Instance { get => instance; }
    }
    #endregion

    #region Outer class for instance-level members of Singleton.
    private DateTime point;

    private TimepointSingleton()
    {
        point = DateTime.Now;
        WriteLine("Timepoint acquired");

        //This simulates resource contention to better
        //show up the multithreading problem when no
        //proper thread synchronization is in place.
        Thread.Sleep(4000);
    }

    public DateTime GlobalTimepoint { get => point; }

    public override string ToString() => $"{GlobalTimepoint:s}";
    #endregion
}
#endregion

Test cases (MSTest) as evidence of the expected and actual behavior:

[TestClass]
public class SingletonSpec
{
    [TestMethod]
    public void two_reads()
    {
        //Arrange
        TimepointSingleton a = null;
        TimepointSingleton b = null;

        //Act
        a = TimepointSingleton.Timepoint.Instance;
        b = TimepointSingleton.Timepoint.Instance;

        //Assert
        Assert.IsNotNull(a);
        Assert.IsTrue(AreTheseTheExactSameObject(a, b));
        Assert.AreEqual($"{a}", $"{b}");

        static bool AreTheseTheExactSameObject(object a, object b) => object.ReferenceEquals(a, b);
    }

    [TestMethod]
    public void concurrent_reads()
    {
        //Arrange
        int read_count = 15;
        using var sync = new ManualResetEvent(false);
        var reads = new ConcurrentBag<string>();
        var instances = new ConcurrentBag<TimepointSingleton>();
        var threads = Enumerable.Range(0, read_count).Aggregate(new List<Thread>(), (whole, next) => { whole.Add(new Thread(operation)); return whole; });

        //Act
        threads.ForEach(t => t.Start());
        sync.Set();
        threads.ForEach(t => t.Join());

        //Assert
        Assert.AreEqual(read_count, reads.Count);
        Assert.IsTrue(reads.All(read => string.CompareOrdinal(read, $"{TimepointSingleton.Timepoint.Instance.GlobalTimepoint:s}") == 0));
        Assert.AreEqual(read_count, instances.Count);
        Assert.IsTrue(instances.All(instance => object.ReferenceEquals(instance, TimepointSingleton.Timepoint.Instance)));

        void operation()
        {
            WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {DateTime.Now:s} Started");
            sync.WaitOne();
            var global_state = TimepointSingleton.Timepoint.Instance;
            reads.Add($"{global_state}");
            instances.Add(global_state);
            WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {DateTime.Now:s} Instance value: {global_state} hash: {global_state.GetHashCode()}");
        }
    }
}

Freethinking and free inquiry about software creation

I very much enjoy computer programming. I also enjoy reading authors that talk about it from diverse perspectives. Just as much as practicing philosophy and reading whoever author that talks about philosophy —taken as the basic human impulse to go deeper into what causes doubt and wonder.

So far, I would say that some mechanical and tedious tasks related to computer programming are no longer a major challenge because we now have a lot of good tools helping with those tasks. On the other hand, the intellectual challenge of computer programming remains as a major challenge even today. Of course, now many good lessons are at reach, lessons from thought and experience of the last seven decades. But the intellectual challenge of non-trivial software endeavors remains in the category of major intellectual challenges.

Freethinking and free inquiry about the historical development of software creation is still worthwhile: which theses –or which aspects of them–by original authors are still current? How far I am able to articulate now those main theses of the field?

«At the time I was being groomed to become a very good theoretical physicist, but in 1955 that training was aborted when I decided to become a programmer instead. Not suffering from excessive modesty, I had what I considered a very good reason: I had concluded that programming presented a greater challenge than theoretical physics.»

Under the spell of Leibniz's Dream. Prof.dr Edsger W.Dijkstra.

«I felt that my problems as a programmer were for a large portion beyond the scope of what Polya covered. At first I hesitated to say so aloud, because stressing the exceptional nature of the one's field is usually a sure way of making oneself utterly ridiculous. But after careful consideration I concluded that the intellectual challenge presented by the programming task is, indeed, as unprecedented as the high-speed automatic computer itself.»

"Craftsman or Scientist?" prof.dr.Edsger W.Dijkstra.

Writing good software

Writing good software takes time and a lot of practice, diverse concepts, values –like diligence–, a lot of patience, and other skills. It is kind of similar to master a musical instrument.

It is good to take time everyday to learn and practice: write working code everyday.

Just like music, first you write code everyday to implement usual algorithms (searching, sorting, etc.) by yourself.

Eventually, you gain enough skill to start your own little compositions.

All great systems are made by great people

About great people as the actual source of great systems, I think we should go deeper on what entails to be called “great”, both, people and systems. The act of design, and its related dexterities, is one factor towards such professional greatness. Much of these questions have been thoroughly researched by many authors. I have quoted one of them in the following old post: Good designs come from good designers, good designers come from....

Furthermore, great people are required for great systems on both closely related realms: technical and management. Great teams grouping individual designers of all sorts of artifacts, e.g., test cases or executable software components, should afford great data processing systems; likewise, management should afford great organizational systems as supportive environments for those teams.

Gerald M. Weinberg —and many others— have already pointed out that the history of software development is paved with failed attempts to realize gains in quality and productivity without first creating a supportive environment. To improve bad situations, many managers spend their money on tooling, methodologies, outsourcing, training, application packages, etc., but they rarely spend enough to remove the management that made those situations in the first place or they hardly spend enough to improve them.

As Gerald M. Weinberg also said, we —software developers— have always been a would-be profession, and we will remain a would-be profession until we outgrow our obsession with quick fixes that don’t involve fixing the managers themselves.

Of course, as the saying goes, «you’ll never clear the water until you get the hogs out of the creek». But, let’s be crystal clear: such hogs are not bad people, but bad ideas. In other words, many underlying theories of software development management are obsolete; including many theories of project management.

This is already known since decades ago. I just recall an old post about it: The Underlying Theory of Project Management is Obsolete.

Back to basics: Demanding reading

The following article came to my attention: The Satir Change Model.

An article that includes references to the works of Virginia Satir and Gerald M. Weinberg is a promising reading. Of course, the direct reading of the seminal works by those authors –among other luminaries– would be the best reading. Though the closer to the seminal authors, the more demanding the reading would be.

That kind of demanding reading is what I am talking about when I say that we —our profession— need to go back to the basics.

Gerald M. Weinberg

One of the finest thinkers on computer software development has passed away on August 7, 2018.

«...computer scientist, author and teacher of the psychology and anthropology of computer software development.» — Wikipedia

☛ http://www.geraldmweinberg.com

☛ http://secretsofconsulting.blogspot.com

☛ https://www.facebook.com/gerald.m.weinberg

☛ https://twitter.com/JerryWeinberg/

☛ https://www.facebook.com/terra.ziporyn.snider/posts/10156674749391457

Reading and digesting classical authors

‘You just narrated part of my story exactly! But there is a second part of my story that led to my current ‘reflective’ stage in my professional career on software design. That second part includes reading and digesting some other kind of texts by classical authors (Dijkstra, Dahl, Hoare, Knuth, Meyer, Tanenbaum, Myers, Mills, Weinberg, Parnas, Gilb, DeMarco, Abelson and Sussman, etc.). This current stage feels like another career entirely different than the career in my previous part of my story. Nowadays, I talk to others about that in the context of my Reflective Developer Program’.

Thought and direct experience

Being wrong, and become aware of that, are two different instances of reality. For me, the conjunction of those instances is a joyful experience. For example, I was wrong, very wrong, about who can possibly be able to know something and teach it to others. It is good to know that I was wrong. I just recalled this because of a question about the role of a Scrum Master and direct experience on code design:

Full conversation: Honestly Curious.

«…I used to think —decades into my past— that “the only way” —careful! Bigotry alarms at full capacity here— somebody could ever know and ever teach about something is by the sole means of direct experience. Period. Simple. End of discussion.

Nowadays, —since about 28 years ago—, I reflect that the subject matter of knowing and the subject matter of being able to teach or help others turned out to be not that simple. And the discussion is wide open, and the debate keeps very active among authorities on those subject matters.

There are cases where somebody can, in fact, learn a lot from the experiences reported by others and by pure sheer thought based on sound theoretical schemes. So, now I think that a fully functional Scrum Master —or anybody, for that matter— can, in fact, help others effectively without the sole means of direct experience.

Does it make sense?»

The growth of a feature — Twelve years later

The original «The growth of a feature» post is about twelve years old. Yet, the history of iterative and incremental software design and delivery, accordingly to Craig Larman and Victor R. Basili, began about 70 years ago.

Art vs Work

Software design & computer programming is my art, not my work. That’s why my trend is to enjoy thinking more about it and doing more of it. The referred talk by Cory House reminds me the brief note I wrote back in 2005: I like it! Also this one: I like it even more!

Becoming an Outlier, by Cory House.

A recent survey

There is this other survey with interesting questions about challenges and strategies for successful agile methods adoption:
http://agileresearchnetwork.org/take-the-agile-in-non-agile-environment-survey/

It reminded me that I have seen, time and again, individuals and teams facing enormous struggles to understand themselves and then change values, principles and practices in their own culture in order to ship better software. In my little window of reality around, many cases look hopeless. But, sometimes, there are individuals eager to think and behave differently and who are actually looking for hints to learn new professional principles and values. For those cases, I usually give the following answers to questions like these:

Question 1: Have you encountered challenges to improve software engineering principles, values and practices?

Part of my answer: many challenges, but —this could surprise you— many come from IT people (architects and developers, and their managers) who are unwilling —or unable— to unlearn and relearn.

Question 2: Which strategies would you suggest to face the challenge of shameful levels of unprofessionalism in software development projects?

Part of my answer: We already know: there is no silver bullet. But, one sensible strategy is to start a long journey of un-learning and re-learning the own computer software career. Get back to human basics: un-learning and re-learning basic philosophical and critical thinking, deep study of philosophy of science and engineering, and other basic stuff in the Humanities; for instance, anthropological research as a preparation for doing cultural critical analysis.

Abstraction stacks and multi-paradigm software design

Originally published in Abstraction stacks and multi-paradigm software design, 19 Feb 2004 7:57 PM.

 

Why is important to learn Microsoft Common Intermediate Language (CIL)?

In your role of software technology end-consumer, there is very little, almost non-existent need to.

In your role of software technology producer, a software designer most likely, then the answer is the same as answering: Why is important to a Daytona race pilot to know his engine?

The answer has a relationship with the eagerness of the pilot or the software designer to win!

When my CIL knowledge would be necessary?

From the very first design decision to the last pulse of the crafted bits. That is, if the software artifact is intended to last then it must be designed with that goal in mind.

It seems that most commercial software is designed with other priorities in mind, but not to last. Perhaps, that is a factor behind the reason why, sometimes, end consumers don’t buy more technology.

What is an abstraction stack?

The basic client-server model where a piece of software (the client) asks for something to another software artifact (the server) without caring what the server has to do in order to fulfill the request. This involves the server taking the client role to ask for help to another server, which in turn takes the role of client and…, you got the point.

If you think a little bit about it, an abstraction stack is endless in both directions, server and client, at least philosophically.

The microprocessor (or the running engine like CLR) can be seen as a pragmatic end of current computational abstraction stacks.

Is not the purpose of an abstraction stack supposed to isolate me from knowing all this low-level stuff?

The main purpose of an abstraction stack is to isolate software artifacts, packaging them in layers, subsystems or components of functionality in order to tackle complexity and convey design decisions at higher levels of abstraction.

It is good and desirable for a software artifact to not know the details of its server.

For a software designer, it is neither good nor desirable to not know the details of every layer, subsystem or component in a target abstraction stack.

So, at your next design decision, take in account that you do not have the luxury to not know the details of how your requests are fulfilled. Options are, either the knowledge of the details is in your head or in the head of somebody else in your very same design and programming team.

What is multi-paradigm software design?

Modern software design encompasses a broad set of techniques coming to us from several schools of thought and paradigms. Design skill comes from understanding, articulating, practicing and feed-backing concepts, methods and techniques from all those paradigms.

Multi-paradigm software design is the practice of growing the best possible software in a given context.

“Multi-paradigm design is a domain analysis technique that features concurrent analyses of the application and solution domain. The goal is to find solution domain constructs that most naturally express the structure of the application domain.” As stated by James O. Coplien in “Multi-paradigm design for C++”

If you know CIL, or the details of what ever layer of your abstraction stack, you are at a better position to take proper design decisions.

CIL is another programming language where you have more design options than popular programming languages C# and VB .NET

How this can possibly be related to my current and future job?

Software design is a very singular endeavor at its current state, a combination of art, science, craft and engineering; proper design allows maximum correctness, robustness, modularity and flexibility. Poor design guided by bogus assumptions leads to misery and despair within development teams.

Or in the words of Bertrand Meyer: "The in-the-large aspects of programming rely on the lower-level parts, and you can't get them right unless you get the small things right too"

Obstacles to DevOps

There are several traits of this DevOps inclination that are compelling to me. One is the kind of intellectual promiscuity involved; that is, to combine perspectives of perceivably dissimilar roles in an indiscriminate way. Doing so would enhance the architectural acumen for design decisions by widening the span of attention to even more relevant matters involved is software execution.

There are a number of cultural obstacles to tackle in order to get such acumen in a software provider organization; for example, the obstacles to freely share the hard-won personal technical expertise on the sole premise that doing so is good for the project as a whole, not just good for political exchange of favors among individuals.

Another grievous obstacle is philosophic and scientific illiteracy in the midst of project leaders and team members. Such illiteracy worsen the chasm between the way words are used to map reality in the architectural drawing board, on one hand, and the daily operations room, on the other. A better awareness, for example, of how language can be used in an operational way to build meaning would help decrease the blaming noise and gibberish like ‘our system is down’ or ‘the system does not allow me to give you service’.

Language can be a tool for a clearer thinking, not just a noisy instrument for obscure utterances. A proper use of technical language is important to enhance quality by means of building meaning with sets of operations. That is, of course, there are multiple legitimate ways to use language, but teams using technical language could benefit a lot from the philosophical and historical reflection of the use of language in the sciences. More on that here: Operationalism

Why a Reflective Developer Program?

I have written down the rationale behind the Reflective Developer Program in the following pages, ending with a brief introduction to the program:

1. The state of software development in some trenches.

2. Agile impressions.

3. The Law of Raspberry Jam.

4. Learning from other communities of inquiry.

5. The Reflective Developer Program - what is it about?

4. Learning from other communities of inquiry

There are a number of works on epistemology —as philosophy of science— and on general theory of knowledge —or gnoseology, as known in some Latin-derived cultures— that have been very significant on my research. For example, Ernst Cassirer’s works study knowledge as a philosophical problem and its implications on the development of human culture:

- The Problem of Knowledge.

- The Philosophy of Symbolic Forms: Vol. 3: The Phenomenology of Knowledge.

- An Essay on Man: An Introduction to a Philosophy of Human Culture.

The philosophical perspectives predominate over strictly scientific perspectives in Cassirer’s works. I have found a more balanced treatment between philosophy and science in Mario Bunge’s two volumes on epistemology:

- Philosophy of Science: From Problem to Theory.

- Philosophy of Science: From Explanation to Justification.

Introductory works more on the side of strictly scientific perspectives that I have found very helpful are:

- What Is This Thing Called Science? by Alan F. Chalmers.

- Scientific Method in Practice by Hugh G. Gauch Jr.

- Theory and Reality: An Introduction to the Philosophy of Science by Peter Godfrey-Smith.

Then, there is this contemporary scientist, Rupert Sheldrake, who —as Paul Feyerabend in his own time— presents quite intriguing, or even interesting, arguments that shake popular understanding of scientific thought in his work:

- Science Set Free: 10 Paths to New Discovery, USA Edition.

- The Science Delusion, UK Edition.

Among the first works that indirectly pushed me to all the mentioned readings was this:

- Testing Computer Software, 2nd Edition by Cem Kaner, Jack Falk, Hung Q. Nguyen.

All this, and the following works by Donald A. Schön, has led me to pursue the development of what I have called a Reflective Developer Program, as a contribution to better professionalism in software development. A reflective developer is someone who tries to realize how thin her received piece of jam really is, and tries to make it thicker.

- The Reflective Practitioner: How Professionals Think In Action.

- Educating the Reflective Practitioner: Toward a New Design for Teaching and Learning in the Professions.

The Reflective Developer Program is intended to be a personal research journey to better understanding of professionalism in computing. Given the philosophical problem of knowledge and The Law of Raspberry Jam, I think that teaching and learning in our profession need to be rethought. Therefore, after studying the following works, I have found that dialog and discussion among practitioners is the appropriate thing to do.

- Turning Learning Right Side Up: Putting Education Back on Track by Russell L. Ackoff, Daniel Greenberg.

- Up and Out: Using Critical and Creative Thinking Skills to Enhance Learning by Andrew P. Johnson.

- Discussion as a Way of Teaching: Tools and Techniques for Democratic Classrooms by Stephen D. Brookfield, Stephen Preskill.

- Developing Critical Thinkers: Challenging Adults to Explore Alternative Ways of Thinking and Acting by Stephen D. Brookfield.

3. The Law of Raspberry Jam

«The Law of Raspberry Jam: The wider you spread it, the thinner it gets.» —Gerald M. Weinberg

As Gerald M. Weinberg said in his work The Secrets of Consulting about The Law of Raspberry Jam: «Another way of expressing the law is this: Influence or affluence; take your choice.» That is, the wider the audience, the more money you can make. Based on the observed effects so far, maybe we could know which has been the choice of the authors of ideas like the agile methods. I am glad they chose to spread their ideas; otherwise, maybe, I could not hear anything about such wonderful ones.

After some years studying about the philosophical problem of knowledge, I think that the choice of influence —as in The Law of Raspberry Jam, alternatively expressed— is exclusively a personal one. That is, I have received my part of jam, as thinner as it could be; now it is my choice to make it thick by means of self-influence: by personally researching the subject matter in order to get the more jam as I could possibly grasp.

For example, in my own research efforts, one of my null hypothesis is that the actual properties of the outcome of a non-trivial software development effort is an epistemic problem; that is, the actual properties of the outcome cannot be known until such outcome is actually experienced by its ultimate customers or end users; most previously conceived rationalizations must be doubted and put to rigorous empirical examination. Another null hypothesis is that the previous one will continually be true indefinitely because of the problem-solution coevolution model of design, where the sole presence of a solution to a complex problem —or a subset of the solution— redefines such a problem.

A trait of my provisional conclusions is that the very activity of software development for non-trivial projects is an activity of inquiry, of an experimental nature. This is true regardless past, current and future buzzwords because most of them, e.g., agile, are not intended to bring new knowledge but just new wrappings for already conceived and published ideas of the past. Part of the support for such conclusions can be traced in the works by early authors in our field, e.g., Gerald M. Weinberg, Frederick P. Brooks, Jr.

The practice of discussing these topics in communities of inquiry, and learning from the feedback, is another way to self-influence.

2. Agile impressions

Why are things as they are? How might things be different? Some years ago I started a personal inquiry guided by questions like these. Just recently I read the Agile Impressions text by Gerald M. Weinberg. I have read many of Weinberg’s books, and I have read that some Agile Manifesto’s authors have learned a lot from those books. That is why I am especially interested to read what Gerald M. Weinberg has to say about the Agile Manifesto’s mindset.

The section Agile and the Definition of Quality, as properly stated at the beginning, is adapted from section 1.1 A Tale of Software Quality, in Quality Software Management. Volume 1: Systems Thinking. I noticed that Weinberg equates the actions of a quality manager —as of 1991— with the actions of an Agile team —as of 2013—.

1991: «That’s why one of the most important actions of a quality manager is to bring such decisions into consciousness, if not always into public awareness.»

2013: «That’s why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness.»

That is pretty much consistent, historically, with the quotation attributed to Weinberg in the article about the history of iterative and incremental development, by Craig Larman and Vic Basili: «...where the technique used was, as far as I can tell, indistinguishable from XP [eXtreme Programming].»

In other words, this is additional evidence for many possible conclusions; for example, that iterative and incremental development (IID) was not born with object-oriented methods in the 90’s, or that IID is not recent and comparatively unproven. Also, this is evidence of how true David Parnas statement is about where the next big thing in software engineering lies, in the horizon or in the past, in the history of our profession.

1. The state of software development in some trenches

The industry of software development has a history of its own ideas like structured analysis, design and programming, or object-oriented, or functional programming, agile methods, software architecture, and so on. In order to learn about some of those ideas, over many years, I have been involved with communities that form around those ideas, learning from authors and practitioners, and from my own application of those ideas to improve the quality of my own software design and programming practice. Along the way, I have tried to discuss with others about all that good stuff of software development as a cooperative game.

As years come and go, I have found teams and individuals that expose themselves to be influenced by ideas in the industry around, and the degree of such influence varies widely. There are still lots of programmers and managers who simply do not care enough to not just repeat the buzzwords but to behave like if they properly understood the concepts. Comes to mind what have happened with other intellectual pursuits in history. For example, very few people around me, even with several academic computing degrees, are able to articulate, in simple terms, the most general justified true beliefs from quantum theory, much less its relationship with the current computing industry. Whereas those justified true beliefs were published almost a century ago!