An Architect asks (part two)…Walking the design tightrope

In a previous post, I tackled a question from an architect friend of mine about whether it was possible to have anything worth releasing in just three iterations. In this post, I want to answer another question from the same conversation:

When we are building software with a traditional phased approach, we have  a lot of time to think about design. How do we avoid bad design if we are moving so quickly?

When you’ve been part of the Big Design Up Front school, you try to anticipate all requirements that may come your way and design for them up front, completing the design of the software before development begins. The problem with this approach is that you end up with a lot of code that you do not need, for a lot of anticipated requirements that never came to fruition, or were removed from scope as the project progressed.

When I was having this conversation with my architect friend, he assumed that I was going to propose an alternative of no design up front, but of course this approach is worse than BDUF.  Let me say that more succinctly:

For anything other than the most trivial of projects, too little design is worse than too much design.

If you don’t think about design at all up front, the best outcome you can expect from your project is a mish mash of features that probably do not hang together as a product. Your most likely expectation is to throw away lots of code and have a dead ends and false starts.

So how much design is enough design? The ideal approach is first to think about the end game for the project. What is the vision for the product / project? What would that look look like (at a very high level)? If your customer expects some upfront specifications, spend the time to create a short document using the Big Picture documentation pattern, as described in Agile Documentation by Andreas Rueping:

Problem: How can people be introduced to a project without being confronted with a deluge of technical details?

Solution: A good feel for a project is best conveyed through a description of the “big picture” of the architecture that underlies the system under construction.

Andreas goes on to describe the documentation pattern as describing the overall architecture, showing how the system is composed of subsystems and modules and explains the basics of the system’s behaviour. It also explains the design principles and the motivations that led to the design, as well as naming the technologies involved in the design. Most importantly, it abstracts over any details, technical or otherwise, that are irrelevant to an overview.

For detailed design, think about what is in the current iteration, and what you expect in the next iteration (some people call this the back burner iteration), and design for that. This is just enough design. Document your design using a wiki, and keep really detailed function and module level documentation in the tests where it belongs.

Maria Spelterini

Maria Spelterini

When designing for an agile project, you will always be walking the tightrope between too much and too little design. It’s a scary place to be at first.

When you fall off on the too little design side you will either have a patchwork quilt of requirements that are not a product, or you will throw away code and have dead ends.

If you fall off on the too much design side, you will end up with lots of detailed design, code and dollars spent on requirements that are no longer needed.

I never said this was easy – this is why we earn the big bucks, right? But, just like a tightrope walker, actually getting up there and falling off a few times will make you better at it in the long run. Over time, you will become the Maria Spelterini of Agile design.

Luhn Algorithm for Salesforce formula field

This is a quick and dirty “how to” post about Salesforce.com formula fields.

I was asked by a customer to implement a Luhn Algorithm to provide a check sum against a six digit autonumber in salesforce. For those of you who’ve never heard of a Luhn Algorithm, here’s the explanation from Wikipedia:

Informal explanation

The formula verifies a number against its included check digit, which is usually appended to a partial account number to generate the full account number. This account number must pass the following test:

1. Counting from the check digit, which is the rightmost, and moving left, double the value of every second digit.
2. Sum the digits of the products together with the undoubled digits from the original number.
3. If the total ends in 0 (put another way, if the total modulo 10 is congruent to 0), then the number is valid according to the Luhn formula; else it is not valid.

As an illustration, if the account number is 49927398716, it will be validated as follows:

1. Double every second digit, from the rightmost: (1×2) = 2, (8×2) = 16, (3×2) = 6, (2×2) = 4, (9×2) = 18
2. Sum all the individual digits (digits in parentheses are the products from Step 1): 6 + (2) + 7 + (1+6) + 9 + (6) + 7 + (4) + 9 + (1+8) + 4 = 70
3. Take the sum modulo 10: 70 mod 10 = 0; the account number is valid.

The Salesforce object is integrated with a back office system, and the users might need to manually enter this value into the back office system. This was a bit of a pain to do, so I thought I’d share it here for anyone else who needs to do something similar.

I wanted to use a formula field to do this, rather than an Apex trigger. I try to avoid triggers in Salesforce if I don’t need them, as they’re restricted by governor limits. This means the solution below is a little ugly, but it works.

I first figured things out in Excel. Excel formulas are similar to Salesforce formulas, so I realised I could make this work with a combination of the MOD function and the FLOOR function. I worked on several test six digit numbers to ensure that my formula worked for each digit, then finally concatenated the whole thing together into a single Excel formula field.

When I moved my formula over to Salesforce, I realised that the FLOOR function in Excel and Salesforce behaved differently (Excel allows an input parameter to say how many significant digits you are flooring to, Salesforce assumes you are rounding down to the nearest digit), so I needed to rework my Excel formula  a little.

One this was done, I took the following steps to get the field up and running in Salesforce.

  • Create a custom autonumber field. In this case, it needed to start at > 120,000 to support existing rows in the back office system.
  • Create a second formula field to calculate the checksum of the six digit number. The formula should look like this (I’ve tried to break up the lines to make it more readable; the line breaks are not necessary when entering the formula in Salesforce):
MOD(10 - MOD(
               IF(
                   MOD(VALUE(CustomID__c) ,10)*2 > 9,
                   MOD(MOD(VALUE(CustomID__c) ,10)*2,10) + 1,
                   MOD(VALUE(CustomID__c) ,10)*2
               ) +
               FLOOR(MOD(MOD(VALUE(CustomID__c), 100)/10,10)) +
               IF(
                   (FLOOR(MOD(VALUE(CustomID__c), 1000)/100)*2)>9,
                   MOD(FLOOR(MOD(VALUE(CustomID__c), 1000)/100)*2,10)+1,
                   (FLOOR(MOD(VALUE(CustomID__c), 1000)/100)*2)
               ) +
               FLOOR(MOD(VALUE(CustomID__c), 10000)/1000) +
               IF(
                   (FLOOR(MOD(VALUE(CustomID__c), 10000)/1000)*2)>9,
                   MOD(FLOOR(MOD(VALUE(CustomID__c), 10000)/1000)*2,10)+1,
                   (FLOOR(MOD(VALUE(CustomID__c), 10000)/1000)*2)
               ) +
               FLOOR(MOD(VALUE(CustomID__c), 1000000)/100000)
          ,10)
   ,10)
  • Create a third formula field that concatenates the two fields together. This field can be passed to the integration and be used as an external Id when updating rows back from the back office system.

That’s it! Ugly, but it works. Does anyone out there have a better and less ugly way of getting this working in a formula field?

An Architect asks (part one)…

I just had a conversation with a software architect friend, who asked some pertinent questions about agile. After a lively discussion, I thought that the best way to respond in detail to his questions was to post here. I’ve broken the post up as it got a little long!

First, a little background on my friend. He is a very talented developer who has been involved with several companies helping to define business strategy, and design and build business applications. He has embraced some agile practices at the developer level (test driven development, refactoring etc.) but has not been involved in full blown agile projects until recently. After seeing a customer’s kickoff presentation about how they intend to manage an upcoming project he had some questions for me. The first question and answer is below:

We’re supposed to have something to release in three iterations. How can we deliver anything useful or worth releasing in three iterations?

There are two parts to this answer. One about what you don’t build, and the other about what you do build.

The first principle you need to follow is Simplicity. This skill is so important that is is mentioned as one of the principles behind the Agile Manifesto:

Simplicity–the art of maximizing the amount
of work not done–is essential.

Ironically, simplicity is a difficult skill the first time you try it. If you’ve been of the school of “Big Design Up Front (BDUF)”, it’s a hard practice to let go of. On an agile project, you need to be disciplined in not building what you haven’t been asked for and don’t need, even if you suspect you might need it in the future. You need to follow the principle of You Ain’t Gonna Need It (YAGNI) all the time. Now, if this thing called Simplicity is defined so simply, why is it so hard to do?

Well, it’s that nagging feeling at the back of your mind that you ARE going to need it. Designing everything up front and gold plating requirements is comforting for two reasons.

  1. Developers love solving problems, and there’s almost nothing more satisfying to a developer than finding a general solution to a problem. The good news is that you don’t have to abandon this approach entirely; as you’ll discover, if you practice test driven development and refactoring properly, it will be easy to find a general solution to a problem when you need to find a general solution and not before.
  2. Developers worry that without a big design up front, they will have to go back to the customer with change request forms and throw away code that’s already been built, thus adding lots of time and expense to the project. These seem like realistic concerns at first glance, so let me address them:

There’s really no such thing as a change request on an agile project. Change requests exist on projects where requirements are fixed. Agile projects embrace change, and what is built and not built is entirely up to the customer. The constant feedback and communication between the customer and developer and the fact they are part of the same team ensures that feedback is incorporated early. Formal change requests are not necessary on an agile project because there is a requirements backlog where the customer can add, remove and prioritize requirements.

While it can happen that code gets thrown away, particularly if you are not practicing Little Design Up Front (LDUF), by following the SOLID principles it’s more likely that your code can evolve and change, and the tests you have in place will ensure that existing functionality is not broken by new functionality.

The second part of this answer is about what you do build. In Agile projects, requirements are typically defined as User Stories. A User Story can be thought of as a vertical slice of functionality that has value to the customer. The skill of defining and slicing up these requirements is so important that there have been several books written about it. I recommend User Stories Applied by Mike Cohn for a great introduction to this topic. Building vertical slices well requires that you practice the principle of Simplicity to ensure that you only build enough infrastructure to support your current requirements.

I’ll talk more about practicing LDUF and agile architecture in upcoming posts, so watch this space.

About Me

Me and the boys

Me and the boys

Firstly, welcome to PracticalAgility.com.

I’m Paddy Healey, a journeyman software developer with over 20 years experience in the IT industry. I’ve worked in many roles in IT, from a glorified tape loader on ICL mainframes, through technical trainer, consultant and developer. Over the years I’ve worked with many businesses in many different industries, on many software platforms and I have never lost my passion for solving business problems.

Today I work for Ext.IT as a consultant and mentor, with a particular responsibility for improving processes and practices, both internally and for our customers. You can hire me by sending an email to paddy@practicalagility.com or info.us@ext-it.com

In terms of what I intend for this website, I’ve always been interested in what works and what doesn’t in different software development methodologies and practices.

I believe that a the following statements are true about the state of software development today:

  • “One-size-fits-all” approaches often do not work, as these approaches are often adopted through dogma, rather than pragmatism and regard for the specific situation.
  • Software development is still a new industry and what we consider best practice today will be quickly superseded, so whatever approaches we take should be flexible.

Many people assume that adopting agile practices means that you either have to be incredibly technical, or have to adopt massive amounts of new processes to be successful.

While it is true that if you don’t embrace change and enter into agile in the right spirit, you will not succeed, you will find that once you try them the developer practices actually help you to grow into a more professional programmer. Agile processes are lightweight but effective, with inbuilt feedback loops to make them self improving.

With this website, I’ll be blogging about and linking to articles that show you how to be better at software. If there are practices that haven’t worked for me, I’ll tell you about those too. I also intend to build a recommended reading list for you, so that if you are getting started with agile, or are curious as to what it’s  all about, you’ll be able to find out here.

That is the philosophy behind the website.

One other thing: this website is not affiliated in any way with Dave Rooney’s Practical Agility blog on Blogspot. This domain name was purchased long before I’d heard of Dave Rooney or his blog, so hopefully the interwebs can live with two of us…

Check it out, as well as other interesting Blogs about agile software development, by clicking the links in the Blogroll, and don’t forget to follow me on twitter.

Enjoy!