Archive

Archive for the ‘General Software Development’ Category

A View From Above

Jonathan Cogley: Registration forms: Breaking down the barriers between your Web visitor and your product

June 5th 2009 | Bryant Smith

A View From Above

“The significant problems we face can never be solved at the level of thinking that created them.”
-Albert Einstein

Last week, I celebrated my fourth anniversary with Thycotic. I wasn’t aware of it until I received an encouraging IM from Jonathan Cogley (my boss) congratulating me on four years with the company. I just buried myself back into my work…

There is nothing wrong with getting deep involved in the details of work, especially if you are having fun doing it, which I generally am. Sometimes it’s a blast. Other times it’s a chore. It’s all a matter of perspective—a precious commodity that is slippery (read David Allen’s ‘Making It All Work’) but essential. Perspective is what turns my work into a blast or a chore. It can either motivate or demotivate you.

Is everything perfect at Thycotic?

No, we’ve got problems; but they’re good problems. Besides, perfect is boring and not very challenging. That’s another perspective that is slippery for me: looking at problems as something fun to solve. The question is, do you have the tools that give you some control and perspective? A coworker’s presentation on Kent Beck’s XP book compared our practices with the book. The presentation was frustrating yet exciting at the same time. Frustrating because I feel a need to apply our Agile practices more purely. Frustrating because I want to become a craftsman at what I do, but sometimes reality gets in the way (our customers, our practices, my own limitations and mistakes, etc.) On the other hand, I feel excited because we have a great team and I have many of the Agile practices down pat.

So what’s the takeaway here?

It’s how do I manage a perspective that’ so difficult to maintain? Today this perspective of excitement, gratitude, and passion for my job is bolstered and supported by the fact that I needed to write this blog in the first place. If I wasn’t writing this right now, I would have probably missed the opportunity to look at my circumstances from a higher ground. Don’t get me wrong, I am frequently grateful for my job and my circumstances. Maybe it’s just the way I am, maybe it’s my faith in God and the Bible. Whatever it is, it is easily attainable by all if we have the right tools.

What are those tools? A short list might include:

  • ‘Making it All Work’, by David Allen, author of ‘Getting Things Done’
  • Ask yourself challenging questions.
  • Read inspiring stories or watch uplifting movies.
  • Get involved in the community.
  • Be a mentor. Teach.
  • Review old dreams.

The problem can rarely be solved at the level that the problem is found. You may have to move your focus to a higher level for clarity, or down to the level of action steps. Most of us have a tendency to get into a groove where we do one more than the other. For me, as of late, I have been having health issues. My tendency was to keep my head down and weather the storm. It’s a nice view from up here, I think I’ll stay a while…

Bryant Smith is a Senior .NET developer at Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship enterprise password management product.

Creating Truth Tables. A Simple Truth Table for Programming Purposes

May 21, 2009 2 comments

David Cooksey Truth Tables

May 21st 2009 | David Cooksey

Truth tables are a handy method for quickly listing all the possible combinations for a set of inputs in logic.

Coincidentally, they are also very useful for doing the same thing in programming.

Let’s say you have a function that has 4 Boolean input parameters and you want to be sure it is mock tested with all the possible combinations. You could just eye-ball it, but chances are a combination or two have been forgotten. Enter truth tables!

As we have 4 variables with 2 values each, we know that we have 2^4 = 16 possible combinations. Create a table with 4 columns—one for each variable, and 16 rows—one for each combination. Then fill the table out as shown below. For verisimilitude we are using variable names that could have meaning in code.

US Citizen

Born In US

Gender

Born Before 1950

True

True

M

Yes

True

True

M

No

True

True

F

Yes

True

True

F

No

True

False

M

Yes

True

False

M

No

True

False

F

Yes

True

False

F

No

False

True

M

Yes

False

True

M

No

False

True

F

Yes

False

True

F

No

False

False

M

Yes

False

False

M

No

False

False

F

Yes

False

False

F

No

There is a simple pattern here, though it’s more apparent when using 1s and 0s or Ts and Fs instead of the more realistic data used here. The first variables column is half True and half False. The second is divided into quarters, alternating between True and False. The third column is divided into eighths, and the fourth is divided into sixteenths.

Let’s consider an example with 3 variables. The first variable is a Boolean; the second an enumeration consisting of three items; and the third a date. In this case the date has 4 ranges of data that change how it is treated in code, namely the four centuries between 1700 and 2000—18th, 19th, 20th, 21st.

2 * 3 * 4 = 24 combinations.

Boolean

Enumeration

Date (Century)

T

Item1

18

T

Item1

19

T

Item1

20

T

Item1

21

T

Item2

18

T

Item2

19

T

Item2

20

T

Item2

21

T

Item3

18

T

Item3

19

T

Item3

20

T

Item3

21

F

Item1

18

F

Item1

19

F

Item1

20

F

Item1

21

F

Item2

18

F

Item2

19

F

Item2

20

F

Item2

21

F

Item3

18

F

Item3

19

F

Item3

20

F

Item3

21

This pattern is marginally more complex. When filling out a truth table, start at the right side and rotate through the values going down. For all the columns following, rotate through the valid column values per the number of combinations in the preceding columns.

For example, let’s say you have the centuries laid out and you need to fill in the enumeration column. There are 4 valid values for the century column, so write down Item1 four times, then Item2 four times, etc., until the column is filled. For the Boolean column, there are 4 [century] * 3 [enumeration] = 12 valid combinations, so you write down T twelve times, then F twelve times.

The great thing about this method is that is simple and logical and can be used with any number of variables.

If you don’t use truth tables, how do you check that you have everything covered? Next time you’re programming a new algorithm, sketch out your truth table on paper, then use it to drive your unit tests and make sure you have everything covered.

David Cooksey is a Senior .NET developer at Thycotic Software Ltd, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship enterprise password management product.

Registration forms: Breaking down the barriers between your Web visitor and your product

May 6, 2009 5 comments

Jonathan Cogley: Registration forms: Breaking down the barriers between your Web visitor and your product

May 6th 2009 | Jonathan Cogley

Registration forms: Breaking down the barriers between your Web visitor and your product

You’ve just found a really neat utility you’d like to download. So…you click ‘download’, and bam! You find yourself gazing at a mile-long ‘registration’ form coupled with email verification:

On one hand, you really want to try out this neat new utility.

On the other hand, you really don’t want to have to part with a load of personal information; fill in a dozen ‘required’ fields; dream up a user name, a display name, and a unique password; and type your email address twice.

Jonathan Cogley: Registration forms: Breaking down the barriers between your Web visitor and your product

What is the value of this additional information anyway? Is this company going to display your real name to anyone? Why do they need your address if you’re not mailing anything to you? Why do they need your phone number if they have no reason to call you? What are they going to use your ‘prefix’ for? This information is of no real use to them and it represents a series of barriers between you and the product you desire.

What information should be required in order to complete a simple download?

Every ‘required’ field on your form is one more barrier between your Web visitor and your product. Request only the information you need in order to perform the action for the user. While it’s tempting to use the opportunity to capture other useful information about your target market, online audiences have become more protective of their personal data and may decide that their privacy is worth more than your download.

Also reconsider the email validation – does it really matter to force a valid email address by sending an email to it and delaying the process? A customer who is genuinely interested is likely to give their real email address anyway.

Thycotic’s Web site registration form requires only an email address, full name, and password. We don’t verify your email address since that isn’t foolproof (most people have a free webmail junk account for such things). In the past we rejected email from free Web mail providers (Gmail, Yahoo, Hotmail, etc) but now we ask for a phone number instead. If a customer is genuinely interested in our product, then they actually appreciate a call to discuss their problem and receive an appropriate solution.

So take the time to consider your audience, then reduce barriers by requesting only information you genuinely need to successfully process the transaction.

Jonathan Cogley is the CEO of Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship enterprise password management product.Are you on Twitter? Follow Jonathan

A stranger in a strange land: A graphic designer in a dot NET Agile sprint planning world

April 30, 2009 Leave a comment

Josh Frankel: Stranger in a Strange Land a Graphic Designer in a .NET Agile planning meeting

April 30th 2009 | Josh Frankel

Stranger in a strange land: A graphic designer in a .NET Agile Sprint planning world

Agile Planning is an effective way of gauging how much work can get done in a given period of time. By measuring things in relative units of effort one should be able to approximate units of work required for a task. Our team uses a point system to avoid being influenced by a system based on hours. Hours may seem easier to use but they are not necesarily representative of the proportional relationship between work that has been completed and work that needs to be accomplished.

Shortly after joining Thycotic as a Web designer I was given a brief overview of Test Driven Development and Agile Planning practices and immediately recruited to participate in the bi-weekly sprint meetings. But with my skill set rooted firmly in the design arena and my vast development skills limited to CSS and HTML-I had absolutely no idea what was being discussed.

As the team went through the challenges and methods of each task I realized that my grasp of programming was comparable to my grasp of Mandarin Chinese. When it came to discussing point efforts needed for tasks, my guesses were wildly different from the rest of the team’s.

It’s been a few months now and sprint planning meetings are a lot easier. My assessment of the point effort needed for a task is usually pretty close to the developer’s approximations. Although I understand the planning terminology, I still don’t know squat about programming- for the purpose of Agile sprint planning, I really don’t need to. I only need a grasp of how or what is going to be done based on it’s relative difficulty to other tasks. What I’m trying to figure out during each sprint meeting though, is how much harder the current task is when compared to one that’s worth one point.

With buzzwords like ‘synergy’ and ‘cross-functional’ being thrown around so much, isn’t it time consideration was given to how Agile techniques might be expanded and enriched by those of us outside the traditional developer role?

Josh Frankel is the junior graphic designer and marketing team member at Thycotic Software Ltd, an agile software consulting and product development company based in Washington DC.  Secret Server is our flagship enterprise password management product.
On Twitter? Follow Josh

Name a variable like you name your first-born

April 13, 2009 6 comments

Jonathan Cogley: Code Naming

April 13th 2009 | Jonathan Cogley

Name a variable like you name your first-born

“You should name a variable using the same care with which you name a first-born child.”

– James O. Coplien, Denmark   (foreword to Clean Code)

This is hysterical!  I had such a good laugh on reading this line.  For those developers who don’t have children – the child naming process can take months … it usually starts in the second trimester (3-6 months of pregnancy) and can still remain undecided when the child is born… having been through this twice, it is not an easy process.

Note that James doesn’t say naming of a child but rather your first-born implying even more care and emphasis!  While this is obviously in jest, it does highlight how important naming and concepts can be within your code.  With our team, naming a variable can sometimes take 5 minutes while the programming pair argues backwards and forwards. If it takes too long we give it some silly name (bunnyFooFoo) and move on with the intention of revisiting the discussion during code review before committing to the source repository. Besides, who would let bunnyFooFoo go into the source repository with their initials on the commit?

Next time you whip out a string “s” or int “i” or DateTime “d”, give a thought to a logical name that will help others to understand the code in future.

Further thinking on naming:

Jonathan Cogley is the CEO of Thycotic Software, an agile software consulting and product development company based in Washington DC.  Secret Server is our flagship enterprise password management product.

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

March 12, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

We concluded the previous blog in this series by revealing how using a professional graphic designer to optimize the aesthetics of your software user interface benefits the overall output. This week, we conclude the series with two more characteristics that are essential to the overall success of your software:

Stability: Design for Multiple Environments

The smart ISV knows that user experience relies on stability. A failure during the initial few minutes can cause negative first impressions and the user may give up on the product. The user may have many different software configurations and settings, making stability and testing a more challenging exercise. The Thycotic team has already encountered an amazing range of issues, especially involving internationalization. For example, language settings on the database server and web server needed to be exactly the same.

“You have to support everyone!” noted David Astle, a Secret Server developer, upon realizing the endless combinations of software and settings that our audience use. Limiting the supported configuration by setting certain system requirements may seem like a smart way to reduce quality assurance time, but it doesn’t really work. Customers will often try your software in other environments and solicit help when problems arise. Ignoring such requests, which may indicate your customers’ preferred environments and configurations, can be dangerous. Our customers quickly requested support for installing the product in a hosted web environment – something we had considered but didn’t officially support. (A thread quickly emerged on our support forums to talk through the issues.) We have also had requests to support other database platforms for our product. This was something we anticipated, and we specifically designed our product to use generic SQL wherever possible to facilitate other database platforms.

There is still a huge cost associated with expanding your supported platform: install issues; environment quirks; multiplying your quality assurance test environments; and ultimately fielding more variation in support calls. This is definitely a balancing act and something you should probably defer until you have enough customer requests to justify the cost.

Quality Assurance

Tools also play a big role in controlling the adjustment to the software vendor world. Virtualization is a must for your quality assurance environment. This allows you to easily test your product on multiple support configurations and reset as needed. It is worth the investment in time to create multiple virtual environments to represent the main configurations that you anticipate your customer will use. Use a tool to create an automated test script or even a repeatable manual test script, and then simply run through the tests on all the configurations. This approach has been especially useful for ensuring quality during the product install process, which is heavily dependent on the environment and is a miserable place to fail on the customer. For our virtualization, we use VMWare software and have found the snapshot feature to be invaluable for rerunning our tests with different builds of our software.

Unit testing tools are even more essential in ensuring high quality in the builds making it to quality assurance. The ability to run an entire regression set of unit tests-a large suite of unit tests which allow you to determine if anything will break when you make a change-was beneficial when making big changes, such as adding support for Microsoft Access as a database platform in addition to Microsoft SQL Server. The same was true when we began supporting Microsoft .NET 2.0. The ability to easily test all of the system features in an automated manner while the product is still in development is a big time and money-saver.

Other standard software development tools, such as source control, issue tracking, automated builds and development productivity enhancement tools, were as useful in the ISV world as they had been in our custom development practice. A source control platform with solid support for branching is especially useful if you need to apply fixes to multiple versions of your software in the field. Branching lets you easily separate out your release versions from your mainline of development for your next product release.

In summary, these are the main differences we experienced between the development of custom software and packaged software:

Custom

Packaged

Control of Requirements

Not usually

Often more than you might like

Attention to Detail

Functionality first and last!

Endless refinement

Number of Users

Small

Huge

Operating Environments

Usually controlled

More than you can guess

Stability

Negotiable

Essential

Building a product can be a rewarding experience, even when the financial rewards won’t let you live happily ever after in Bermuda, but it poses a different set of challenges than those experienced when developing custom software. Think carefully about your strengths and how you might adapt your best practices before trying your hand at packaged software development


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.