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

Best Database Managers for Developers


The technical management of relational databases is a highly mature technology in the software development profession. Many of the high-end tools such as those offered from Toad and Embarcadero are superlative with their capabilities but completely beyond the affordability for most individual developers, unless of course they need such powerful tools for their businesses and clients (Toad does offer freeware versions but they are somewhat limited).

For most of us, we tend to work with databases through client tools provided on their workstations or we use the individual offerings from such vendors as Microsoft, MySQL, and PostgreSQL to name a few. However, as good as these tools are, to use them requires understanding the idiosyncrasies that comes with each as all of them are proprietary to the database. This is not a major undertaking since all such database managers operate in relatively the same fashion.

Nonetheless, if you work with a variety of databases constantly and you do not require the extensive capabilities that come with the high-end offerings, working with a single database manager for all your efforts more often than not makes such work a much smoother process.

There are two such database managers that fit this bill and are in fact quite popular with many professional developers; Database.NET and the products from EMS Database Management Solutions.

Read more of this post

%d bloggers like this: