In FoP, Karl states that your goal is to create highly maintainable code.  His thesis has many presecriptions for this, but I wanted to make a few comments about what I consider the process of creating.

I program computers because I like to create.  I like to "design" new things, and make them reality.  Basically, I like to take things that already exist, and apply the things that I have learned to make them do new things.  To be technical, as "Herbert Simon" would say in "The Sciences of the Artificial", what I do in designing things is apply knowledge to transform something into something else; I create through the process of design, which is an artifical process because it uses cognition instead of being naturally occurring.

Now, this creating can be done done several ways.  One is to modify something that already exists to do something differently.  Another is to take two or more things that already exist, and combine them together with some new stuff to make them work together to do something new.  Or you can just create something altogether new.

Regardless of which of these scenarios, the end result is something that I want to be proud of.  And I like Karl's statement that your goal as a programmer should be to make highly maintainable code, and I think this is spot on.  That is how a programmer has his achievment most accurately measured.

Why?

Because showing that I created something new, and did it well, is what gives me the most satisfaction.  Highly maintanable code means that the code can be understood, that it follows patterns of practice that have been gained through my experiences, and probably most importantly that because of both of these the people using it can learn to do the same if not better.

But what is meant by "highly maintainable code"?

I think this breaks down to several things:

1. The code is built using patterns of practice that are easily understandable so that it can be "maintained" - that is understood completely by others,
2. The code is tested and proven to do what it is intended to do, otherwhise it is surely not "maintainable".

I used to be skeptical of TDD.  I now embrace it wholly.  I used to wonder why I made this change.  And I quess that is why I was so perturbed in a previous post when I mentioned that I was actively prevented from building a test.  After all, without being able to create the test and prove what you did, how can you tell if you created something effectively?  And what better a way of defining the measurement of your quality at the start so that you can guide your way to your goal?

Some notes on this podcast that I think are of importance...

Ted states that event based programming differs from event driven systems.  An example of an event driven app is a windows GUI.  These event driven programs do nothing until receiving event and then handle it internally.  Event-based applications, on the other hand, basically operate upon upon internal communications between different parts of the application that are hooked together to provide functionality through event based communications. 

Dynamic Routing is stated as being one of the important things about this type of programming.  Dynamic routing is where handlers for events can be changed at run-time.  In event based systems this is fixed at runtime.  Event-based applications can change the configuration on the fly.  To do this, several constructs are used:

• Builders - instantiate all the objects in the system
• Binders - provide communications channels between systems
• Coordinators - provide orchestration between objects through binders

The key point is that binders preserve the decoupling of sources of events from their listeners.  This is important to be able to ensure flexibility, independent development, and independent testing of the components.  A builder puts together all entities that will be wired, and then passes control to a binder which wires the individual components.  Binders then wire up all the observers to subjects. 

description of switch statements being used as a means for demultiplexing data moved over a single communications channel.  At some point some data is created, then through one code path (the communications channel) a decision is made to go different ways.  This inherently bad for concurrency and scalability, and handling through bindings is much more scalable.

Also raised was a concern about the .NET/WPF model of events and passing argugments to the event through classes as a parameter.  To create your own events, you must necessarily then create an event arguments class.  This therefore causes class explosion as you need to make a new class for every event just to pass the arguments.  I totally agree with this as I think its a total pain to have to go through this.

Ted has a book on this topic.  I have not read it yet: Event-Based Programming: Taking Events to the Limit.

I'm curious to see if he gets into topics of Invasive Software Composition.  I recommend the book on this by Uwe Assmann.  This book discusses a number of topics, but which I would describe as mostly discussing AoP and connection of software components through connectors, ports and adapters.  It's also a good read if you are into SOA and BPEL, as (at least to me) it gave good clarification on the use of communications channels (SOAP/REST) between components (Web Services) and transformation (XSLT) of data (XML) across the channel.

Where this ties into the discussion that Ted had is that Assmann (boy that's a bad name in the US) would do the "binding" with AoP constructs, basically injecting the bindings between the components at runtime through dependency injection (DI).  I would also tend to say that the bindings could not also be done this way, but also through generic programming using policy classes, as well as havnig routes between objects be able to be modified dynamically through having the injected policies either change or make decisions on the data.

This last point gets into another SOA tennant (a reason I brought it up earlier)  which is know as content based routing.  Typically, this is done on an enterprise service bus through logic attached to the bus, but within an application, a very flexible model of routing of data as well as code flow could be set up with a good combination of AoP, DI and event based architecture.

I've always wanted to define a canonical list of software patterns.  There are more type patterns than most people know.  Most programmers I cross think purely in terms of the GoF (gang of four) patterns, but there are many more types to know. 

Here is my current list of all types of software patterns:

• The classic GoF design patterns
• Patterns of Enterprise Application Architecture
• Enterprise Integration Patterns
• Business Process and Workflow Patterns
• Data Access Patterns
• Remoting Patterns
• Threading Patterns
• Real-time patterns
• Testing (TDD) Patterns
• Parallel Programming Patterns
• Ajax Design Patterns
• SOA Design Patterns
• Implementation Patterns
• Cloud Computing Patterns

This weeks Hanselminutes was a discussion with Tom and Mary Poppendieck on Lean Software Development and what is "software success".  Much of this discussion struck a chord with me and that I figured it would be good for me to drop a few thoughts onto my blog.

The initial part of the discussion started out with talk on what is the definition of “success” of a software project.  Scott apparently was chastised by Mary on a panel for mentioning that he thought it was to “be on time, in scope, and on budget.”  Mary stated that this is the definition of success according to “The Standish Group”’s chaos report, which measures software success on these criteria, and more specifically, failure of projects by not achieving these. 

She then said that she feels that this is not an adequate (or even correct) measure of success, and that for a software project to be a success it must be a business success, not a technical success.  This means that the software that is being implemented must create something that does what the business needs, such as achieving market share or being profitable, not simply accomplishing some type of task or goal.

I consider this to be a very important statement.  I’ve been on many projects that have been completed on time, on budget and in scope.  But they were never used.  Or used briefly, and then forgotten.  These, in essence, wasted all of the money put into the implementation.  These types of solutions have always been in my mind to not be successful software projects even though many call them successful.  Needless to say I don’t really like these types of projects, as in the long run I haven’t contributed to bettering the bottom line.

This leads to the idea that developers should not be measured by being done “by a certain date”, or on a certain “budget”.  Mary stated that when she was at 3M that the teams that she was on had to show P&L for the projects, marketing plans, …, to be responsible for all that, and in short showing that profit would be made from the project.  Or else, the project would not even be approved.  I agree with this whole heartedly, and more organizations should really learn to do more effective forecasting of the ROI / IRR on software projects before jumping in to that pool and building away.  Additionally, these measurements should also be used to guide the project alongs its path.

Mary then got onto a point that I think is very important, that her teams were held accountable to be responsible at a higher level than just time and budget, which are the typical things for which most software teams and project managers are held accountable.  These teams should be held accountable for creating things that address a tangible business need.  Their success must be measured on the actual problem solution, the successful capture of a financial opportunity by the organization.

One thing that comes to my mind, and that I feel she wants to say but never really gets around to it (probably due to time constraints), but I’ll say it (and I’ve said it to other before), is that it is my opinion that software is just a tool of implementation towards a completion of a solution / product.  Software development is a tool in building things that allow businesses to exploit opportunities, and the focus of software development must be to effectively address increasing profit in an organization, otherwise the criteria for success of the project is incorrect. 

Software development to me is not different than, say, using plastics in injection molding of car parts, or the assembly of those parts into a car, or any type of widget.  If the widget is not something that anyone will buy (that is, it will make money, and money above the cost of building it), then it doesn’t matter if it is plastic or metal machinery, or software development, that put it together – it just shouldn’t have been done in the first place.

Where this discussion in the podcast was going, but never got to, was into discussion of product development, and what I would refer to as software product line engineering (SPLE).  These higher level constructs for measurement that were mentioned by Mary, are in my opinion, components of proper product platform management, that uses software as the tool set for building the product, and where measuring success of products is in making profit (yes, I sound like a ferengi).

I'm going to follow up this post with another on my thoughts about SPLE as I think it is really important, but I need to address one more issue first.  During this discussion, Scott made a mention about the agile technologies, and that don’t these solve all of these problems?  Well, Mary had an interesting response which I totally agree with, and I’ll state it from my perspective:

Agile software technologies and tools as described today are an implementation detail of proper product management.  They are the means by which you create the parts of a singular product made of software, not how you define what should be in your product, or as the parts used to build a suite of products.  Measuring for success on using agile tools and methodologies alone is therefore an invalid measurement of the success of the products built with them.

I get a lot of flack from people I mention this to, especially at things like agile user groups.  I don’t care if you use XP, Scrum, TDD, MDA, Nunit, Mocks, FitNess, … all that stuff … if you are not building the right thing, then all these just help you build the wrong thing better.  Yes, they are important (and I do personally consider them to be very important), but they miss the overall target because the people working with them have myopic views of the overall organization since they are only in the trenches of software development.  It's not their fault, but it is a situation that does need to be fixed.

Also, and perhaps more importantly, even if you are building the correct thing, but you are not building it in a way that can lead to greater agility in the future, then what is the purpose?  This is something that touched on very briefly by Tom in the podcast, but could have used more elaboration as I think it is the real key to software success.  Software must be built in a manner where it is used to accelerate future product development, so that the organization can become faster to market with products down the line.  This is the holy grail of software reuse.  Not using software necessarily to build software faster, but to use product components built with software to build products faster than competitors.

This last note leads again back into software product line engineering.  I'll follow up with more on that topic in some future posts.

Take the following code snippet to iterate across an array:

        int[] ia = new int[] { 5, 4, 3, 2, 1};
        for (int i=0; i<ia.Length; i++)
        {
            Console.WriteLine(ia[i]);
        }
 

What'sthe problem with this code?   Well, its just too verbose.  I have asimple idea here, and I have to type way too much.  All I want to do isdo something to every element in the array (in this case, it's print iton the console, but the process can be arbitrarily complex).  To dothis, I have to say 'for', and then create a variable that I have toinitialize, increment and check for a completion state.  I then have touse that variable to select the particular element of the array toprocess.

I can't tell you how many times I've had to type thisboiler plate, and it kills me every time as I have a simple idea, dosomething with each of the items, and I have to do a lot of problematictyping to get it done (I wont get into the reasons for problems - thathas been documented elsewhere quite well).

C# nicely has gone and made this a little simpler:

        int[] ia = new int[] { 5, 4, 3, 2, 1};
        foreach (int i in ia)
        {
            Console.WriteLine(i);
        }

Atleast with the foreach construct, I don't have the initialization ofthe index variable, incrementation, termination comparison to type andget messed up.  I still do need to have a variable to hold the currentitem, and the other boiler plate code around it (the 'foreach' andsuch).

Can't this be still simpler?  How about the following:

        int[] ia = new int[] { 5, 4, 3, 2, 1};
        iterate ia |i| { Console.WriteLine(i) };

Theiterate keyword means just that - iterate across something.  You figureout how to, Mr. computer.  I'm just interested in doing something witheach item, which I'll refer to as the symbol inside of the pipes. Isn't this nice?

Technorati Tags: Patterns

Technorati Tags: Patterns, P#