The Agile Principles that impressed me most as a Software Developer
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.
Pair Programming
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.
The Sprint
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.’
Conclusion
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.
An Unusual Regex Application
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.
The Agile Virtue of Transparency
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.
Easy SQL totals and other Aggregates with rollup and cube
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!
Do websites need to be experienced exactly the same in every browser?
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.
Working with JSON Values that are C# Reserve Words.
February 17th 2010 | Jimmy Bosse
Working with JSON Values that are C# Reserve Words
While playing around with GitHub’s API for Gists, I discovered I couldn’t simply deserialize into an object because the API used the C# reserve word “public” as a property name. Luckily, the DataMember attribute has a “Name” property that allows to you explicitly map a JSON property to your object’s property of a different name:
1: namespace MyGistClient
2: {
3: [DataContract]
4: public class GistsResult
5: {
6: ...
7:
8: [DataMember(Name = "public")]
9: public bool IsPublic { get; set; }
10:
11: ...
12: }
13: }
While C# will let me make a property named “Public”, I decided to use “IsPublic” instead so I don’t have any issues if my object gets consumed by another .NET language that isn’t case sensitive.
Quick Tip: Control.Find(string id) Extension Method
December 27th 2010 | Jimmy Bosse
Quick Tip: Control.Find(string id) Extension Method
For my current project, I am constantly using FindControl to dynamically locate a child control within a parent control. Instead of constantly typing this:
1: DropDownList dropDownList = employeeListView.FindControl(“regionDropDownList”) as DropDownList;
I created an extention method to prettify my code:
1: public static class ControlExtensions 2: { 3: public static T Find<T>(this Control control, string id) where T : Control 4: { 5: return (T) control.FindControl(id); 6: } 7: }
So now I can type this:
1: employeeListView.Find(“regionDropDownList”);
Enjoy!
