No bug left behind

The Software Quality Digest with the latest articles, blog postings and discussions about software quality, testing, usability, accessibility, scalability and related topics of the past two weeks. If you have a relevant link for the Software Quality Digest, please let us know and we would be happy to include it in the next digest.

Software Quality and Testing

• Software Engineering: Dead? – “And yet, it’s also a release. It’s as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I’ve slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.”
• The four essential laws of software updates – “Automatic updates are becoming more and more common, which is a good thing. They save us time and hassle: instead of finagling with installers, we can just sit back, relax, and let all our programs do the work for us. Oh, if only it were that easy.”
• Good Lazy and Bad Lazy – “Something which I’ve come to realise more recently is that it’s not necessarily true that being lazy as a developer is always a good thing – it depends in what way you are being lazy because there are certainly good and bad ways in which you can express your laziness!”
• Book Review: The Art of Unit Testing – “Given my personal commitment to software quality through testing, I was excited to get my hands on a copy of Roy Osherove’s The Art of Unit Testing from Manning. A few weeks ago our copy was delivered and I have been excited for an upcoming vacation which would give me the time to sit down and churn through the book.”

Performance and Scalability

• My Thoughts on NoSQL – “In the late nineties and early thousands, websites were mostly read-only–a publisher would create some content and users would consume that content. [..] And with that fundamental shift away from read-heavy architectures to read/write and write-heavy architectures, a lot of the way that we think about storing and retrieving data needed to change.”
• Latency is Everywhere and it Costs You Sales – How to Crush it – “Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition. “
• Scalability issues for dummies – “Every once in a while I get people asking me what’s taking me so long to open my startup Inkzee to the public. They also ask me what exactly have I been doing as the web seems exactly the same. I normally answer that things aren’t easy, that it takes time, specially if you are alone, like I am. After a while I end up explaining my problems with scalability and that’s the point where people just can’t follow you. I’m going to explain here what are scalability problems and how deep the repercussions are for a small company.”

Process and Methodology

• Considering Agile, deciding against it – “Some time ago, while managing a distributed software project, I spoke to a developer who was thinking about joining our team. This individual was a big proponent of Agile development. When he found out that in our particular project we were not using an Agile development model, he began to lose interest. He compared my position there to the position of the Tom Smykowski character from the movie Office Space.”
• Planning for Feature-Complete Deadlines – “Planning to catch a plane is a perfect example of risk management for contained change: problems are expected, but they usually fall within a range you can still make an estimate of. (I wrote about this in my post The Three Types of Change.) Using experience I can make a probabilistic forecast of the time required to catch the plane. It will take two hours at the least to be there on time. But when Murphy’s Law hits me (and it usually does in some way) it could be anywhere up to four hours.”

Usability and Accessibility

• Mobile Usability – “When designing for mobile, there’s a tension between (a) making content and navigation salient so that people do not work too hard to get there, and (b) designing for a small screen and for slow downloading speeds. That’s why almost every design decision must be made in the context of the site being designed, and what works for a site may not work for another. “
• The Inclusion Principle – “Affordance allows us to look at something and intuitively understand how to interact with it. For example, when we see a small button next to a door, we know we should push it with a finger. Convention tells us it will make a sound, notifying the homeowner that someone is at the door. This concept transfers to the virtual environment: when we see a 3D-shaped button on a web page, we understand that we are supposed to “push” it with a mouse-click.”
• Reinventing the desktop (for real this time) – Part 1 – “Since the 1980’s, this functionality has been presented to users on most systems with only minor variations upon the standard WIMP (Window, Icons, Menu, Pointer) model handed down from Xerox PARC and the first Mac, so, obviously, the modern desktop is not really broken: people have been getting by with essentially the same design for decades now. Still, there is a perennial longing for something better, so the question is what motivates this feeling?”

Security

• Hacking CSRF Tokens using CSS History Hack – “In this exploit, we discover the csrf token by brute forcing the various set of urls in browser history. We will try to embed different csrf token values as part of url and check if the user has visited that url. If yes, there is a good chance that the user is either using the same CSRF token in the current active session or might have used that token in a previous session. Once we have a list of all such tokens, we can just try our csrf attack on the server using that small list.”

As I’ve explained in the first posting of this small blog series, we have been looking for an ideal web development stack for a new installable product. We looked at the most popular development stacks, platforms and frameworks before eventually deciding which one to use. I will try to summarize the pros and cons of the stacks we evaluated and explain how we’ve come to the final decision.

We aren’t experts in all the different frameworks and platforms we evaluated and there are probably some details we got wrong. Feel free to correct us by leaving a comment. So without further ado, here are the pros and cons of the different development stacks in regards to installable web applications:

• Java (including Grails and Spring)

  Java and the various frameworks such as Spring and the dynamic counterpart Groovy combined with the Grails framework qualify in many ways to be the perfect web development stacks for installable applications. The Java platform is very mature and has very good support for cross-platform and cross-database development. If you use frameworks such as Spring, you also benefit from the MVC pattern and from enterprise features and libraries. Java also isn’t going anywhere and it’s safe to say that Java will be available for the next 10+ years and probably a lot longer. Unicode support is also excellent, which is rare for cross-platform development stacks.

  However, one of the biggest drawbacks of this platform also made us decide against using Java: deploying Java web applications is complicated and scares the hell out of us. We wouldn’t feel comfortable having to support deployment scenarios with all the different available Java application servers out there, which you need to run a Java web application. The need for an application server such as Tomcat or JBoss is a serious disadvantage, especially if your customers aren’t experienced with installing and configuring such a solution.

• Ruby on Rails

  Ruby on Rails is a modern and productive web development stack and framework. Using Ruby as the programming language of choice, it’s best known for the MVC architecture and the well-integrated ActiveRecord object-relational mapping system for database access. Ruby on Rails also emphasizes the convention over configuration concept, making it very easy to get started developing web applications. Rails also comes with reasonable support for multiple database servers, but is usually used with MySQL and PostgreSQL.

  Recent versions of Rails also improved the support for Unicode and UTF-8 encoding, making it more suitable for applications that are used by users from non-western countries. Rails is usually deployed by configuring a Mongrel cluster (which is easier than it sounds) and using a front-end web server such as Apache, nginx or lighthttp for static content serving and load balancing the different Mongrel processes. Although setting up a run-time environment for Rails applications is still a lot easier than for Java web applications, it can still be problematic for customers who have no experience with Rails and/or Unix environments.

  This leads us to the big problem with Rails: the support for Windows servers is miserable. Because most Rails applications are developed, tested and deployed in Unix environments, either for hosted web applications or in-house intranet applications, supporting Windows servers isn’t an important issue for the Rails team or developer community. However, if you are trying to sell an installable web application to typical companies, Windows servers are still extremely popular for internal application and workgroup servers. And if your potential customers are used to running Windows servers, you better make sure that your solution works flawlessly in this environment.

• ASP.NET

  ASP.NET is a good choice for many installable web applications. It’s reasonable easy to deploy an ASP.NET web application on a Windows Server with IIS and most companies (and potential customers) already have such a server running as an internal application server. The Unicode and localization support is also top-notch and if this is one of your most important requirements, you should definitely consider going with this development stack.

  Another big plus for ASP.NET is the strong developer community with countless of blogs, books, websites and forums. The rich offering of user interface controls, libraries and development tools for the .NET platform in general and ASP.NET in particular by third-party vendors is also unmatched. However, ASP.NET also has its problems. ASP.NET Web Forms really encourages mixing application logic with the user interface code, which can result in badly designed applications and hard-to-maintain code. The abstraction in ASP.NET Web Forms that’s supposed to make web development easier for Windows desktop developers makes the development stack hard to debug and overcomplicates things.

  Experienced ASP.NET developers try to workaround these limitations by using patterns such as MVP or MVC. Especially Microsoft’s new ASP.NET MVC framework is an interesting alternative to Web Forms, as it encourages the separation of business logic, data access/validation and user interface code and makes it easier to build a maintainable application. This leaves us with the biggest drawback of ASP.NET: the lack of cross-platform support. Sure, there’s Mono, an open source .NET implementation that also supports ASP.NET. But while it’s definitely a nice option to have, it’s not widely used and I personally would not consider it to develop cross-platform web applications at this point.

• PHP

  PHP is arguably the most used web development programming language, despite it’s many technical limitations and problems. The main reason PHP has become so popular is that it’s extremely easy to use and that it’s supported by virtually all web hosting companies. Developing an PHP application without using a decent application framework will most likely lead to an unmaintainable code base, however. The language itself, although explicitly designed for web development, doesn’t come with a (MVC) framework and doesn’t help with separation of concern in any way.

  One of the technical limitations is the lack of Unicode support. While most development stacks have quite good Unicode support by now, PHP’s support for non-western characters is still very limited and if you plan to support most server configurations and multiple databases, it’s basically non-existent.

  Luckily, there are quite a few available PHP frameworks to remove some of the mentioned limitations such as the Zend framework, CakePHP or CodeIgniter. Using one of these frameworks makes it a lot easier to write maintainable applications and also provides you with often needed functionality not found in PHP itself, such as a database abstraction layer.

  Of course, PHP also has its good sides. Applications written in PHP are very easy to deploy and work on most operating systems and server configurations. Even Microsoft is working hard to improve the PHP deployment experience on Windows and IIS, as many popular web applications such as WordPress are written in PHP. The great cross-platform, cross-database support combined with the ease of deployment and available frameworks make PHP a good web development stack, even though it’s not the best technical choice.

Having evaluated the above mentioned frameworks and having looked at the pros and cons of each development stack, we have come to the conclusion that PHP together with a lightweight framework such as CodeIgniter is the best choice for an installable web development stack, at least today. Yes, from a technical standpoint, PHP is less than great. The ability to easily deploy and run a PHP application on most server configurations, however, easily outweighs its limitations. One drawback that really made us think twice before deciding to go with PHP was the lack of proper Unicode support. Unicode support was originally a really important requirement to us, but we decided that we can do without Unicode support for a few more years until this problem will hopefully solve itself (with better Unicode support in PHP).

You might also be interested in our reasons to choose CodeIginiter as the PHP framework for our application. The great thing about CodeIgniter is that it’s a really simple framework. Although CodeIgniter only offers the most basic features and you have to implement advanced capabilities such as locale or authentication support yourself, this simplicity makes it really easy to understand the entire code base in a very short amount of time. So even in the unlikely case that we needed to fork this framework because the authors stopped supporting it, we could easily improve and add features to the existing code ourselves, something that is not really feasible with most other frameworks and stacks out there as they are often too complex.

Some months into development we are still happy with our choice. The application is coming along nicely and PHP and CodeIngiter have proven to be a solid development stack for an installable web application so far (of course, the real challenges come when customers deploy our application in many different hosting environments). Our choice of a development stack would most likely be different if we were building a hosted solution where we could control every little aspect of the server environment. But because our customers will have to deploy and host our application themselves, PHP and CodeIgniter are a great choice for us.

Now before you start your next big thing, make sure to consider all your options, as you cannot easily change platforms once you’ve invested a lot of time and resources.

The Software Quality Digest with the latest articles, blog postings and discussions about software quality, testing, usability, accessibility, scalability and related topics of the past week. If you have a relevant link for the Software Quality Digest, please let us know and we would be happy to include it in the next digest.

Software Quality and Testing

• Quality is Dead #1: The Hypothesis – “You know it’s dead, too, don’t you? You long ago stopped expecting anything to just work on your desktop, right? Same here.” .. and a response by Uncle Bob
• Which Is More Beautiful Architecture – FP or OOP? – “So, who wins? That’s a good question. If you’re in a world resigned to side effects then OOP might just be for you. Else, Haskell and the lessons learned from the language can be powerful instruments in creating rich and beautiful architectures using pure functional techniques. “
• Anecdote Driven Development, or Why I Don’t Do TDD – “Two words: tee dious (sic).”
• Are short methods actually worse? – “Another way of putting it is: short methods may have more defects per line, but they still have fewer defects overall.”
• What makes a system hard to work with? – “My point here is that I definitely believe that there are certain ‘qualities’ of a system’s design that either hinder or accelerate the progress of the system.”
• Slow tests are a bug – “And slow tests are a problem for at least two reasons: they slow down your development and decrease code quality.”

Usability and Acessibility

• Bargain Basement Usability Testing – “We know it is good to focus on usability. We need only look at Apple and the iPod to know that it provides tangible benefits. However, in reality we often shy away. It is hard to prioritize usability when deadlines are looming and budgets are tight.”
• Kindle 2 Usability Review – “The new version of Kindle, Amazon.com’s dedicated e-book device, recently shipped with an improved display and various other upgrades. It now provides good usability for reading linear fiction (mainly novels), though it’s less usable for other reading tasks.”
• Beautiful Forms – Design, Style, & make it work with PHP & Ajax – “We will go through designing and usability you need to keep in mind, styling your form, spicing it up with some nice javascript effects, validating user’s input and finally getting it to work using PHP and Ajax.”

Performance and Scalability

• The Computer Performance Shell Game – “If you’re interested in performance, the absolute first thing you have to do is determine which of these bottlenecks is currently impeding performance — and eliminate it.”
• Performance Impact of CSS Selectors – “This had me convinced that optimizing CSS selectors was a key step to fast pages.”

Technical Tips

• Understand Normalization Before Denormalizing – “Database denormalization is an area which is frequently misunderstood and gets software developers into trouble. Many developers seem to think that denormalization is the antithesis of normalization and have conflicting goals.”

Process and Methodology

• How to be a program manager – “Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t.”
• Sharpening the Saw – “Sharpening the saw is shorthand for anything you do that isn’t programming, necessarily, but (theoretically) makes you a better programmer.”
• The Bare Minimum – “When it comes to project management, I tend to favor the less-is-more approach. For the most part, I think teams should be self-managed and organized. I’ve never seen project managers actually add value – they merely get in the way and slow teams down.”
• Agile, management tools help small team boost software quality – “Indeed, Comet estimates that these tactics have improved software quality by 25% and time-to-market by 10 to 20%.”
• Improving Software Process – A Letter to Upper Management – “Any process, principle, practice we choose should have quality at its heart. Regardless of what process, principles, practices we adopt they will only be successful if we are disciplined enough to follow them.”

Misc

• Wolfram|Alpha Is Coming! – A new search engine by the makers of Mathematica, launching in May
• How to Succeed at Anything – “The good news: Talent is meaningless. You can be world-class at anything.”

Welcome to No bug left behind. This new blog is all about software quality, testing and programming and is written by Tobias and Dennis Gurock. We are planning to post articles, links, technical tips and other tidbits related to software quality on this blog and are also looking forward to occasional guest posts by other developers and testers. If there’s a software quality related topic you would like to read about, email us or leave a comment, we appreciate any suggestions!

You can learn more about us and our background (and how we found the stupid name for this blog) on the About page. Also make sure to subscribe to No bug left behind if you are interested in software quality and related topics. Enjoy!