Archive

Archive for the ‘Custom Development’ Category

The Facade Pattern – Don’t Talk to Strangers

June 18, 2009 2 comments

Ben Yoder the Facade Pattern

June 19th 2009 | Ben Yoder

The Facade Pattern – Don’t Talk to Strangers

The Facade and Adapter patterns are two closely related and easily confused designs. Both patterns create a layer between two interacting classes but the objective of each is significantly different.

While the Adapter pattern encapsulates the communication between two classes, the goal of the Facade pattern is to simplify wiring in a set of actions leveraging a complex subsystem of code, such as a group of legacy classes, or a third party vendor’s class library or API. If you ever need to integrate a third party system or an open source library and find yourself entangled in outside dependencies and overly-complicated sets of method calls, a Facade refactoring can help you.

There’s a good chance you’ve created a facade pattern on occasion without realizing it. As an oversimplified mechanical analogy—when you start a car, you don’t go through the separate steps of combining an electrical spark with gasoline in the engine cylinder while simultaneously cranking the engine to achieve compression. Instead of worrying about the complicated series of steps involved in making a car start, you simply turn a key which creates some magical action that starts a car.

The engine ignition switch is our facade class. It hides the ugly workings of the engine from us and we simply say “Make Go” and it works.

    public class SparkPlug
    {
        public void Spark(){…}
    }
    public class FuelPump
    {
        public void PumpFuel() {…}
        public void ShutOffFuel(){…}
    }
    public class Starter
    {
        public void Crank() {…}
    }
    //Encapsulates starting logic
    public class IgnitionSwitchFacade
    {
        public void StartEngine()
        {
            FuelPump pump = new FuelPump();
            SparkPlug plug = new SparkPlug();
            Starter starter = new Starter();
            pump.PumpFuel();
            starter.Crank();
            plug.Spark();
        }
    }
    //Client Code that interfaces with the Facade
    class You
    {
        static void Main(string[] args)
        {
            IgnitionSwitchFacade ignitionSwitch = new IgnitionSwitchFacade();
            ignitionSwitch.StartEngine();
        }
    }

This bit of code is contrived, but it demonstrates what’s so powerful about the Facade pattern and how it differs from the Adapter.

While the Adapter is concerned about sitting between the client and an interface, the Facade’s aim is to encapsulate common logic or instructions of a subsystem for the client’s consumption.

The goal of the Facade is simplicity. It provides a common gateway to the class library which can be easily modified and called rather than dealing directly with the logic and classes it hides.

Read David Cooksey’s The Adapter Pattern, A Code Diplomat

Ben Yoder is a Senior .NET Consultant at Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship password management software product.

My two and a half cents – pitfalls with rounding

March 19, 2009 Leave a comment

Secret Server at FOSE tradeshow

March 19th 2009 | Tucker Croft

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:”Calibri”,”sans-serif”;}
True or False: these values are the same?

1.       61.64598913 saved to DataBase Column :[Age] [decimal](10, 2)

2.        Math.Round(61.64598913, 2)

What does (1. == 2.) return?

False. Bryant and I came across an interesting issue when comparing two values that appeared identical, but which the code insisted were different.   Our research lead us into the internals of ASP.Net rounding to solve an infrequent but legitimate concern.

Scenario

The above question became my issue. I needed to know why a portion of the system would compare a value in the database to the same newly-calculated value and judge a significant difference.

The scenario, using Age as the example:

  • CalculateAge() – A value is calculated with up to 15 decimal places
  • AgeInDB – The value is stored in a database table with precision 2
    • [Age] [decimal](10, 2)
  • AgeChangeDetector – Determines if the Age has changed by comparing CalculateAge() to AgeInDB
  • If Age had changed flags the value for review
  • If Age hadn’t change then doesn’t need to be reviewed

After several months and thousands of values being compared correctly,  I found a single value being repeatedly marked for review even though the raw Age was not changing.

  • Calculated Age(): 61.64598913
  • AgeInDB: 61.65

At first glance, this seemed to be a simple failure to compare the values at the same precision. Since the database is at precision 2 and the new calculated value is up to 15 decimal places, the same value would appear different if compared directly. But looking at the comparison the code was:

  • Math.Round(caculatedAge, 2) == AgeInDatabase

With the Math.Round function both values were being compared to the same decimal places. I checked the AgeChangeDetector tests and all test cases passed with a variety of different decimal number combinations.  Curious, I plugged the mysterious values into the AgeChangeDetector class and saw my assertion fail; the class detected a difference with the AgeInDB at 64.68 and the rounded calculation at 64.67.  Seeing the 64.67, I had isolated the problem to the Math.Round function.

Banker’s Rounding

Jumping on Google, I searched for “problems with Math.Round” and filtered down to a forum about the internal algorithm.  Rounding is, at its core, a lossy method where a number right in the middle (.5) must be given a bias and go up or down to 1 or 0.  From grade school, everyone is familiar with common rounding which always rounds .5 up to 1.  When saving the decimal value to precision 2, the database used this method, hence the 61.65.  But Math.Round uses the algorithm known as Banker’s Rounding.  Banker’s Rounding strives to equal things out by rounding up as often as it rounds down.  In a transaction, one party would gain the half a penny and one party would lose it.  To achieve an unbiased view of the middle number, bankers round to the closest even number.  Since having an even number before the .5 is as statistically likely as having an odd, the bias evens out over multiple transactions.  My problem boils down to the fact that ASP 1.1 Math.Round will always use Banker’s Rounding and my database is using common method.

Solution

Knowing the problem may be half the battle, I now had some potential solutions that didn’t seem easy.  One option was that I could round every number in code first before saving to the database. This would ensure that all values going (and coming) from the database would be uniform with my calculations. But that would be a big impact type of change and add an extra level of processing on every decimal value persist to the database (and this might need to expand to more than just the AgeInDB column).  Also, I had to keep in mind that the database had already saved all its numbers and there would be no way to know if the number had been rounded up because it landed on .5 or because it had landed above that.  Another option would be  that the comparison was all that really needed to change, so I researched a means to accomplish common rounding in the AgeChangeDetector.

If I was  in ASP 2.0, Math.Round would take an optional parameter that can set the rounding algorithm, but I am tied to ASP 1.1 in the current release.  After receiving input from forums, I created a new Method to round numbers using the built-in rounding in the ToString method.  My function looked like this:

public decimal CustomMathRound(decimal number, int places)

{

string decimalPad = “#.” + string.Empty.PadRight(places, ‘#’);

string nums = number.ToString(decimalPad);

return Convert.ToDecimal(nums);

}

I replaced the call to Math.Round with my custom function and the new test passed without disturbing any other functionality.  Feeling confident that this was a workable fix, I replaced all other comparisons between a database value and a calculated value with my custom function to avoid another change conflict in the future.

Follow-up

Rounding is a common task for a developer, but should be considered thoroughly to ensure that different methods are not in play on each side of the comparison. The thousands of correct values before this issue proves comparing numbers to a given significance can catch you off guard. This problem is such an edge case that even in-depth test cases may not expose it. This is a situation that the developer must be aware of beforehand-to specifically test a number impacted by banker’s rounding.


Tucker Croft is a Senior .NET developer at Thycotic Software Ltd. Thycotic is recognized for providing Agile TDD Training and Agile .NET Consulting Services, and its flagship password management software Secret Server.

A Developer’s Uphill Journey From Custom Development to Software Vendor – Part 2

March 5, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

We concluded our last blog post by posing a question about meeting customer requirements in an off-the-shelf software product:

So, how can we bring customers into the software development loop and meet their real world needs?

There are things you can do as an ISV (Independent Software Vendor) to bridge the gap between the development team generating requirements and somehow involving the customer.

You can come up with personas for typical users of your new software and categorize their likes, dislikes, favorite colors and even foodstuffs, but it is all fantasy until you have your first customers. Another option advocated by many vendors is an early access beta program; this helps to build a community around your product in the early stages and provides valuable feedback from people using your product. This option is still not ideal since the characteristics of a beta tester may not match the profile of your typical customer in six months time. At this point, the cynics are probably saying that this whole situation isn’t that different from custom development projects, since their user requirements can be poorly defined or championed too.

Our approach was to focus on the pain that our product solves. Secret Server is a web-based application to store passwords in an encrypted database and then securely share them with other team members (or your wife for that matter!) By delivering the core pain-relieving features, we would have a product that was genuinely useful and could then be refined and tuned based on customer feedback. This strategy put our product in our customers’ hands quickly, solved a few of their main problems, and began generating a stream of feedback to then drive requirements for the next phase. In fact, our tracking system actually prioritizes issues and features requested by our customers.

In our custom development, we always practiced what we call “just good enough.” This means giving the client just what they asked for in the shortest possible time while avoiding any over-engineering (read: technical guessing). This mentality was useful for our initial product development since we could easily have blue-skied the product into non-delivery. Focus on the pain your product solves and deliver it quickly to get early customer feedback.

Aesthetics Count!

First impressions count when the user has a choice about using your software. This impacts the aesthetics and the quality of the user experience. Gone are the developer-designed user interfaces, as they simply can’t compare to the work that a true graphics designer can produce in a few hours. The implications of this decision were huge for our development team. The developers knew that a qualified professional would beautify the interface later on, so they could ignore aesthetics and focus on the functionality and automated unit testing (test-driven development) of the software. I have seen developers spend hours tweaking a user interface on many custom development projects because no budget was available for a dedicated graphic designer. This costly exercise seldom produces remarkable results. The decision to use a professional early on benefited the overall output tremendously.

The user experience isn’t just pretty graphics, though, and the vendor should spend serious time refining the number of clicks to perform tasks, the information presented on the screen and the metaphors used in understanding the system. This difficult and time-consuming task can be justified, since the results will be spread over the many users who will try and, hopefully, use your software. Small gains in usability can yield large rewards when marketed to the masses; the economics of this attention to detail do not pan out when there are only a small number of users for your software.

Next week’s blog will explain how stability and virtualization play a vital role in quality assurance.


Jonathan Cogley is the founder and CEO of Thycotic Software. Test Driven Development (TDD) is the cornerstone of the Thycotic approach to software development and the company is committed to innovate TDD on the Microsoft .NET platform with new techniques and tools. Jonathan is an active member in the developer community and speaks regularly at various .NET User Groups, conferences and code camps across the US. Jonathan is recognized by Microsoft as an MVP for C# and has also been invited to join the select group of the ASPInsiders who have interactions with the product teams at Microsoft.

A Developer’s Uphill Journey From Custom Development to Software Vendor

February 26, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

From Custom Development to Software Vendor: A Developer’s Perspective

Every software engineer dreams of the day when he can stop working on those awful Test Process Specification reports (the TPS reports made famous by Office Space) and build his ultimate product, sell millions of copies and live in the Bahamas-or at least a moderately priced condo in a major metropolitan city!

In the last quarter of 2005, Thycotic Software started on this journey.  The bulk of the company’s business was in a successful custom development consulting practice but the sights were set on building a base of product-driven revenue.  The logic leading to this decision was something like this: “We build great custom software for our clients; therefore we should be able to build a great product and sell it.”

The product veterans can stop laughing now. As we learned, there are many differences between these different worlds of software development.  Secret Server, our first off-the-shelf product, would teach us new things about building software: choosing features; support calls with the general public; and how to set new records for daily caffeine consumption.

What are the typical characteristics of custom development?

  • The software caters to a particular business need.
  • It’s time-sensitive due to a market opportunity, budget or fiscal cycle.
  • You have a limited set of users.
  • Users are frequently mandated to use the software.
  • Aesthetics are typically the lowest priority.
  • Stability is often negotiable as long as there is a workaround.
  • The deployment environment is well known and can often be controlled if necessary.

This is the typical world of the corporate developer-ugly applications with aggressive time lines, and very forgiving users.  How well do these traits relate to the world of the software vendor marketing to the public at large?  In many ways, they don’t.  Our team quickly started to notice the differences as the project got underway.

Figuring out the Customer Requirements

First, when requirements were unclear, we had no definitive customer who could give us input.  A large corporation might enlist focus groups of potential customers to understand wants and needs, but for a small team, this option is costly in both time and resources.  This forced us to generate the customer requirements internally, which basically meant guessing.

You have control of the requirements!” noted Bryant Smith, a Secret Server developer, when discussing the increased burden on the team to define the feature set. Some developers may feel empowered by this control but it is a dangerous game since the chosen features, their value, and their usability will determine your sales and ultimately the success or failure of the product.

How can we bring customers back into the loop to make these decisions easier and relevant to their real world needs?

Next week’s blog will answer this question, and reveal how aesthetics affects the quality of user experience.


Jonathan Cogley is the founder and CEO of Thycotic Software. Test Driven Development (TDD) is the cornerstone of the Thycotic approach to software development and the company is committed to innovate TDD on the Microsoft .NET platform with new techniques and tools. Jonathan is an active member in the developer community and speaks regularly at various .NET User Groups, conferences and code camps across the US. Jonathan is recognized by Microsoft as an MVP for C# and has also been invited to join the select group of the ASPInsiders who have interactions with the product teams at Microsoft.