Marco Dorantes' WebLog

Product owner

marcod — Fri, 30 Oct 2009 15:21:00 GMT

Writing software for my own—or my kids—use and delight is almost always a fun and successful endeavor, if expectations are not well managed, I throw it away, no problem. Likewise, when programmers write software for their own use, there are more chances the software can be steered gracefully to a useful end.

It is quite different writing software for paying customers when the business value is a moving target. One development management strategy is to isolate the development team from such dynamism for at least a short period of time (30 days in the case of Scrum). Then reflect how close we are from the adjusted target and plan the next short development cycle based on current priorities. Enabling the growth of the functional capacities the business actually needs. The whole point of the adaptive methods of development is to give chance to the related parties —and especially to the Product Owner— to learn, to realize, to corroborate, what is the actual —up to a given point in time— need; and to direct the development effort only toward that need.

In addition, if involved people lack the awareness of what entails this style of development for each role —like the accountability for steering the effort by the Product owner— then, agile and lean fads become the new excuses for brittle software.

Writing

marcod — Wed, 30 Sep 2009 14:14:00 GMT

The act of writing demands some skills from the writer, skills of the intellectual kind. Of course, the demand varies accordingly to the type of writing among many other factors.

Writing texts for humans, from blog posts to literature, is challenging if the purpose is to convey a message in a clear and concise way, as possible.

Writing technical texts for humans and computers, also known as the act of artistic programming of digital computers, is also very challenging.

Based on typical conversations between IT professionals nowadays, I guess that only very few people alive today actually know what really entails a common communication between humans and computers through technical texts (also known as source code).

SQA — Are you–really–making sure that quality is present?

marcod — Sun, 30 Aug 2009 17:50:00 GMT

What is the idea behind SQA?

If SQA stands for “Software Quality Assurance”, then I hardly find a project team member not under that cap —in a team with agile principles, values and practices, that is.

If SQA stands for “testing” (validation and verification testing, for functional/integration/acceptance testing purposes) then I think the old practice of having a different set of professionals doing destructive testing still is a good advice (if finding bugs is the goal).

Unit testing for Test-driven design is for developers (constructive mindset), validation and verification for functional/integration/acceptance testing purposes is for testers (destructive mindset). Hence, testers’ role does not change very much while adopting agile methods.

Moreover, making really sure quality is in there implies something greater than thinking SQA as a role some people have in a software project.

Where are we -as industry- about delivering business value to customers?

marcod — Thu, 23 Jul 2009 05:18:00 GMT

For a hint, see the The Standish Group CHAOS Report summary:

CHAOS Report Summary 2009

"These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"

Is there such a thing like a method of design?

marcod — Mon, 15 Jun 2009 09:45:00 GMT

I have observed, time after time, an author or renowned professional share or publish her opinion about something, said, in time T1. Many people listen to that opinion —with accuracy or with misinterpretation— and then take that view for granted. Moreover, many, many people start behaving like propagandists of such reinterpreted or particular view; they even start enterprises based on generalizations of such views. Sometimes, curiously enough, the original author —who is guided by his own critical powers— find out, in time T2, new corroborated information which become the base for a shift in opinion or a significant improvement over her previous views. Including a complete departure from what he previously said.

For instance, about 1964, Christopher Alexander wrote a book entitled Notes on the synthesis of form. Many people understood that what is important about design is the process or method of design and they emphatically pursued the development of design processes as mean to better designs. Doug Lea wrote about the integration of Alexander’s works to field of software design.

Almost ten years later, the same Christopher Alexander wrote a preface to the paperback 1971 edition of the same book. There he explains that after the book was written, he discovered new information that leaded him to understand how unfortunate is the disproportion portrayed in the book between the attention given to the design method or process and the attention given to the practice of design itself. Mainly, because no one will become a better designer by blindly following the denoted design method, or indeed by following any method blindly.

Central piece of code as a cornerstone for a tool

marcod — Fri, 08 May 2009 08:34:00 GMT

Sometimes, the idea of a tool could gravitate around a very simple piece of code, an enabling mechanism that gives life to a much larger functionality.

That is the case of a simple tool I am writing for my own use. It is an application, based on Windows Presentation Foundation, which help me to upload files from my local hard drive to a number of Windows Sharepoint sites and folders; following my own uploading and publishing patterns.

The whole of the tool goes around this single piece of code:

The importance of doubt in software design

marcod — Fri, 01 May 2009 03:44:00 GMT

The acts of exploring and discovering which start from simple doubts —kind of ‘I am not entirely sure about...’ thoughts— is what makes software design and computer programming so exhilarating for me. Doubts from the efficiency or balance of a given design decision to the net and long-term benefits of traditional beliefs about the software development process in a business context.

Based on the results so far from my personal research program on the subject of the act of computer programming, I have corroborated that this activity can be reduced —regarding its essence— to a pure act of design. Hence, further improvement or advancement of the software development profession goes on the road of improving the design skills of practitioners.

Software designers on the road to seasoned software professionals will need education about art —please note that here education is used in its widest sense and not just the popular notion of schooling— and about methodologies of intellectual work in language, literature, history and philosophy. Of course, as is the case for the good education, it is self-inflicted. That is to say, training can be given but education can only be chosen.

Among the set of dexterities in a software designer, the ability to think critically stands as a very important one. The exercise of the critical sense —in contrast with the common sense— has proved very beneficial for the design task and directly related to the quality attributes of its outcome, namely, working software that delivers actual business value.

Know your design tools — The Singleton case

marcod — Mon, 30 Mar 2009 05:53:00 GMT

A professional software designer —one whose next paycheck depends on the quality of her software— looks for an ever increasing acquaintance with his design tools.

One of the most important design tools in software is the actual computing machine —abstract, virtual and physical— where the software under design will be executed. The reason why the computer is a design tool is the interacting or conversational exchange with it that allows better design decisions. That is, the practice of a reflective conversation with the situation at hand as described by The Reflective Practitioner: How Professionals Think in Action by Donald A. Schön.

One benefit out of such conversational exchange with the computing environment is that hardware and software components will be utilized closer to their original intent, unnecessary code will not be present and thus simple, clean, less complex, and more maintainable software could be put on the hands of users.

For instance, if you need to implement the Singleton design pattern using Microsoft Visual C^# upon the Common Language Infrastructure (CLI) implementation from Microsoft, the Common Language Runtime (CLR), then it is better to first know these design tools in depth instead of trying ‘as is’, the same, unquestioned assumptions from other computing environments.

The point of Singleton is to have a single instance of a class, an exact same object shared across a given CLR AppDomain inside a Windows’s Win32_Process instance, that is, a global state available to all executing threads in the give CLR AppDomain.

The idea is, given this method...

static bool AreTheseTheExactSameObject(object a, object b)
{
  return object.ReferenceEquals(a, b);
}

...that the following assertion will succeed, even if this assertion is executed concurrently by a plethora of AppDomain’s threads:

object a = TimepointSingleton.Instance;
object b = TimepointSingleton.Instance;
System.Diagnostics.Debug.Assert(AreTheseTheExactSameObject(a, b));

The horror of global variables from old structured design techniques strikes back, now in the form of nice-looking object oriented terms. The horror could be kept in control if the shared state is read-only. But, even if the shared object’s state is read-only, there is one state that must be written once at instantiation time: the variable holding the reference to that single and shared object.

At instantiation time the following constructor must be executed only once:

private TimepointSingleton()
{
  point = DateTime.Now;
  Console.WriteLine("Timepoint acquired");
  
  //This simulates resource contention to show up
  //better the multithreading problem when no
  //proper thread synchronization is in place.
  System.Threading.Thread.Sleep(4000);
}

With the following class type member field:

private DateTime point;

The private access modifier in the constructor ensures that instantiation could only occur inside the class; no other place in the program could create objects of this class. The one and only instance of this class is created by the class itself and its reference will be kept in a private static field member and accessed by a static read-only property:

private static readonly TimepointSingleton instance;
public static TimepointSingleton Instance { get { return instance; } }

Of course, the heart of the issue is that multiple threads could invoke that public static read-only property simultaneously; which is not a problem once the object reference is in place —in the reference type variable of the private static field member— because, once initialized, this field’s value (an object reference) is read-only state for those multiple threads.

So the main design decision here is how to write the object reference of the one and only instance into that private static field.

Modern computing environments usually have implicit and explicit mechanisms that ensure the execution of a single thread in a given code point. The implicit ones are provided by the underlying execution environment and are the simplest and easy to use. That kind of mechanism is what we prefer here over explicit mechanisms that could convolute and add complexity to our design unnecessarily. Visual C++ with native code has them, and also Visual C^# with the current CLR.

Explicit mechanisms for thread synchronization at initialization time involving single or double checks and volatile fields could be applied successfully, but if simpler, implicit, mechanisms are at hand that could deliver clearer results, then they should be chosen.

Based on empirical analysis and also corroborated from CLR via C# by Jeffrey Richter, that simpler mechanism for the Singleton case is a static constructor, (also named type initializer or class constructor).
From the Microsoft Visual C^# Language Specification 3.0, in the 10.12 Static constructors section:

“The static constructor for a closed class type executes at most once in a given application domain.”

So, the crucial code would be:

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

This way, the class is not marked with the beforefieldinit CLR metadata attribute that allows the CLR to optimize type initialization for perfomance, and not necessarily for correctness. So the following field initializer accomplishes not exactly the same thing (that is, the beforefieldinit attribute is still generated):

private static readonly TimepointSingleton instance = new TimepointSingleton();

For additional perspectives click here.

An artistic -as in skillful- programming excellent textbook

marcod — Sat, 07 Feb 2009 22:54:00 GMT

The mind of Bjarne Stroustrup through the thinking and design style of the C++ programming language has been of critical importance for my own thinking and practice of programming. Yes, he is a philosopher of computer programming, an artistic programmer (as conveyed in Artistic programming as theory formulation).

Newcomers to computer programming and experts alike could benefit from Programming: Principles and Practice Using C++ book, as a variety of concepts and exercises are covered, including historical perspectives. Also, seasoned programmers could find many hints as the book is an instance of how an expert explains and teaches to newcomers.

As a reading suggestion: in section 1.6 Ideals for programmers, a general programming process is explained and the importance of how testing, analysis, design and programming are related is noticed. So, for a perhaps better reading, I suggest the sixth paragraph which says:

“We can describe the process of developing a program as having four stages:”

would be clearer if read this way:

“We can describe the process of developing a program as having four activities:”

Artistic programming as theory formulation

marcod — Sat, 07 Feb 2009 21:59:00 GMT

An artistic painter enjoys painting. That is a trait of artful making even when there is no fulfillment other than the act of painting in itself. The same could be said about problem-solving. Financial gratification could be part of the after-the-fact effects of painting or problem-solving but is not related at all with the act of painting or solving complex problems, nor as cause, reason or driver.

As time goes by, as observations and corroborations expand, computer programming —as a material object of philosophical study— looks more and more like a mix of artistic making and problem-solving activities, and less and less like an industrializable or automatable activity; there is a continuum of better tooling but that doesn’t take out a bit of the essence of programming.

But, once again, what is computer programming? Adopting and keeping a reflexive skepticism over what we do as computer programmers and searching for better answers to that question will allow us to enhance our fulfillment and also to evolve the groundwork for the next scientific revolution related to how humans make use of digital computation.

Programming entails communication, between humans and also between humans and digital computers (hence its relation with cybernetics, which is the theory or study of communication and control in living organisms or machines). For communication, we human beings make use of linguistic signs —the association of a concept with an acoustic image, as signified and signifier respectively— which are codified in a language, natural or artificial, as a medium of expression. For digital computing to take place we must, ultimately, articulate and codify our concepts in an artificial language, whether this is a programming language or the language of mathematics.

A frame for effective and precise communication of concepts as justified true beliefs has been the scientific idea of theory, which represents the best effort to explain and to predict something, and yet, it has a provisional character, and never an absolutist position. For computing purposes, a theory and its formulation are the outcome and the process of programming, respectively.

Programming as theory formulation occurs even if the mainstream programmer is not aware of that, perhaps this unawareness is part of the reason of crappy and brittle software. An artistic programmer, on the other hand, enjoys the act of programming, of solving problems, and frames her mind and his expression as a coherent system of general, constant and necessary relationships between concepts.

Happy thinking and programming

The practical disproportion

marcod — Sat, 31 Jan 2009 20:13:00 GMT

Some individual or a small group of them have an idea or a system of ideas that look promising out of which come outstanding outcomes. Later, those very same ideas are adopted into the mainstream but a much lesser level of greatness comes out.

I have observed this pattern over a number of dissimilar contexts, software development, business, religion, to name a few.

Why is that?

Is it a fixated perception that —as colored glasses— makes me watch something where there is no such a thing? Perhaps.

Which could be another explanation or reasonable system of interpretation for this pattern of behavior among humans?

A possibility is that an important part of the root cause for that situation is a disproportional focus on the practical side out of everything. Many, many people believing practical consequences are the sole criteria to judge knowledge, meaning and value.

I suspect the obsessive, disproportional and exclusive focus on the practical aspects of a subject matter carries most of the blame.

How many of us could actually explain the difference between theory and practice, theory and hypothesis, reliable knowledge and belief?

“Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass and never has any certainty where he is going. Practice should always be based upon a sound knowledge of theory”
-Leonardo da Vinci (1452–1519)

“The trouble with people is not that they don't know but that they know so much that ain’t so”
-Josh Billings (1818–1885)

Agile and lean fads are the new excuses for brittle software

marcod — Fri, 05 Dec 2008 16:25:00 GMT

Now that many are looking for ways to cut costs and maximize the benefits out of their shrunk budget, there is no shortage of offers about how to do just that. Among those offers are the agile and lean software development methods, which are quickly becoming the norm rather than the exception in the IT industry’s parlance nowadays. Soon, in most IT shops, anyone talking against agile and lean concepts will become the next weird, anti-social, anarchist, non-team-player guy that dare to endorse a different view than the mainstream view. Just as it happened when some guy started to talk about the shortcomings of structured analysis, design and programming compared with object-oriented techniques, as with many other ideas in the history of our infant industry. Each time, an exaggerated message of the future gains was given in order to hook buyers on the new ideas. Why this time would be different?

Don’t get me wrong, the most gratifying and positive professional experiences —individually and in teams— on software development have come from the agile and lean mindsets. It is just that the patterns of behavior that I have seen from we humans in large groups make me wonder, why on Earth this time the substance is actually going to be broadly adopted and not just the buzzwords? Is the general public going to really enhance their average software experience because of better software or the whole point for the software providers is costs reduction only? I’m afraid the latter is closer to the truth than the former. The main concern I have is that —as far as my understanding on agile and lean mindsets can go— the former is the way to reach the latter. This has been the whole point since the first generation of Method Wars in the history of professional software development. Point that, historically, could not have been fully explained and broadly understood yet.

There is adaptive software development (also known as agile) thinking and there is lean software development thinking, just as there are their corresponding fads (adopting only the buzzwords and not the change in mentality). The thinking part is more likely to achieve some level of the sought-after benefits, and the fads will just give a bad name to the good ideas in agile and lean.

A way to specify behavior

marcod — Mon, 01 Dec 2008 07:00:00 GMT

The modern name for an ancient programming technique —which roots can be traced back to Dr. E.W. Dijkstra*— was “test-first programming” and didn’t preclude, in any sense, the need of validation and verification testing, done by an independent group of people with a different mindset and goals (whereas programmers want to release the best possible software, the testers want to stop releasing software with any lurking bug).

Seasoned testing professionals usually have a bunch of techniques for testing existing software based on already specified behavior, and these professionals have been able to do just well without “test-first programming”. An important project (is there any that not?) could not afford to go without these professionals and any attempt to dismiss their importance because of a programmer’s technique is a recipe for disaster.

On the other hand, test-first programming is a way to specify behavior and to build trust that the specified behavior is kept in place while the software grows in capacity.

* “Instead, you construct a correct program in small steps. Each step takes the specification and produces something a little nearer to the final program. Each step is small enough that you can see exactly what needs to be proved to show that the step is correct.”
– The Professor Edsger Wybe Dijkstra school of thought (aren’t these the eXtreme Programming test/code/refactoring micro-cycles?)

Faculties offer courses and lectures freely

marcod — Wed, 29 Oct 2008 12:00:00 GMT

The University of Washington, the Computer Science & Engineering department —as other faculties like MIT and Stanford with programs like MIT OpenCourseWare and Stanford Engineering Everywhere— offers videos recordings of selected lectures and course materials. This is great for those interested in learning and further improvement.

For example, recently (October 21, 2008) Joe Duffy from Microsoft gave a talk about Microsoft's Parallel Computing Platform: Applied Research in a Product Setting. The video recording is freely available.

Adaptive Methods for reality

marcod — Wed, 01 Oct 2008 06:09:00 GMT

The attitude of mind to approach reality that has helped humans to explain and to predict phenomena (observed facts) consistently and precisely, the scientific mindset, is one among those things computer professionals could adopt to better understand software development fundamentals. There are two somehow conflicting aspects of the scientific attitude that make it so compelling just because that opposing effect.

First, that eagerness to bring all possible thoughts about a subject matter by previous and current thinkers to the working table, so new work can be based on rock solid arguments gained through rigorous work and tested conclusions. In contrast, how many current software professionals have a working knowledge of structured design methods? And of first, second and third generations of object-oriented analysis and design methods?

Second, in the essence of a scientific attitude is the constant disposition to disprove current beliefs, to refute our own viewpoints, an inexorable bias to distrust self-righteous thinking; that is, to put our conclusions under the most severe and ruthless testing conditions possible. Why? Kenneth Boulding said: "Knowledge increases not by the matching of mind images with the real world —which is impossible—, that is, not by the direct perception of truth, but by a relentless bias toward the perception of error. This is as true of folk knowledge as it is of science". In contrast, how often can we found people with a dogmatic view of their profession in software? “We only do this or that buzzword around here”, “This brand or fashion is the only true game in town”, etc.

The combination of those —rational and skeptic— attitudes is requisite for scientific progress, that is, the accretion of reliable knowledge about a subject matter within the reach of science (the natural world). Philosophers of science have factored those attitudes out of science and have made them available for use in other disciplines so they could also be able to advance the knowledge in their fields in a rigorous and reliable way; for instance, social sciences like sociology, economics, anthropology (which includes physical anthropology, archeology, ethnology, and linguistics), political science, and others.

The world of software is a world of the artificial, a world of logical constructs governed by a different set of relationships in sharp contrast with those from the physical world and very similar to that from the field of linguistics, where the relationship between the sign (symbol), the signified (concept) and the signifier (linguistic image) is subject of significant changes between a discrete point in time (synchronic linguistic) and its evolution (diachronic linguistic). As far as we are interested to know something about software development we better strengthen our critical thinking powers including those mental attitudes mentioned above.

I have seen those very same attitudes in practitioners of the now generally known agile methods for software development; a distinction is in order, the practitioners I am referring to are not those just using the buzzwords, but those that bet their careers on their professional values and principles; those reflective practitioners who backup their beliefs with their behaviors, those who take the scientific approach to reality as a tool, not as a religion. These guys are perpetual learners, de facto scientists in the field of software. For they, the name agile means just a starting point for a continuous cooperative understanding. The term agile means only a token to bring a conversational style, just like the term adaptive which, by the way, was the second candidate name word from that Snowbird, Utah meeting on February 2001. In my opinion, adaptive reflects better the contrast with absolutist predictive approaches and emphasizes the ever-changing and self-critical nature of modern (or post-modernist from a philosophical perspective) software development processes.

Adaptive methods imply —in addition— a dual mode of behavior from their practitioners, just like the progress of science needs a dualistic endeavor for unblocking situations. These modes could be called up like Evolutionary and Revolutionary, where the former refers broadly to a thinking style that search truth deeper in a single direction by kind of specializations and the latter means a thinking style that broaden the perspective by kind of generalizations; the traits could be like follow:

Evolutionary mode	Revolutionary mode
Craftspeople	Seers
Team players	Independent
Normal evolutionists	Non-normal. Revolutionary.
Technical climbers-engineers. Problem climbers.	Travelers. Valley crossers. Philosophers.