Archive for the ‘Software Development Lifecycle Management’ Category

How do I love thee? Let me count the ways.

Thursday, August 20th, 2009 by Sebastian Holst

“How do I love thee? Let me count the ways. I love thee to the depth and breadth and height” - Sonnet 43, Elizabeth Barrett Browning

So “what’s love got to do with it?” (Private Dancer, Tina Turner) Hint: if people live for love, then businesses live for money

On July 14th, Microsoft announced Azure pricing and a “grace period” through PDC 2009. A primary rationale here is to enable development organizations to optimize deployment and monetization models to maximize Azure commercial opportunities.

So, whether you are a romantic (like Ms Browning above) or perhaps more hardened like Tina Turner’s Private Dancer (or Stanley Kubrick a la Full Metal Jacket), one thing is for sure - Microsoft wants Azure to “love you long time.” How deep, wide, high or long is the question.

Check out a this article in SD Times - PreEmptive’s Dotfuscator instruments Azure applications By David Worthington – where Dave Worthington makes many of the very same points.

Of course, we announced Runtime Intelligence Service (RIS) Azure support to help developers answer these very questions. While perhaps not as soaring as a sonnet – Runtime Intelligence allows for any .NET component deployed into Azure to be injected (post-build) with session, feature and method level monitoring. The runtime intelligence is streamed out of Azure for analysis. Other than writing a custom solution, this is perhaps the only means to measure adoption, usage patterns and performance inside Azure in near real-time.

Now, my posts are all intended to help you (blog followers) find more ways to make more money (we want to spread the love). So, you will note that I very specifically said the RIS helps to answer these questions. What the Azure development community really needs is an ROI calculator that will combine real usage data (from both legacy and piloted Azure applications) with Microsoft pricing and the offset IT expenses to come up with an Azure ROI calculator. I know there are lots of calculators being written – but how many of them can incorporate actual usage data before and after deployment to the cloud? That’s not our business – but could it be yours?

If yes, let me know and I will make sure you have what you need to call our RI Service via our RESTful API – making your calculator uniquely able to reliably predict cloud ROI.

As always, i have a more philosophical take on this issue on my personal blog at http://apps-are-people-too.blogspot.com/2009/08/how-do-i-love-thee-let-me-count-ways.html

Back to the Future

Monday, August 17th, 2009 by Vadim Polner

Introduction

In this article, I will offer you a unique look at the rise of agile practices. You will see how core agile values of instant feedback and communication manifest themselves in different forms throughout history. You will see how Runtime Intelligence embodies the essence of agile software development, and how it helps software succeed.

The Age of Antiquity

Athens and Jerusalem! The rivalry between them resulted in major battles throughout history and spilled over to our times.

The book of Talmud, a magnificent compilation of biblical commentary and legal analysis, was put to writing in the ancient Babylonian academies of Sura and Pumbedita. Similar to Extreme Programmers of today, scholars worked in pairs, pouring over and discussing the meaning of incredibly difficult texts. To the Sages, the Text was the embodiment of the Master of the Universe Himself. It communicated to them in a very real and tangible way. Greek logic was an extremely useful tool, but not a solution to all of the world’s problems. In the dusty halls of ancient academies, the Sages perfected the art of close reading, reasoning by analogy, and pattern recognition.

The Greeks, on the other hand, perfected the art of logic, philosophy, and mathematics. The Universe could be a living organism to them, but it did not interfere with the lives of mere mortals. In the Greek mindset, the Universe did not actively communicate with us. The notions of theory, formalism, and proof - all made their way into our worldview through the Greeks.

The Age of Reason

Similar to the Greeks before them, the great men of the Enlightenment saw the world as a big mechanical device. The Universe functioned like a big clock, and human beings were like specks of dust in this gigantic mechanism. The world abided by a strict set of mathematical rules, and the future could be predicted if only all the variables were known.

The Age of Reason exerted its influence on software engineering as well. The field of program verification was consistent with its worldview. Programs were seen as mathematical structures whose correctness could be proven by analytical means without ever executing them. Program verification made great contributions to computer science, but it never replaced the empirical and intuitive approaches to software engineering.

The Age of Modernity

Our age witnessed the birth of quantum, chaos, and the Big Bang theories. The Universe is no longer a mechanical clock it used to be. All of a sudden, a human being becomes an active participant once again.

In modern software development, we see a shift from formal and theoretical approaches to people-oriented ones. Active participation and communication start running like golden threads through agile practices of today.

In the art of unit testing, for example, unit tests collaborate with you on several different levels. They communicate the intentions of your programs and allow you to concentrate on the implementation details later. Unit tests let you break the dependencies in your code and make your programs decoupled and cohesive. They provide you with an instant feedback about the overall health of your system. You can execute thousands of them and get a result within seconds or minutes. Unit tests give you the confidence you need when you try to adapt to changing requirements of the outside world.

In the age of modernity, your applications become active participants and communicators too. Enter Runtime Intelligence.

Runtime Intelligence and Agility

In the world of Runtime Intelligence, there are no theories to predict which features your customers will like. There are no formal proofs about your software usage. There are no surveys to figure out how your applications are used.

Similar to unit tests of the art of unit testing, your applications themselves communicate with you. Based on their instant feedback, you can quickly make important business decisions. You can see which features provide the most value for the money you spend, which features your customers rely on the most, and which features need further development. You can adapt much faster to the rapidly changing world around you. This is the essence of being agile.

Great ideas do not exist in an intellectual vacuum. They are often a reflection of their times. If we want our software to succeed, we must pay close attention to the lessons of history. As we embark on a journey back to the future, one thing is certain. Our past is behind us. Our future is still in our hands.

Lower the Cost of Knowing

Monday, July 6th, 2009 by Gabriel Torok

Before tools like Survey Monkey were available, you could conduct surveys. But the cost was much higher, often including costs of envelope stuffing,  outbound and return postage, incentives such as a dollar in each envelope (to try to increase the response rate), data entry costs, and long time delays. Given the hassle and costs, you might be forgiven for making important decisions based on sparse data. In America, it’s called going with your gut. The rapid proliferation of low-cost web-based survey tools is a clear indication that lowering the “cost of knowing” stimulates organizations to “go find out.” In the past, companies did not survey as extensively because they felt they couldn’t afford the higher costs, and perhaps they did not value knowing enough to invest more.

Likewise, before point-of-sale systems were widely available, retailers were able to track customers and their buying habits, but at a very high cost and hassle factor. It was probably easier to “go with your gut”. Now, point-of-sale systems are a multi-billion dollar a year business and retailers are at an extreme disadvantage if they don’t use one.

A lower cost of knowing continues shifts in our desire and use of information. Developments such as nearly free international communication to practically ubiquitous Internet search have made knowing quick and easy. For example, today it is possible to very quickly discover which vendor has the best price and service. Improved information allows everyone to make better and faster decisions.

And yet today, many software producers still take a reactive “go with your gut” approach to understanding how their customers use their applications and measuring the satisfaction they receive from them. That is because historically, it’s been difficult and expensive to measure how users - individually or in aggregate - actually use applications. In other words, they perceive the cost of knowing as higher than the value of knowing.

This will change as new options significantly reduce the cost of knowing for software producers. In tighter economic times such as now, getting low cost, accurate and timely insight into software behavior, stability and performance will become essential. Successful software producers will benefit from the value of enhancing the customer’s experience by proactively understanding problems and opportunities and acting decisively based on their knowledge. What your customers aren’t telling you might be hurting you. After all, why would you rely only on your “gut” or a handful of customers for feedback when you can easily listen to your applications in a broad and precise way?

Beauty and the Beast

Wednesday, July 1st, 2009 by Vadim Polner

Introduction

In this post, I will discuss beauty and technology. You will see specific examples of beautiful ideas found in computer science, ancient texts, and the latest creation of PreEmptive Solutions called Runtime Intelligence™. We will discuss the future of our industry and what helps software succeed. We will have a fascinating adventure through time and space. Buckle up, sit back, and enjoy the ride!

Complexity of software and technology

Technology is a complicated beast. One distinguished computer scientist remarked that he always dreamt of the day when a personal computer will be easier to use than a phone. Alas, he quipped, this day finally arrived when he no longer understood how to use his phone. Arguably, software is the most complex machinery known to man. With few keystrokes and limited only by the power of his imagination, a programmer can improvise machines of unprecedented complexity. How do we deal with these beasts, and what should be our guide?

Beauty

What is beauty? This topic fascinated the most brilliant minds in our history since ancient times. In his discourses, Plato talks about dividing nature at its joints and putting the pieces back together. The ability to do these things properly constitutes in his eyes the power of gods. In Plato’s ideas, a modern software engineer will recognize the concepts of coupling and cohesion that are central to the construction of high quality software. Christopher Alexander, an architect whose work inspired the design patterns movement, talks about “quality without a name” that recurs in great designs. This nameless quality is not in the eye of the beholder, he suggests, but can be objectively measured. One of the best definitions is given by Yale computer scientist David Gelernter in his fascinating book “Machine Beauty”. According to Gelernter, beauty is the marriage of power and simplicity. Achieving more with less is the hallmark of beautiful design. Unification and simplification are the driving forces behind great advances in science, technology, and other human endeavors.

Beauty in Systems Design

Alan Kay, the creator of Smalltalk programming language, uses the U.S. Constitution as an example of a beautiful system. After more than 200 years, it still functions without problems. The rabbinic Sages discuss the concept of beauty in the Talmud, monumental compilation of biblical commentary, law and homiletics. Talmudic tractate Sukkah 35a analyzes the Hebrew word for beautiful, hadar. The Sages conclude that it is the yellow citron tree, because the word “hadar” is interpreted to be a fruit which “dwells continuously all year on the tree” (ha-dar, literally, “that which dwells”). Thus, they understand the word “dar” to mean permanence, a continuous process through time, similar to the French “duree” or the English “endure”. In other words, beauty implies something that doesn’t lose its relevance over time.

Beauty in Computer Science

One of the most beautiful ideas in computer science is object-oriented programming. Alan Kay describes the epiphany he had when he finally got the idea of recursive simplicity inherent in object-oriented design. He realized that instead of dividing computer program into weaker things called data structures and algorithms, why not divide it up into little computers that have the same power as the whole. The designers of Simula-67 carefully studied Algol-based languages and made a startling observation. In order to execute a procedure in Algol, a local environment is created, which exists only for the duration of the call. Why not let those environments stick longer indefinitely, the designers observed, and let them communicate with one another. This led to the creation of the first object-oriented programming language that allowed software to be based on the real world structure and greatly simplified the design and construction of complex programs. The beauty of Simula-67 design was that tremendous power was achieved by utilizing already existing constructs. The idea of object-orientation was latent in the design of Algol waiting to be discovered.

Beauty in ancient texts

Biblical stories are some of the best examples of power and simplicity. As little children, we learned the story of creation of Eve from Adam’s rib. But did we know that the same story also contains deep insights into human nature and the Universe? Analyzing the text, the talmudic Sages make a startling observation. The Hebrew word “va-yiven” (created) used in the story exclusively in relation to Eve comes from the Hebrew word “binah” (understanding, intuition). After careful text analysis, the Sages conclude that when God created a woman He endowed her with greater intuition than a man! This is not a revelation to the better half of our readers who knew it all along, but this illustrates how a little story simple enough for children to understand also contains powerful insights into the makeup of our psyche. The power has been latent in the text waiting for us to discover it.

Beauty in Runtime Intelligence™

We finally come to the latest and greatest technology from PreEmptive Solutions - Runtime Intelligence™. In a flash of insight, the designers of Dotfuscator realized that in addition to obfuscating applications, why not let businesses inject additional code into their binaries that will talk back and provide all kinds of information about the way their software is used. In the age of agility, timely feedback is one of the most valuable assets. With a few simple clicks, organizations have a new powerful way to protect, manage, and monitor their software applications. This includes feature usage, shelf life expiration to stop applications from functioning after an expiration date, and tamper detection that allows an application to detect whether it has been hacked and take an appropriate action at run time. With aspect-oriented programming techniques, no additional code is required. Code that doesn’t have to be written is the most beautiful code there is. Runtime Intelligence™ allows you to do that and more. The power and simplicity latent in its design speak for themselves.

Helping Software Succeed

Why is beauty important in technology? It is important, because it helps us to be more competitive by achieving more with less. It helps software succeed. Beautiful code is easier to read, modify, and extend, and it saves us valuable time by letting us concentrate on solving increasingly complex problems. The recent rise in popularity of agile methodologies that put great emphasis on aesthetics of software development is a testimony to this view. As more sophisticated machines are developed, beauty will continue to play an important role in technology. As we enter the next decade of the 21st century, let’s hope that beauty will finally conquer the beast.

How to sell to over one million .NET developers with VS 2010 and VSTS 2010

Monday, June 15th, 2009 by Sebastian Holst

Roughly 15% of all Visual Studio developers have used Dotfuscator Community Edition (CE) to prevent reverse engineering (and I think we can all agree that this is a relatively specialized requirement). If you accept the next uncontroversial assumption that more developers would want to know who is using their software, how and why than would be concerned about reverse engineering – then we can also assume that the new Dotfuscator CE that includes application monitoring capabilities will be adopted by perhaps 2X or even 3X more developers – or between 30% to 45% if the 6 million+ Visual Studio users.

This next series of posts will outline specific opportunities for entrepreneurial developers to build solutions targeting the millions of .NET developers likely be using these new capabilities as VS2010 reaches general availability.  For an earlier example of this, see my blog entry how to make $5 from every .NET developer on the planet.

Post 1 – Code coverage!? I got your code coverage right here pal!

If you think development teams would benefit from being able to readily reconcile testing code coverage results with beta usage code coverage to improve quality and reduce development costs – read on…

With VS2010 Dotfuscator CE feature tracking, you can stream back feature usage during a beta release that can provide a complete picture of what methods were called, in what order and on what technology stack. If only there were an easy way to not only visualize this in the context of the application’s code base but also to overlay this information on earlier testing code coverage results to ensure I have tested what is being used and my beta users are using what I think needs to be tested! That might be an opportunity…

We’ve got an “opp” for that! (apologies to the iPhone ad guys). If you have evaluated VS Beta 1, you may have already noticed that VSTS 2010 Architecture is a completely new release which leaves behind the current Distributed System Designer and the underlying System Definition Model (SDM ) and replaces them with the Unified Modeling Language (UML), Domain Specific Languages (DSLs) and other tools that are not related to UML. The specific tool I want to point to here is the Architecture Explorer (AE).  AE visualizes relationships inside code using the Directed Graph Markup Language (DGML). By extending the DGML, one can use the Architecture Explorer to create visual models of assemblies – post-build – combining both the relationships inside the code (this comes with AE out of the box) and testing and usage coverage results by extending the styles already included in AE. In short, The Architect Explorer with its DGML support and the ability to extend/modify styles offers an ideal means to quickly reconcile usage data with testing code coverage (and platform and framework coverage as well).

This screen shot shows a generic rendering inside the VSTS Architecture Explorer. The rendering is entirely driven through XML data and, as such, can be easily extended to provide specialized views that are relevant across the entire lifecycle of an application.

In this case, the color schemes (or fonts or sizes) can be driven by:

The level of testing completed as reflected inside a TFS repository to quickly answer the questions

  • Testing status – how much testing has been completed?
  • Testing the right things – are there components that should be getting more (or less) attention?

The level of usage by beta test users as reported via the instrumentation capabilities included in Visual Studio 2010 Dotfuscator CE to quickly answer the questions

  • Beta adoption sufficient – have enough users actually run the software through its paces?
  • Critical path coverage – are the new components being exercised as expected?
  • Testing coverage map to usage profile – combining both testing data and usage coverage data can identify areas of code that are not being tested sufficiently given the patterns of usage that are being observed? (mash up)
  • Platform/framework coverage – are enough users evaluating on Vista SP1 or .NET 1.1 or …?
  • What exceptions have been detected that have not been reported through other channels?