This blogs topic is about software industrialization, which means making software development a predictable and repeatable process.  The only other requirement for software industrialization is that the software created meets the end user's requirements.

 

Why is software development not a predictable and repeatable process?  I can partially explain this through a small story where after spending 10 years in the software development business, a friend of mine and I opened up our own consulting company in 2001.  Our company was based on one single Microsoft product in which we would offer consulting services for.  That product was BizTalk Server which is a message oriented middleware product for exchanging disparate data and orchestrating business processes across multiple applications.

 

Over a four year time frame, we custom designed and constructed twenty-five or so integration solutions using every version of BizTalk Server. Even after that many projects, our process for designing and constructing these solutions was still far from being predictable and repeatable.  Sure we got (much) better, but we realized it was the variability that was so difficult to overcome.  I mean variability in everything that is software and the processes used to design and construct it.

 

For example, there is always large variability in the quantity and quality of software requirements.  A very small percentage of customers know exactly what they want, more still know exactly what they want, but can't articulate it, all the way to the other extreme where customers have no idea what they want, but still want something built.

 

For every single "discrete" chunkable requirement, there seems to be at least a dozen ways to design it.  For every design, there seems to be almost infinite ways to implement it.  When I say design, I mean a particular design for a particular requirement in which the chunkable output of the design is on the order of 40 hours effort per one developer to complete the requirements, finish a detailed design, code, test the chunk and done.  The culmination of designs to meet all of the requirements is called the software architecture.

 

Case studies and industry reports point to inadequate and/or always changing requirements as one major contributing factor as to why software development is not a predictable and repeatable process.  Another contributing factor is size and complexity of software development where it is most always underestimated.  I would be the first one to agree with both statements, but I would say that this is more symptomatic then the root cause.

 

Yet another contributing factor to why software development is not a repeatable and predictable process is programmer productivity.   I have worked with over a hundred software developers in my 15 years in the industry and I can say that programmer variability is just as broad as the other contributing factors as discussed above.  There are several books that quantitatively put programmer productivity variability levels in the range of 20 to 1 and even 100 to 1 between programmers that have been assigned the same code project to, design, construct and test the software.  I have seen the extreme with my own eyes where some developers can't write the code no matter how much time was given, while others can write it in two weeks flat.  Thats off the chart in terms of variability.

 

One of the reasons for the wide variability in programmers, aside from the skill sets discussed in the previous paragraph, are the tools that are available for programmer use.  The tools themselves are incredibly complex environments and sometimes require people to think in ways that they may not be able to grasp or it is so complicated, no one can figure it out.  I can't grasp C, but I grok Smalltalk from a programming language point of view.  When we asked a printer to print the help file that came with BizTalk Server 2004, he called us to say it is likely going to be 10,000 pages and cost $500.  That's just one product!  And we use a half dozen other products for designing and constructing our integration solutions including, SQL Server, ASP.NET, Visual Studio IDE, Windows 2003 Server, SharePoint Services, C#, FrontPage, .NET Framework, and on it goes.  While some of these products are not the same size and complexity of BizTalk Server, they require deep understanding of just what they heck they do and how all the products fit together in order to provide the tools and framework to design and produce the Customer's solution in any reasonable time frame (read: cost).  Even the .NET Framework Class Library alone has over 5,000 classes to get to know, some very intimately.

 

These are tools and technologies from one vendor!  What about multiple vendors?  Also every vendor seems to be pumping out the latest and greatest tools and technologies every year.  Where does one find the time?  Answer: one does not find the time which results in peoples knowledge of these tools and technologies, plus the specialized skills required and experiences to use them effectively, varies wildly.  This is another major contributing factor as to why software development is not a predictable and repeatable process - the programmer never gets a chance to gain years of experience using one tool or even small set of tools - so everything is (always) new.

 

Even within the Microsoft technologies mentioned above, there are many technologies that do more or less the same job (but the tools are totally different) for one specific area - user interfaces.  There are (at least) five Microsoft technologies for developing user interfaces. To me, it is mind boggling why even within a single vendor, that not only are there five different technologies to develop user interfaces (actually 7 if you count InfoPath and SharePoint Designer), there are multiple tools for each technology.  For example, ASP.NET - there is Visual Studio and FrontPage.  Both have very deep features, but the tools are completely different.

 

Some would say introducing standards would alleviate this problem.  While I concur and it has proved to help industrialize other industries (e.g. electronics), it is still early game in the software world and the technology advances far outpace the speed at which standards can be ratified.  Also, believe or not, Microsoft's latest technologies are all (mostly) standards complaint and all with public specifications. So what's the value of standards?  What our industry needs is innovation.  What would be truly innovative from Microsoft (and other vendors) is simply one technology and tool that produces any type of user interface you want.  From a developers perspective, this means being able to focus on "one" tool or technology to do a specific task, like designing and constructing any type of user interface.  With one tool and language (for user interfaces), then we might have a hope of industrializing software development.

 

Let me put it another way, how many people do you know that are fluent in six foreign languages or more?  How many of those people are fluent in both the spoken and written word?  Have you ever tried learning a foreign language so you are just as fluent in it as your native language?  Learning and becoming fluent in any foreign language is no easy task.  But for software programmers, we must learn multiple foreign languages to design and construct software.  It may even be tougher than learning a traditional foreign language as our programming languages regularly change including the introduction of brand new ones (e.g. XAML). This gives some insight as to one of the major reasons why software development is not a predictable and repeatable process even for the software programmers.

I live in a small town of about 5,000 people on the Sunshine Coast in BC, Canada.  Meeting my neighbors Grandpa was an interesting experience.  Grandpa grew up in the Northern part of the Sunshine Coast and has lived here most of his life.  I got to know him a bit when we were launching fireworks (its big here!) last Halloween with our families.

 

Over 4 months I would have occasion to bump into Grandpa on the ferry as I take a 40 minute ferry ride into Vancouver everyday, as does anyone that needs to make it to Vancouver from the Sunshine Coast.

 

Yesterday, I was sitting at the local Tim Hortons having a coffee and working on my new Acer 8204 laptop (which I purchased specifically for WinFX, Vista development), and I met Grandpa after I had been sitting for an hour, long enough for me to disappear completely into the computer.  He said, Are you actually doing something or trying to look intelligent.  I said I was coding.  He said, What do you do for a living.  "I write software".  He said, that he used to program assembler way back when.  He said, "if just one letter or number is off, it doesnt work!.  I said nothing has changed.

 

First, I was a bit taken back that he could even remember assembler, I cant, and he does not even remotely look the type.  Second, I was surprised by my own comment of nothing has changed since assembler.  Now really, we have come a long way since assembler, see Raising the Level of Abstraction .  But otoh, it is still true today one character or number is off in your source code that you are hand writing and it wont compile.  It is much easier to find the compile error today, I suppose.  And with Intellisense, how can you miss? (ha ha).  The point is, the computer is excellent at repeating precision instructions and we humans are not.  So why not get the computer to do the work of writing precision code based on a higher-level abstraction (i.e. tool) where we don't concern ourselves with hand writing low level code.

 

This makes me wonder about how far programming languages have come over the last twenty five years.  Personally, I am a Smalltalk fan.  The concept of everything is an object and message passing made much more sense to me than C.  The fact that objects in Smalltalk could do only three things made it easy for my brain to understand what was going on.  However, from an employment perspective, I chose and have been working with Microsoft technologies since 91 when VB1 was first introduced.

 

The only language that has come my way that makes me as excited like Smalltalk did is XAML.  I have discussed a bit about XAML in my previous posts.  Here is a snippet from the WinFX SDK help file for Build 5308:

I am impressed with XAML.  It is early game, but GDI has done well for 20 years, Microsoft is betting on XAML, WPF, WinFX and Vista as a worthy successor to GDI and hoping it will last as long.  For the computer user, the next generation XAML based applications will be like when HTML first hit the web, (then FLASH), where everyone, all of a sudden, is a web site designer   However, what shakes out is the next level of computing interactions based on these Microsoft technologies.

 

However, to make life a bit confusing, XAML is but one of the 5 ways, just using Microsoft Technologies to develop user interfaces.  Tim Sneath has an interesting angle on explaining these five UI technologies called, "Windows Forms, ASP.NET/Atlas, DirectX, WPF, Win32 - that's five UI technologies to choose between. How do I decide?"

 

Having read his article I am satisfied that using XAML and WPF to develop my Storyboard Designer Application is the right choice.  Once I have developed something, I can say to Grandpa that we dont have to worry about each individual character or number anymore, thats what the software tool does!

This last post in the series is to describe a few more details around the Storyboard Designer application I am building.  Storyboard Designer is targeted at Power Users and/or Business Analysts (BAs) to enable a quick way to design and construct custom business user interfaces, which will in turn become business applications. The application will allow for the design and construction of workflows, business rules and data access associated with these user interfaces.  This is done so in a storyboard fashion similar to what has been successfully done in the film industry for over sixty years.

 

Whats different about Storyboard Designer than other storyboard type applications?  From a marketing perspective it is targeted at business Power Users and/or BAs tasked with defining the requirements and specifications for a custom business application, including the UI, workflow, business rules and data access.  The idea is that requirements become specifications as defined (read: modeled) by the BA using the designer.  Since we are using XAML, the resulting specifications become the implementation.  Key point.

 

Storyboard Designer has a drawing canvas that will allow the organization of businesses and business applications.  A Power User can drag and drop UI components onto a canvas to build a user interface in XAML.  Storyboard Designer will offer catalogs of composite UI parts that are commonly used in business applications, plus the capability to reuse complete user interface definitions for common business objects like Invoices, POs and any other set of forms for that matter, built or purchased, all XAML.

 

One design goal is to ensure the BA can define (read: design) a business application using Storyboard Designer without writing any code.  Or at the very least meet the 80/20 rule.  Another goal is to provide an intuitive drawing tool that will allow the BA to specify (and as a result, implement) a business application in the shortest time possible.

 

Toolboxes of components will represent real world business application constructs, for example, an invoice form, people interacting with the invoice form in a workflow, invoice form business rules and invoice form data, all need to be easily specified (i.e. drawn) on the canvas.  In addition, objects need to be configured and hooked together to represent a real world business application.

 

Using XAML, we can more easily come up with a 3D virtual world that represents these objects in a way that dozens or even hundreds of user interface screens (plus associated roles, workflow, business rules and data for those screens) can be easily navigated to on the canvas, as thumbnails.  Clicking on any thumbnail will zoom the object to screen for editing.  Those that have played with the workspace zoom in Expression Interactive Designer will know what I mean as an analogy.  XAML will provide, layering, zoom capabilities and levels of transparency to show the connections to the various objects without the screen real estate becoming overwhelming or cluttered.  Look at how Google Earth or Virtual Earth is displayed essentially on one canvas using layers and zoom.  AutoCAD works in a similar way.  Storyboard Designer will implement similar concepts except we are looking at a map or CAD blueprint of a custom business application from a 3D drawing perspective.

 

Over the coming months I will put together a prototype of Storyboard Designer based on the specs described in this series.  I will come back to this topic when something is built.

 

The purpose of this ten part series was to discuss industrializing parts of the software development process we use to design and construct business software.  Storyboard Designer is my small contribution to industrializing software.  I have been in the software development business for 15 years and one conclusion I have come to is that the state of the art of developing software today is still trial and error most of the time.  Further, rarely does what we build meet what the business user actually required.  This is the semantic gap between requirements (i.e. the intent of the business application) and the executables (i.e. the ruin-time business application).  Talk about lost in translation!

 

Storyboard Designer provides the capability for business Power Users and/or BAs to easily draw business applications using a 3D visualization tool with the output being the actual executables for a custom business application.  Not only does the tool close the large semantic gap between requirements and executables, more importantly the tool can be used by the very people that know everything there is to know about their own business and what the business application is supposed to automate.  As a result of these tool capabilities, the time frame for designing and constructing business applications is dramatically reduced and on its way to becoming a predictable and repeatable process for delivering business applications that actually meet business user requirements.

 

Lets see if I can make this real

As described at the beginning of this series, I have a specific requirement for a Storyboard Designer application.  The specific requirement is to industrialize some level of the software development process used to design and construct business applications. The rational is that the end-user of a business application interacts with software through a GUI 100% of the time.  Therefore, provide a designer tool aimed at Power Users and/or Business Analysts (BA) who can quickly storyboard user interfaces, workflows and data access in the shortest time possible.  Storyboard Designer is not a traditional developers tool, but rather a visualization tool that can be used by a Power User and/or Business Analyst (BA) to quickly build scalable and robust business applications.

 

Think of it this way, senior management at FedEx, in the book, Reeenginering the Corporation, realized that the people actually performing the work on the shop floors knew their business processes inside and out.  And more importantly, knew what most of the solutions were to the problems they were encountering using traditional business applications and consequently, the business processes they imposed.  As a result of senior management listening to employees in the trenches, FedEx reengineered their way into an incredibly successful business.  In other words, they were the first to industrialize the way packages were shipped and delivered for a specific market.

 

Remember the introduction of FedExs online package tracking software?  So simple that anyone with some degree of being able to navigate the internet could use this tool.  Thats why it became #1.  Another example, closer to home in the software world, is MS Access and Excel, which are reasonably complicated software, but yet Power Users and BAs have developed an entire subculture of business applications running organizations today.

 

With respect to Storyboard Designer, a Power User and/or BA (the people that really know the business application in question), can create their own business applications in the shortest time possible.  The goal is to quickly create or reuse user interfaces, (composite controls and complete UIs from catalogs), plus being able to visually hook up the UI to a data source or workflow, with or without business rules and all without writing any a single line of code.  Is it possible? 

 

From a marketing point of view, all that is required is to put a usable storyboard designer tool in the hands of the people that know how their business works so they can build their own custom IT automation applications to suite their specific needs.  Just like how they build sophisticated Excel applications and Access database programs today, except I am hoping much easier using Storyboard Designer.  Thats the level of abstraction I would like to achieve.

 

As discussed in this series of posts, I came to the conclusion that XAML would be an excellent language to not only build a Storyboard Designer, but also have the output of the Storyboard Designer produce XAML as well.  XAML can be used to declaratively define user interfaces and workflows that run on WinFX without any further interpretation.  In other words, once compiled, it can be run directly on the OS.  This is very powerful.  Even more powerful is that fact that XAML is public specification and therefore portable language format that can easily be exchanged with our XAML enabled tools.  This means it is possible to create catalogs of real user interfaces and workflows that can be shared amongst people.  The specifications become the implementations using the designer tool.  This dramatically reduces the gap between requirements (i.e. intent) and deliverables (i.e. executables) that is so prevalent in the way we design and construct business software today.

 

Storyboard Designer will be a visualization tool in which Power Users and/or BAs can draw their business applications on a canvas using toolboxes of objects that they can drag and drop on the screen.  Objects will represent UI, workflow, data access. people and businesses all connected together and can be viewed all together.  This is a key design goal.  It is in someway like traditional architectural blueprints in the construction or manufacturing industry.  Think AutoCAD for designing business applications. 

 

So doesnt Cider, Expression Interactive Designer (which I am still evaluating), SharePoint Designer offer this already?  No, all of these (low level) tools require highly skilled developers and designers to be productive with these tools.   Storyboard Designer is aimed directly at the Power User and BA for an organization.  We are raising the level of abstraction in the designer tool itself so that a Power User and/or BA with minimal training or expertise can productively build their very own business applications.

 

Next post will describe some of the design details of Storyboard Designer and then we will wrap up this series of 10 posts.

In this series of posts, I describe a real problem in the software development process of designing and constructing business applications.  Not only is the design and construction process trial and error, (i.e. not predictable or repeatable), there is a tremendous semantic gap between describing requirements (i.e. intent) and the resulting deliverable (i.e. executables).  The reality is that business users interact with software 100% of the time through a user interface.  Thats it.  Business users dont care about technology.  They care about getting their customized business application designed and constructed in the shortest time possible for minimal cost (including TCO) and perhaps more importantly, does exactly what they envisioned it do to.

 

Having designed and constructed software for business users over 15 years, it seems that using a storyboard designer application to define user interfaces descriptions and business workflows is one way to help industrialize the software development process.  Further a catalog or library of pre-built storyboards with corresponding workflows, would allow a business user to choose from a catalog a set of storyboards that would assist in defining their specific business application in a short time period.

 

After more research described in the previous post, it seems that completely abstracting user interfaces is still unrealistic given the immaturity of language standards and tools. XAML as an eXtensible Application Markup Language looks very promising for describing Windows user interfaces and workflow.  Since the reality is that the majority of business applications are targeted for the Windows platform, XAML appears to be a great way to quickly define business user storyboards that can immediately be run on XP and Vista.  XP and Vista can execute compiled XAML (i.e. C# code) on their run-time platforms with WinFX installed, and render the user interfaces and execute the workflows on the business users computer screen.

 

There are a handful of XAML applications and tools on the market that may provide an environment for quickly defining Business User storyboards.  As discussed in the last post, we are going to start to look at Cider and Interactive Designer, both from Microsoft and targeted at different audiences.

 

Cider is used inside of Visual Studio 2005.  Anyone that has used Visual Studio WinForms Designer knows how quickly one can define user interfaces.  However, using traditional WinForms, the problem is that the user interface description is tightly bound to the code-behind.  Cider on the other hand, uses XAML to define the user interface and is completely separate from the code behind.  The fact that Cider is embedded in Visual Studio means you can hook up your XAML with any programming language and other components, all within the IDE.

 

However, the quick synopsis is Visual Studio 2005 is a full blown Integrated Development Environment (IDE) and while fine for me as developer, it may cost too much and will be too complicated for a Business Analyst or Power Business User to rapidly define a business user storyboard.  Also Cider still presents a relatively low-level toolbox full of discrete controls, whereas I was hoping to have a library of common composite controls and even fully defined user storyboards (like an invoice storyboard) as catalog items to browse, select and edit.

 

While Cider is great for an IDE and directly targeted at developers, I was hoping to have a higher level of composite controls and catalog capabilities.  Also by raising the level of abstraction, I want a simple storyboarding application that is purpose-built to rapidly define business user storyboards that a Business Analyst or even a Power Business User can quickly define, including composite controls and cataloged items (i.e. completed storyboards) to select from.  This is the main goal of my storyboarding application.  Perhaps Cider can assist me in building this application.

 

We will come back to Cider, but first we will take a quick look at Microsofts Expression Interactive Designer which just released as its first CTP.  Next post.

Last post we discussed several different XML markup languages for user interface definition looking for a candidate language for designing and constructing storyboards or at least assist in building a simple storyboard designer if no suitable storyboarding applications exist.  I hinted that I found a candidate.  It looks like XAML is good language candidate.  A concise overview of this technology can be read in a recent Forrester article called, WPF Will Dominate Rich Client Development.  Carl definitely gets it.

WPF stands for Windows Presentation Foundation which is Microsofts new user interface presentation technology that runs on Windows XP and Vista through WinFX runtime components. eXtensible Application Markup Application or XAML is the design-time language that is suitable for defining and construction user interfaces and workflows that are separate from code-hind (e.g. C#) as this is the code interface separation point, sometimes referred to as the plug-in interface. That means the user interface and workflow definitions are 100% portable and are distributed through a standard plug-in package (i.e. XAML).  XAML can be shared between XAML design-time applications without any translation cost or loss of fidelity.  XAML can also be run on Microsofts new application execution environment, WPF for business user presentation of the user interface and WF for run-time workflow execution.

 

One very interesting paragraph in the article is, The key is that XAML is a description of the user interface, not an abstraction of the user interface.  This is a subtle but critical distinction.  Other XML-based user interface (UI) languages, such as User Interface Markup Language (UIML), have attempted to describe the common capabilities of multiple UI technologies or even devices, and in order to do so, they must abstract the specifics of a given platform into a common generic format.  Inevitably, something gets lost in translation. XAML makes no claim to universality; it describes Windows user interfaces.

 

Telling statement lost in translation.  While I was thinking of having my storyboarding application generate multiple user interface implementations for different platforms as a goal, it now seems unrealistic.  The reality is that most business applications are written with a Windows user interface, which ultimately is my target audience.  The fact that XAML describes a design-time Windows user interface description using an XML markup language that is completely separate from code-behind is a key technology trait required for toolability which is one of the key concepts behind why XAML

 

Carls article further states, picture a prototyping tool that could be used by usability specialists to rapidly prototype and test designs. Authors note: hey, thats my idea! Users could also consider defining web server based process flows and integrations in a business process tool and then easily handing off specifications for the interfaces of individual services to a programmer who will populate them in Visual Studio.  Interestingly enough, it is no surprise that business workflows can also be defined (just recently) using XAML in Windows Workflow Foundation. 

 

Next post we will explore a number of designer applications and tools for rapidly defining business user storyboards using, or can output XAML.  First we will look at Microsofts Orcas Cider as a CTP XAML designer in Visual Studio 2005 and the first CTP release of Expression Interactive Designer (aka Sparkle) which is a standalone product.

In part 5, I discussed a vision for a catalog of storyboards that represent user interface screens, business processes and the metadata that describes these storyboard definitions.  For example, storyboards are descriptions of a user interface i.e. they contain no technology implementation details, but rather metadata descriptions of the user interface elements.  This metadata can be used by code generators to generate a technology specific implementation.  As discussed in this series, a business user interacts with the user interface 100% of the time and does not care about the technology implementation or the technical details, the business user just wants their application ASAP and for a minimal cost.

 

Storyboarding in the film industry is used to minimize requirements risk and maximize production efficiency.  Storyboarding in the film industry models the complete film in a very short period of time and cost.  The design of the film is complete up front and then the actual construction of the film is an implementation of the storyboards i.e. film rolling, sound rolling, lights, actors, action!. The software industry could learn from the film industry.

 

Lets put the concept of a catalog of business user storyboards aside for the moment and focus on the tools and languages that are available to design and construct business user storyboards.

 

As a quick reference check, lets look at a storyboard tool that already exists to see if it meets my requirements.  A company called Caretta has produced this fine storyboarding application.  While I think this is an excellent storyboarding tool, it has no code generation facilities or even the ability to output a definition of the storyboards in any standard format.  This is unfortunate, as this storyboarding application would have met most of my requirements.

 

After more research, I could not find any storyboarding tools that meet my requirements, so we need to take a step back and look at some language standards for defining user interfaces.  I found a good reference to start from, XML Markup Languages for User Interface Definition.  There are several possible candidates to choose from.  AAIML, AUIML, XIML, XUL, XMAL, UIML, UsiXML, DIWG, XForms, and on it goes! 

 

It is amazing to see how many XML markup languages there are specifically designed for defining user interfaces.  It also is amazing to see what various stages each standard is at on its quest to becoming a real standard.  The process is slow and lengthy. I wonder if the electronics engineering world went through the same arduous process of becoming an industrialized engineering discipline. 

 

At one point in the electronics world, (70's) it seemed to all converge around the invention of the 14 pin DIP as a standard plug-in or interface that allowed chip manufactures world-wide to package their circuits in a standard package and distributed through a catalog.  Today, there are millions of different circuits on these chips in the market world-wide, all offered through standard plug-in packages.  This is a good example of "technology" industrialization where a standard interface is highly beneficial to the industry overall.

 

Ok, now what?  I spent the last week researching these XML markup languages for user interface definition, to find a suitable candidate for designing and constructing storyboards.  I think I found one that will work.  Next post we will look at the findings.

Lets take a break from whats new in software development for 2006.  In Part 1 and Part 2 of why software industrialization, I discussed some basic concepts around what does software industrialization mean and why we need it. Software industrialization is designing and constructing software in a predictable and repeatable manner.  Software industrialization is also producing a software, of any sort, that actually meets the user communitys requirements, whatever and whomever they happen to be.  Thats it.

 

In our software industry, there is a still a tremendous gap between requirements (i.e. describing the intent of the software) and the actual software deliverable (i.e. executables).  In fact, if you look at and believe statistics, our numbers aint so good!  The reality is that, we as software developers or engineers, dont have any predictable and repeatable process for creating software and we dont get the software right the first time.  In fact, we may never get it all right.

 

I have been involved in the software development industry for 15 years and have worked for several companies both in Canada and the United States ranging from my own start-up company, that I co-founded with Barry Varga, called, 5by5Software, now Bridgewerx to the very large (Kodak, Motorola and lots in-between.  Each company had their own process for designing and constructing software.  These development processes ranged from fly by the seat of the pants to highly process controlled CMMI complete with formal assessments.  In these companies I participated in several different development methodologies including RUP, extreme programming, Agile, old school waterfall for those that remember, and a mix of pretty much everything in-between.

 

I have read several dozens of books on the subject of software engineering, hundreds of articles and attended many a conference/seminar on the subject area.

 

Based on 15 years experience, I draw a few observations and maybe a conclusion or two:

 

1. Its still the Wild West" when it comes to software development.

 

2. None of the software development processes or methodologies that I have participated in has proven that one is no better than the other. The harsh reality is that manual labor software development is still mostly a trial and error process.  Meaning we are still far away from making it a predictable and repeatable process.

 

3. I have had the good fortune to work with several dozen extremely talented and brilliant software developers/engineers, project amangers, BA's, etc., who are directly responsible for the success of the projects/products I have participated in.  It is these people that have made the difference between success and failure and had nothing to do with processes or methodologies or toolsets or programming languages or technologies.  Its all about the people!

 

4. There have been a few critical innovations of late that appear very promising for increasing the level of predictability and repeatability of designing and constructing software.  These innovations are described in a book called Software Factories  

 

5. Another critical innovation is the renewed interest around Domain Specific Languages (DSLs).  Every programmer should take the time to read Martin Fowlers most excellent paper called, "Language Workbenches: The Killer-App for Domain Specific Languages?  DSLs assist in raising the level of abstraction for developers to produce software in a more predictable and repeatable manner thats the real point behind DSLs.

 

6. All the business user ever interacts with 100% of the time is the user interface, graphical, text or otherwise.  All the business user cares about is that through the user interface they can get at, manipulate, save data in an intuitive and functional manner.  Functional manner means that the software does what the business user expects or wants it to do.  In our technical world, this maybe written as workflow or business rules or custom C# libraries, or whatever development artifact(s) represents this functionality.  However, we software developers forget that the business user does not care how it is done, or what with - when I click on this thing, here is what I expect to happen, your software needs to do that.  Its that simple from a business users perspective.

 

Point 6 will be a topic of a future post, because after 15 years in the biz, I finally get the business user.  And interestingly enough, from a programmer perspective, not getting the business user is the number one reason why software projects/products failed in 1994, and still failing today