November 16th, 2011 | Katie McCroskey
Pictures are worth a thousand words, so I’ll try to keep this brief – TDD teams write better software.
The chart above is based on a formal paper of four empirical case studies on teams using Test Driven Development. Test Driven Development has been used sporadically for decades, and has been tested in academic and controlled settings numerous times. But this paper is different because it’s not about controlled experiments; it involves real people, real projects and real customers – at IBM and Microsoft, really smart companies. Test Driven Development is when a developer writes a failing unit test to define a desired function. Then, code is written to pass the failing test. Finally, the code is refactored to meet acceptable coding standards. The developers are in control, constantly making small design and implementation decisions – and getting constant feedback.
A few details on the teams: at IBM the developers were working on developing device drivers, working on new and legacy code. It was a distributed team, working in Java and no one had any previous experience in TDD. The teams at Microsoft, on the other hand, were co-located, working in C# and C++ on three products you may have heard of: Windows, MSN and Visual Studio. None of these teams were Agile, but collectively decided to try out TDD.
Despite the differences in project size, type and environment – the results were conclusive. Test Driven Development drastically reduced the defect density (bugs, missed requirements, etc.), anywhere from 40 – 90%. In the end, the tests were considered assets so when the code is enhanced/modified it will be easier to find new bugs. Although all the teams did experience a slight increase in development time, 15 – 35%, the increased time is offset by the improved quality and reduced maintenance costs. If you are interested in learning more, check out the formal paper.
May 5, 2011 | Michael Millstein
What is a password worth? A lot…and here’s why you shouldn’t become too attached to just one.
When you think of passwords, what do you think of?
You probably think of your AOL account, gmail, computer log-on, bank account (either online log-on or pin number), online store account…the list goes on. Do you use the same password for every account you have? Chances are you have the same password for nearly every account you have—wait, except with your work account because they make you change your account password every 60 days or so. But, you definitely use a variation of your original password every 60 days, so it’s close enough.
Now, imagine you’re an IT system administrator at Joe’s bank, the largest bank in the nation. Along with the passwords you use on a daily basis for your personal accounts, you also have hundreds of passwords for your Service Accounts, Windows local admin accounts, Root accounts, network devices, etc. What would happen if you used the same practices for work accounts that you do at home? A skilled hacker comes along, figures out your password, and gets the keys to your entire kingdom! And here the stakes are much higher—instead of hacking just one individual’s bank account he could log into your infrastructure and get payroll, social security numbers, credit card numbers, bank account information…everything.
Passwords are among the most valuable information in the world.
The notion that passwords are sacred comes from the book “The Art of Intrusion” by Kevin Mitnick, one of the most famed hackers of all time. The book highlights some of the most memorable hacking attempts in history, some which were successful. One of the stories told could have cost Boeing millions in losses or reputation: two teenagers thought it would be cool to hack for fun. They hacked into Boeing as well as government websites, a credit union, and the DMV among others. They simply used common usernames and passwords. Once they were in they gathered any information they wanted, and browsed wherever they wanted to browse. These young men were just hacking for fun, there was no malice behind their acts but they encountered very sensitive information.
We make our users change their passwords every 60 days or so, but what about all of the privileged accounts mentioned above? Typically, IT pros store their passwords in an encrypted Excel file, use generic/default passwords, and do not change these passwords regularly. Why don’t we enforce the same user-level policies on privileged account passwords? These passwords literally hold the keys to the kingdom yet they are not adequately protected by IT pros. If the passwords are the same across multiple devices and accounts, a hacker can view all the sensitive information on your network without breaking a sweat.
Some companies believe that their strong external firewalls can keep out intruders.
Well think again. Once a hacker gets through that firewall he’ll head straight to your servers, databases and the other accounts containing sensitive information. Without strong internal password policies, or software to help manage passwords and rotate them to keep hackers guessing, your infrastructure is vulnerable. You may be just one hack away from learning a tough lesson. I learned at a recent military event that some of the system administrators for the military and their contractors use Microsoft Access—an unencrypted file—to store privileged account passwords. In addition to not being able to track who has which password, I could have logged on to their system, or hopped onto an unguarded computer, and viewed every sensitive password on the network. This can cause hours, even days in downtime, and millions in expenses. Plus, it can compromise sensitive information that could be devastating to the company concerned, or even the country. “Let’s wake up people. Changing default settings and using strong passwords might stop your business from being victimized” (Mitnick, 88). Don’t be the next victim. Take action and use the same password policies savvy IT administrators place on their end users.
April 27, 2011 | Jacob Stucky
The Agile Principles that impressed me most as a Software Developer
I spent the first several years of my career as a software developer in a non-agile environment. We didn’t purposefully follow any particular software design model, but we ended up getting fairly close to a waterfall approach. We would go through the motions of creating both requirements and design documents, but each phase would never seem to truly finish as we were forced to start later phases early due to time and budget constraints.
Without a clear development model, a developer might end up taking the mostly finished requirements document, a half-finished design document, and the memory of a conversation on how the system was supposed to work and spend a few months in development. The developer could easily spend months lost in the code without the support of another set of eyes to look at the code and assist with problems, or to keep him honest (i.e. not taking shortcuts, writing quality code).
Of course, developers always have deadlines, and in my experience in non-agile environments, it’s no surprise to have to put in long hours in order to meet the deadline and get the software released into a test environment. This was often the first time someone other than the developer would see the project; the extent of the testing being when the developer ‘tried it’ as a part of building the feature.
Hours of phone conferences, bug lists that are dozens of items long, and more months of hot fixes and changes would follow, and might continue well after the production installation. You hope to avoid, but are not surprised by arguments over budget, timeline, and what features were or were not included in the ‘approved’ requirements and design documents.
The result of projects such as these is that a single developer ends up ‘owning’ each project or large feature. If that developer ever leaves the company, there is a mad scramble to do a knowledge transfer to another developer for maintenance or new features. Heaven forbid the elusive ‘version 2’ ever gets approved and the new developer actually needs to have a full understanding of the system or feature.
When I joined Thycotic I was introduced to several agile principles. Here are the ones that made the most impact on me as a developer:
Test driven development
Test Driven Development, or TDD, was probably the largest and most difficult adjustment I had to make. This was not because I was ideologically against the goals or ideas of TDD, but because it requires an adjustment of how the developer thinks. For the eight years I had been writing software I’d always had a full plan in mind of how each piece of functionality would be implemented and would often stub out, or even fully write, methods that I would later need.
With TDD you do not work ahead in that way. You start with a single failing test and only write the code that is necessary for that test to pass. This is followed by another failing test, and the pattern continues, with a step to look for refactoring opportunities whenever you have full green tests. This refactoring is safe because you can simply rerun your test to confirm the code still works. The benefit of this process is threefold. One, you have not wasted time writing code that is not needed. Two, every bit of code is written in order to fix a failing test, giving you full test coverage and confidence that if the code breaks at any point, your tests will be able to inform you. Three, with properly named tests, by the time the feature is complete your tests serve as full code documentation for how the feature works and what results should be expected.
Surprisingly, at least for me, the transition to programming with a pair was not a difficult adjustment at all. Even in my previous jobs there were times when someone was stuck working on a particularly difficult section of logic, and having two people look at the problem together helped solve the problem in much less time. Pair Programming gives you that benefit at all times. Not only does having a second developer working with you help when solving a complex issue, you and your pair also work together to keep the other focused. A pair working together is also more likely to follow best programming standards than an individual working alone due to the presence of peer accountability.
Working with smaller, manageable increments of time and a solidly defined amount of work is simply amazing. There really isn’t much more I can say about it. Instead of looking at a daunting project that will take months to finish, with no tangible goals in sight, everything is broken down into two-week increments.
The progress is tracked daily and it is easy to see with a glance how you are doing. There is rarely an impending sense of ‘This is never going to get done’ because you discuss and agree to what you can finish in the two week period. Everything else is outside the scope of the sprint, and thus outside the scope of concern for the time being. Of course, you revisit that additional work in the next planning meeting, but when you sit down to actually program, it is not hanging over your heads.
The sprint planning process is the most difficult part of a sprint because it means making sure that you can finish what you committed to, while at the same time not under committing. However, as teams gain experience, the process improves and as a result, so does the ability to plan accurately.
Verifies and QA process
For all but the simplest story there is a set of written “verifies.” For example, “Verify that there is an edit button on the page.” These verifies serve as a checklist for the QA process. The story isn’t considered complete until the entire list of verifies for that story are tested with a release build and signed off by the pair that performed the QA. Because of this guided and focused QA testing we have much more confidence in every story we complete, rather than if we had simply ‘tried it’ while developing, or after a fresh install did some ‘clicking around.’
I feel like I really hit the ground running at Thycotic. The agile techniques meshed well with my programming goals, and I immediately saw the benefit in this programming style. Moving entire teams to this style of programming would likely take effort, since it is a change in how programmers, management and clients interact, and it requires serious dedication from both programmers and all levels of management. But through this focus, I have also seen the benefit of more consistent results, better accountability, and a better quality product.
April 21, 2011 | David Cooksey
An Unusual Regex Application
As any student of regular expressions knows, the regular expression engine has no understanding of the meaning of the characters it matches. The engine can match “A” or “B” but it doesn’t understand the relationship between “A” and “B”. It can match 1 or 2 but it cannot tell you that 1 + 2 = 3.
However, regular expressions are very good at quickly matching text and this can be used to obtain some related information, such as how many instances of a capture group were found. A Regex can be created based on this which will tell you how many of each letter occurs in a string. Consider the following example.
Let’s say you have a string containing some letters, such as “wsaerdctfvygbhnjmhgdeswxdcfgvbhjnqwertyuioplkjhgfdsazxcvbnmwsae”
Against this, run the following code block with the string above as the content.
Each letter has its own named capture group allowing zero or more repetitions. The number of captures of each letter-specific group is equal to the number of letters in the string. This can be extended to count specific words, words starting or ending with specific letters, or any other pattern-based categories.
April 14, 2011 | David Cooksey
The Agile Virtue of Transparency
Transparency runs contrary to human nature. We all want to look good, however, the greatest programmer in the world will still cause bugs. Few designs are so prescient that they never require updating. When mistakes or design flaws are discovered, it’s natural to downplay, hide, excuse, or otherwise mitigate the negative effect these mistakes have upon our reputation.
Unfortunately, this human tendency can cause many problems. Bugs can remain unfixed and architectural flaws unresolved. In order for our code and processes to be useful, our mistakes need to be brought to light and corrected. This is precisely why transparency is so valuable, and also so difficult. A team or organization must be structured in such a way that mistakes are corrected while simultaneously encouraging people to own up to their mistakes.
Naturally, common sense applies. There is no need for every developer to constantly inform the team every time they make a typo or cause a test to fail locally. Transparency does not mean that every individual detail should be published to everyone up and down the chain. No one can absorb all of that data, and the sheer mass of data would actually discourage transparency because it would be extremely hard to find the data points that are relevant. A problem or potential problem should be brought to the attention of the people who can resolve the problem, and those who should be notified of it as soon as possible.
A friend told me a story recently that does an excellent job of illustrating the value of transparency between levels. His company had decided that it was time to create a new website. Their website was functional, but could use a facelift. Also, there was a lot of business logic in the database which could possibly be pulled out into a services layer. The team was hired and they got to work. A year later, the new website had less functionality than the original website. Content management required business analysts to open and compile multiple Visual Studio solutions. A change to a stored procedure parameter required compiling more than 12 independent solutions—and no business logic had been pulled out of the database.
This occurred because the people asking for the new site had no view whatsoever into what it was going to be. There was no involved product owner. There were no intermediate demos that evaluated progress or architecture. There were no intermediate releases to gather feedback. As a result, a year’s worth of time and considerable funds were wasted.
This is an extreme example, but it shows very clearly why transparency is such a valuable virtue for an organization to have. Opaqueness makes it far too easy to hide flaws, which can dramatically increase cost to the company.
So, how do we encourage transparency within an organization? First, lead by example. If a manager never admits to a mistake, chances are the people working for that manager will never admit to mistakes either. Secondly, avoid mockery. Scorn, ridicule, and condescension train people to protect themselves emotionally by hiding their mistakes. Every developer will cause bugs and make poor design decisions from time to time. Third, extend a helping hand. The field of development is so large that no one is an expert in everything. Sometimes a bug or unusual design decision is caused by incomplete understanding of part of the specific system or the underlying programming concept. A team effort to fix the bug, if it is significant, can help create a sense of community and avoid the blame game.
There is no doubt that transparency is difficult to achieve and maintain. However, if you want to develop products that meet the needs of your users in a work environment where people can focus on their work instead of appearances, it is essential.
March 31, 2011 | David Cooksey
Easy SQL totals and other Aggregates with Rollup and Cube
SQL 2008’s introduction of the rollup and cube keywords allows for easy subtotals and other aggregates by your selected groups. To see how simple it is to set up your automatic subtotals, let’s look at an example. For those who want to skip right to SQL, see the script at the bottom.
Imagine you have a table that stores sales information. This table holds the customer name and the products that were purchased, along with the salesman who got credit for the sale and the purchase date. The precise schema for the table follows.
By joining this table to its related lookup tables we see that it has the following data:
If we wanted to write a query to give us totals by customer name, it would look something like the following.
By adding WITH ROLLUP to the query we get an automatic grand total.
The rollup keyword generates aggregate summaries based on the order of the columns in the group by clause. If grouping by customer name, salesman name, and product name—in that order—summary rows will be generated for all products by salesman and customer, and all salesmen and products by customer. However, there will be no summary row for all customers by either salesman name or product name.
Now let’s try something a little more complex. Let’s get totals and averages by customer and salesman.
The cube keywords used here generate summary rows for all combinations of columns in the group by clause. In this result set we have aggregates grouped by customers and aggregates grouped by sales. These summary rows have null in one or more of their columns. The grouping keyword tells us whether a particular row in the result set contains aggregate information for a given column. The grand total row is marked as a grouping row for both sales and customers. The grouping keyword may be necessary to distinguish summary rows from rows that legitimately contain null.
Rollup and cube provide grouped aggregate summaries with very little effort. I highly recommend them for anyone who has to do a lot of SQL report writing!
March 14th 2011 | Jimmy Bosse
Do websites need to be experienced exactly the same in every browser?
Someone just asked me, “Do websites need to be experienced exactly the same in every browser?” (Go to the link now and come back. Go on, I’ll wait…)
While this was initially amusing, my amusement quickly changed to concern. What happens if we stop building sites for the lowest common denominator? I work on a project that still needs to support IE6 because every paying customer needs to be able to use the web application they pay us to provide. I guess I would like to ask the mystery producer of the site, (I believe it is http://simplebits.com/) to define experienced. If it means that every pixel render in the exact same way, then no. But if experience means perform the same tasks, my answer is ABSOLUTELY.
When I go to YouTube, I want to watch a video of some sort, usually a dumb video my father in-law just emailed me. When that web page comes up, I expect to be shown a video. If I am greeted with some snarky message about what a Luddite I am because I use a browser that my IT department makes me use, then in my opinion, your site is a failure. Granted, because you just called me a Luddite, I am pretty sure my opinion matters very little to you. If, on the other hand, you play a pixelated video for me because that’s the best my lame IT department installed browser can render and you also politely inform me that the video would be way cooler if I viewed in on my teenage daughter’s i9000 giga-core quantum computer, then your site is a success. Hey I might even annoy my daughter by invading her inner-sanctum to view the video on my second mortgage and see what all the fuss is about.
In fact, just this morning I was trying to log into my health care insurance provider’s site to research providers and was confronted with a message that I had locked my account. How did I do that? Well, I made the silly mistake of browsing the site with my iPad. Their support staff informed me that the site didn’t work reliably in Safari and that I should use Internet Explorer. My task of doing a simple directory search now required me to go to my office and boot my computer because someone couldn’t be bothered to make an HMTL login page work correctly on the iPad?
It is okay to use a given browser’s full potential to make a user experience better, easier, and faster. But we must remember that as the creators of these websites we are by definition more advanced than the users for which we build them. And if you are like me and have bills to pay and are trying to generate income from them then you want to reach as many users as you can.