Common Sense Software Engineering: Windows Developers Should Follow the Stable Infrastructure and Development Environments of the Java Community and Forget the Hype



In the 1990s when Java began to appear on the developer scene it met its competition from Microsoft head-on in that it struggled to gain an acceptable place within the international development community.  However, over the years Java appears to have arrived at more stable set of infrastructure and development standards than Microsoft appears to offer now.  This is the result of both communities taking maturation trajectories that were in a very real sense diametrically opposites of each other.  Microsoft, at the time, was offering maturing technologies while Java was the “new kid on the block”.  Both communities also offered completely different viewpoints towards their product developments.  Microsoft offered products with “ease of use” as the underlying factor allowing developers to quickly create both desktop and web applications far more quickly than competing solutions.  This was especially true when compared against the new Java tools.  However, Java had its founding basis in the academic and scientific arenas.

One could see this easily with the many Java articles that took apart various interface controls that we in the Microsoft Community took for granted with the exception of third-party control developers.

The Java Community did have a difficult time to get its place as an accepted form of development until it presented an alternative to Microsoft products in the large enterprise development area, which was Microsoft’s weak spot since Microsoft products at the time were targeting division and department level applications.  Once Java tools became more usable for developers, the large enterprise arena saw the advantages of Java development with its better suited enterprise offerings (ie: J2EE, and later, the Spring Framework).

Today, we find a Java Community that appears to be far more stable than that of the Microsoft Community though one would not know it with the subdued reporting around it.  Years ago such reporting was quite different as the two communities fought each other for developer supremacy  Reading online magazines such as today, most of the articles appear to concentrate on existing technologies along with their refinements.  The opposite appears to be true for Microsoft, which seemingly approaches product refinement the way the US Pentagon approaches new weapons procurement; both throw out perfectly fine technologies and start over with brand new and completely untested concepts.

In this author’s opinion, and as one who has worked with Microsoft technologies his entire career since leaving the mainframe world around 1989, Microsoft has made some serious mistakes with not only the products they are offering but how their style of developing applications has changed over the years.  This appears to have happened most egregiously with the latest CEO of Microsoft, Satya Narayana Nadella, while under Steve Ballmer; Microsoft appeared to be more stable in this regard despite his terrible reputation.

Read more of this post

The “War Game” and Understanding Complex Application Development


Author’s Note…

Please note that the use of the words game, war game, and simulation are all used interchangeably through this paper.

Merriam-Webster Definition: “War Game”…

a military training activity that is done to prepare for fighting in a war

a simulated battle or campaign to test military concepts



This piece is a somewhat more radical departure from those that I have written before as it is both a sociological and technical one at the same time.  This writing attempts to demonstrate the use of a completely unrelated subject to assist in the development of one’s mind to allow it to understand and encompass large-scale complexities that are most often the underlying foundations in similarly large application development.  This piece uses the somewhat forgotten genre of the historical simulation or war game to promote this concept.

To be sure there are a variety of other pastimes and hobbies that can provide the same orientation.  Writing for example, is one of them.  However, for the technically oriented mind and also from my own experiences, I have found the war game to be an excellent departure from studying technology to learning something completely new and possibly alien that will help younger development professionals grasp the complexities of their careers from a different point of view.

There are many types of war games that are available to the public as well as several commercial versions of military-grade training simulations that can show how actual military officers are trained in the matters of violent conflict.

From still popular board-games that require face-to-face interaction with players to computer-based simulations with increasingly powerful artificial intelligences that also offer Internet and Play-By-Email (PBEM) options, there is literally something for any period in history one may be interested in studying, recreating, or altering…

Read more of this post

Common Sense Software Engineering – Part VI; Function Point Analysis



“Function Point Analysis” is probably as close to a pure engineering paradigm as one could get. It was designed to allow professional software developers to determine the size of a software development effort by attributing calculated metrics to each individual component that would make up the entire endeavor.

There are a number of variations of this process, including more recent developments, but this paper will explore the original paradigm so that developers can have an initial starting point for further research. The original methodology, though a bit complex, can provide just as accurate a forecasted set of metrics for any software development project as the more recent developments for this technique.

It should be noted that “Function Point analysis” is not very well suited for maintenance tasks since many such tasks would be considered quite compartmentalized and usually only involve only one or two individual developers. As such, these tasks often do not require the in-depth analysis for scheduling that major endeavors require.

However, for new endeavors or even complex modifications to existing systems, in-depth analysis of the effort requires some level of accurate forecasting for the time it would take to complete. This is what “Function Point Analysis” does, and it does it quite well. Despite the claims by many Agile promoters, software development can be measured effectively and subsequently provide accurate estimations of how much time it would take to complete a certain task within a development effort.

And despite the promotion of rapid delivery of finished products in today’s hyper-fast technical environments there is little to support such speed except for a lot of discussion for the best processes that will deliver such capabilities. Human beings can work only so fast and be effective.

Read more of this post

Common Sense Software Engineering – Part V; Estimates & Project Metrics


“Agile” and the Problem with Estimates

 In today’s increasingly fast paced development environments much is discussed on how to develop applications more quickly and what efficiencies can be implemented towards getting them into production. Starting with “Agile”, which advances rapid application development to new extreme levels we are now moving into an additional era of “DevOps”, part of which is to support continuous integration of applications into production. Despite some of the gains in efficiency in both areas there is still little discussion on how one gets to efficient application development in the first place. In fact, there have been very few documents written on how one estimates and schedules new and ongoing development efforts within the criteria that the “Agile” paradigm promotes; though there may be actual techniques involved, little is portrayed about them. However, in lieu of this articles are beginning to appear that are detailing the ongoing issues even with this very popular process paradigm.

One such article, which recently takes a high level look at these issues can be found at the online edition of Forbes at…

The article’s author states right up front that “Agile” is continuing to have issues beyond the basic task and small-project levels as follows…

“Nevertheless, the problems and limitations of Scrum and the broader Agile movement have proven surprisingly persistent, in spite of the throngs of very smart people who have worked in various capacities with Agile over the years.

The numerous complaints about Agile include its lack of focus on software architecture, its emphasis on one-off software projects as opposed to building reusable code, and the reinforcement of the notion that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.”

Interestingly enough, it suggests that not enough is being done to correct these issues, which could boost the “Agile” paradigm to next level, which is interpreted as a mixture of the “Agile” and “DevOps” paradigms. However, if one analyzes this prospect it may do more actual harm than good if you intend to build a new paradigm based on one that is beginning to show significant limitations.

One of these limitations is that the “Agile” paradigm has made a serious but successful attempt at removing or limiting the reflective aspects of software development. One such aspect is that of project estimates and subsequent scheduling.

Due to the large numbers of organizations that have refused to understand and implement quality project estimate analysis, which actually follows engineering paradigms, companies have floundered consistently in their attempt to implement software projects on time and within budget, that satisfy user expectations. If you remove or ignore such a vital aspect in software engineering you cannot possibly label what you are doing as software engineering as Yahoo has recently done by eliminating another such vital aspect to the engineering process, that of Quality Control.

Though the claimed results in that organization are significant from such a function being moved into the development arena there are two issues here, which have not been explained in this recent announcement (see… One, there is no mention of the types of projects that Yahoo is concentrating on to make such statements credible or questionable. Two, there is no evidence that by making such a move developers can exceed the maximum percentage in their ability to unearth defects, which has been thoroughly researched to be a consistent approximation of 60%.

Read more of this post

2010: The Deconstruction…

2010 - The Deconstruction

Initial notes…

The following piece is a sociological analysis of the state of professional software development today. As one who is not just a senior software engineer but a military historian\analyst as well, I have brought together the skills of both these areas of expertise to demonstrate to the technical community at large that what is happening to our profession has nothing to do with innovation or new opportunities in application development but instead is an ongoing process of terrible, deleterious, degradation that has professionals everywhere concentrating on abstract concepts, useless paradigms, and redundantly, new tool introductions without any analysis as to the benefit of their application to the development of new applications. In fact, little has been reported on the success (or failure) of application development itself, as this aspect of reporting has been pushed aside for the less relevant aspects of our profession. Is it not the final product that is important and not what makes it?

The negative results of this process are staggering and are not simply the result of a software profession overwhelmed by marketing hype and vendor misdirection both supported by an avalanche of “me too” groups of young professionals trying to insert their own ideas but is as much also a symptom of what is happening to societies in general.

To understand that this deterioration is not isolated to our profession alone, one should take a look at the article at Russia Insider at The article is written by a US military analyst and provides some in-depth details as to the state of the US Armed Forces and intelligence agencies. You will also find some of my own historical notes in the comments section below it.

To add to this, one may also want to see John Oliver’s piece on the state of US nuclear arsenals, which is both hilarious and terrifying at the same time ( Much of what Oliver reports has already been reported in the mainstream news outlets.

Cognizant functionality in life today is quickly deteriorating in all areas of industrialized societies into nothing but a cacophony of gibberish and nonsense, not to mention the terrible social and political traumas being afflicted on citizens across the globe along with horrific conflicts and their affects. The software development profession has not been immune to these trends…

Read more of this post

Common Sense Software Engineering – Part III; Risk Analysis


The following piece describes a process for performing “Risk Analysis”, also known as “Risk Management”. What the reader will find is that contrary to popular development paradigms, true software engineering practices require quite a bit of upfront analysis for new project development as the prior piece on “Requirements Analysis” demonstrated.

In the frenzy of the so called “new development environments”, many technical managers as well as professional developers have attempted and still are attempting to find techniques that will allow them to avoid such in-depth processes and yet still create quality software deliverables. No matter how much marketing, PR, and other technical propaganda is thrown over the issue of quality analysis, without it, quality will never be part of the end result.

On another note, the reader will note that Steve McConnell and other software engineering analysts of years ago are relied upon for this work as has been the same with the other articles. Steve McConnell’s 1996 classic, “Rapid Development”, to this day has never been refuted and is still in fact being corroborated by subsequent studies in this arena. As a result, for many quality business technical personnel, it is still considered the “Bible” of software engineering.


One of the most important aspects of the management of any software project, large or small, is the management of risk. “Risk” in terms of project management, is any situation that either prevents a project from reaching a successful and timely conclusion or interferes to delay a well-run project towards that same conclusion.

Overwhelmingly, IT project management ignores this very crucial aspect of software development. As a result, project development schedules are affected negatively with the same managers putting pressure on their staff to make up for lost time, when it should have been properly planned for.

Every software project is faced with risks of all types and severities. In fact, any endeavor is faced with similar potential obstacles to completion. If you attempt to climb a mountain you risk the possibility of breaking a limb and in the more treacherous climbs, your life.

Read more of this post

Common Sense Software Engineering – Part I; Initial Planning Analysis


Trying to Avoid It… Among other things…

Since the advent of “Extreme Programming (XP)” in the early 2000s, software professionals have been attempting to find new ways to develop quality applications under increasingly tighter deadlines, smaller budgets, both with declining resources. Much of the thrust of these efforts has been the result of pressures that were forced upon IT organizations from the increasing traumas of the then new business fad of outsourcing in-house talent to less expensive foreign firms. In a very real sense the traumas visited upon the professional software development community, especially in the United States, encouraged the increasing avoidance of proven strategies in order to satisfy technical management that were under the same pressures to produce but did not have the courage to manage the deteriorating circumstances properly.

Read more of this post

%d bloggers like this: