There is No Silver Bullet like ‘Rush code to live’

There is No Silver Bullet for software development, as you can read in Fred Brooks epic 1975 book about software development titled “The Mythical Man-Month“. But if I have to come up with any Silver Bullet it would be: ‘Rush code to live’. This is a theoretical model for doing software development, which follows the DevOps model. Since it is a ‘Silver Bullet’ it claims to be a revolutionary way to produce software much faster and cheaper.

SaaS needs a rush

In a Software-as-a-Service (SaaS) landscape you need to keep your customers happy by continuous, incremental improvements of the software, which follow an organic growth model. By doing big bulky updates, the user will have to wait a long time before anything changes and the user experience will suddenly change, which might alienate your users. Apart from that: 1) the moving target kicks in; 2) risks grow, since reverting will be increasingly difficult; 3) it is unclear what needs to be tested; 4) and users lose confidence when you keep moving the deadline for the next version.

Organize carefully

So take SCRUM, with a product owner and everything that comes with it. Now split your big software team of into small expert groups of 2-3 people that own a specific part of the code. Increased feeling of ownership encourages responsible behavior. Now make sure every group has one natural leader (a more senior developer), to avoid unproductive coding style/architecture discussions. Now let them develop blocks of code that are as small as possible, but can be brought to live individually. This would make programmers work for 2-3 days on a single small feature. If a feature is too big, simply cut it up into parts to make it smaller. Test the feature and bring it to live by the next day, when the code is still ‘top of mind’ and bugs can be fixed fast and easy. It is important the testing is done together with some other developers in demo-like sessions to avoid blind spots and encourage competition and enthusiasm.

Testing and deployment

When bringing the code to live, make sure this is done carefully by only the best developers. Do it when usage is low and do not tell customers about your ‘Ninja deployment’, since this may increase the expectations and thus the bug costs. When bringing code to live, your monitoring must be top-notch and you must be able to revert fast (only to fix bugs and redeploy). This means that if something fails, it will always be the new feature and only a limited set of customers will notice. If you can, bring the feature live for only a subset of the customers first. Both of these measures help further reduce the risk and positively influence the test (test vs. bug costs) trade-off on which you decide the amount of testing effort. Do not hesitate to bring code to live that does not add value. Even if it only provides part of a feature and must therefor be hidden, you should still deploy it.

Change your thinking

Now think outside the box and consider the truth of the following ‘Rush code to live’ principle:

Every 10 lines of code written but not brought live (into production) will cost you one extra man-hour every day.

Reasons it might be true? Only after code is running flawlessly on live will people stop discussing, changing, arguing and worrying about it. Note that I only have a gut feeling to back this claim up, and is not based on any research whatsoever. Still, I believe the cost of unreleased code is way higher than anyone can imagine, so ‘Rush your code to live’ for fun and profit!

PHP 5.3 is now officially end-of-life (EOL)

PHP 5.3 last regular release (5.3.27) was done in July 2013, back then we read the following statement on the release notes:

Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year. – php.net

So, back then it was not a big deal, since security fixes would be released for one more year (and a year seems very long). But last week PHP 5.3.29 was released and since that year has passed PHP 5.3 is now officially end-of-life (EOL). This means there are no further updates, not even security fixes, as you can read in the release notes:

This release marks the end of life of the PHP 5.3 series. Future releases of this series are not planned. All PHP 5.3 users are encouraged to upgrade to the current stable version of PHP 5.5 or previous stable version of PHP 5.4, which are supported till at least 2016 and 2015 respectively. – php.net

Ubuntu Linux users that run the still supported (and popular) 12.04 LTS release on their web server should not be worried too much: Ubuntu maintainers will backport security fixes until 2017. But running PHP 5.3 might be cumbersome, especially if you want to develop using the latest PHP frameworks or libraries. These often contain “array short syntax” and thus require PHP version 5.4 or higher . The simplest option is to upgrade your Ubuntu 12.04 LTS to 14.04 LTS, since that comes with PHP 5.5. If you decide to stay at 12.04 for a while, you will be stuck with 5.3.10 from the repo, unless you…

Upgrade PHP from 5.3 to 5.4 in Ubuntu 12.04 LTS

This is more or less the only option you have. Since it is not officially supported you have to install a PPA. I normally do not recommend this, since you could mess up your system badly and/or severely endanger the security of your machine. But I must admit that Ondřej Surý’s PPA is a very famous and widely used one, which would make it a bit more trusted. So, I will include the instructions, but you have been warned:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:ondrej/php5-oldstable
sudo apt-get update
sudo apt-get dist-upgrade

Why you should not upgrade PHP to 5.5 in Ubuntu 12.04 LTS

PHP 5.5 and it’s dependencies are provided by the “ppa:ondrej/php5″ repo. And even though PHP 5.5 is longer supported and more powerful than PHP 5.4, you should probably stick to PHP 5.4. The reason for this is that PHP 5.5 requires Apache 2.4, where Ubuntu 12.04 comes bundled with Apache 2.2 by default. This means that when you upgrade PHP 5.3 to PHP 5.5 you also have to upgrade Apache 2.2 to Apache 2.4 (as a dependency). This could break many things, but it will (most certainly) break your virtual host configuration. So this is something I can’t recommend unless you are really sure what you are doing. Do not upgrade PHP to version 5.5 without having a tested upgrade plan. I’m serious… be very very careful!

Please stop using pop-up windows in web applications

In the Nineties, we were writing desktop applications with pop-ups. These desktop applications consisted of multiple windows that popped up. I was programming Delphi back in these days, where windows were called forms. The naming probably came from their main purpose: data entry into the bundled Paradox database. This is comparable with the forms that we see today on the web and they were equally abused for other purposes.

The purpose of forms in a database driven application is to facilitate CRUD (Create, Read, Update, Delete) operations. That is why you need the List, Add, Edit and Delete forms. Maybe the Delete form is not needed and this can be just a conformation dialog. To simplify the application flow, it used to be possible to make pop-up windows “modal”. This meant that you could not ignore them and had to click them away before you could continue. This is typically something you would want when you want the user to confirm an action or acknowledge a critical error.

JavaScript (like Delphi back in the day) has simplified making modal pop-ups by offering us the functions “alert()” and “confirm()”. But let’s take an example of a typical company database application. Such an application may have an overview showing a listing of customers. Maybe you can search in this list. If you click on a specific customer you may be able to see a list of their orders. In the Delphi days, we would have a window with customers and when you clicked on the “view orders” button, it would open up a new window with this information.

lightbox_popup
Figure 1: Example of a jQuery lightbox styled pop-up in WordPress

On the web, we first tried to copy this model by opening new browser windows in web applications. Then came the era of pop-up ads and ad blockers, and people started moving away from the multiple browser window strategy. This move was stimulated even more when browsers started having tabs. Then we saw that developers started making jQuery lightbox styled pop-ups on top of other pages. These are still used a lot, but I feel they lead to horrible user experiences wherever they are used.

In the end, most of the developers saw the light (fortunately). They probably realized that you do not need a stack of windows since the web browser already allows you to go back (and forward by opening new pages) in this stack using the back button and the links you can click. Also, the browser creators acknowledged that in order to make users use the “alert()” and “confirm()” functions, they had to make sure these pop-ups rendered in much prettier way. Until then, they resembled the JavaScript error pop-ups from the Nineties.

So today, when I stumble across an HTML anchor tag with an TARGET property, I cringe. It hurts even more when I see people use jQuery lightbox styled pop-ups. Not only because they are almost always a pain to close, but also because they do not work properly on different screen sizes (like phones). However, the worst thing about this form of pop-up, is the wrong expectation that people have about the underlying page. What should happen when the pop-up is closed? Should it be reloaded, so it is updated? Or can it have old data? I don’t know, can you tell me?

To add something constructive to this rant, I will also propose some new rules for pop-up lovers that have a hard time forgetting the Nineties:

  1. Everything is a page, and your application can most probably be represented by a tree (with some jumps back).
  2. Use clickable breadcrumbs to show the current path in the tree structure of your application.
  3. The back button should work everywhere and warn when needed (about reposts or expired pages).
  4. Make sure all your pages have a single, structured, short, but descriptive URL.
  5. For confirmation, rely on the JavaScript “confirm()” function.
  6. Use top of page colored flash messages to show success or failure.

Are you in the business of making web applications that mainly do CRUD operations on a database? Have you still not sworn off pop-ups? Do you think I am wrong? Please use the comments to discuss.

PyCon Australia 2014: conference videos online

pycon_au_logo

PyCon Australia 2014 was held last week (1st – 5th August) at the Brisbane Convention & Exhibition Center.

PyCon Australia is the national conference for the Python Programming Community, bringing together professional, student and enthusiast developers with a love for developing with Python.

For all of you that did not go, most of the conference is available on YouTube (39 videos):

  1. Graphs, Networks and Python: The Power of Interconnection by Lachlan Blackhall
  2. PyBots! or how to learn to stop worrying and love coding by Anna Gerber
  3. Deploy to Android: Adventures of a Hobbyist by Brendan Scott
  4. How (not) to upgrade a platform by Edward Schofield
  5. Caching: A trip down the rabbit hole by Tom Eastman
  6. Verification: Truth in Statistics by Tennessee Leeuwenburg
  7. Record linkage: Join for real life by Rhydwyn Mcguire
  8. Command line programs for busy developers by Aaron Iles
  9. What is OpenStack? by Michael Still
  10. Software Component Architectures and circuits? by James Mills
  11. IPython parallel for distributed computing by Nathan Faggian
  12. A Fireside Chat with Simon Willison
  13. Accessibility: Myths and Delusions by Katie Cunningham
  14. Python For Every Child In Australia by Dr James R. Curran
  15. Lightning talks
  16. How to Read the Logs by Anita Kuno (HP)
  17. Serialization formats aren’t toys by Tom Eastman
  18. Django MiniConf: Lightning talks
  19. What in the World is Asyncio? by Josh Bartlett
  20. Try A Little Randomness by Larry Hastings
  21. Building Better Web APIs by HawkOwl
  22. devpi: Your One Stop Cheese Shop by Richard Jones
  23. Learning to program is hard, and how to fix that by Jackson Gatenby
  24. Lesser known data structures by Tim McNamara
  25. The Quest for the Pocket-Sized Python by Christopher Neugebauer
  26. Sounds good! by Sebastian Beswick
  27. Running Django on Docker: a workflow and code by Danielle Madeley
  28. Software Carpentry in Australia: current activity and future directions by Damien Irving
  29. The Curse of the Django Podcast by Elena Williams
  30. Grug make fire! Grug make wheel! by Russell Keith-Magee
  31. (Benford’s) Law and Order (Fraud) by Rhys Elsmore
  32. The Curse of the Django Podcast by Elena Williams
  33. Lightning talks
  34. The Curse of the Django Podcast by Elena Williams
  35. Seeing with Python by Mark Rees
  36. Descriptors: attribute access redefined by Fraser Tweedale
  37. How do debug tool bars for web applications work? by Graham Dumpleton
  38. Continuous Integration Testing for Your Database Migrations by Joshua Hesketh
  39. Closing

Have fun watching!

A series of quotes from Richard Stallman

Richard (Matthew) Stallman, often known by his initials, RMS, is a software freedom activist and computer programmer. He is a great speaker that makes some strong statements that are definitely worth being aware of, since they also well substantiated by extensive arguments. In this post, we will look at three videos featuring Richard Stallman and list some quotes that may spark your interest in the context in which they were said.

1) Richard Stallman: We’re heading for a total disaster (24:30)

In this interview from 2012, Richard is talking about the dangers of Extreme Capitalism (NB: contains religious and political views).

  1. “..a program is free or proprietary depending on whether the users control the program or the program controls the users..” [2:04-2:12]
  2. “I saw myself facing a life of proprietary software and it was ugly, it was disgusting.” [5:13-5:19]
  3. “Free software combines capitalist ideas, socialist ideas and anarchist ideas, it does not fit in any of those camps.”  [8:18-8:26]
  4. “You father was assuming that when you buy something you control it, and this used to be true, and often it still is true, but not with software.” [10:16-10:26]
  5. “..Microsoft Windows has known malicious features. [It] has features to spy on the user, features to restrict the user, these are called ‘digital handcuffs’, and it has known back-doors..” [10:46-10:56]
  6. “The recent Apple products, the ‘i-things’ have known spy-features, know ‘digital handcuffs’, the nastiest ever, and a known back-door.” [11:05-11:16]

2) Richard Stallman Talks About Ubuntu (6:10)

In this 2013 video, Richard Stallman talks about Ubuntu and its privacy invading features (see related blog).

  1. “Ubuntu has an unusual flaw, which is: it is spyware” [1:38-1:43]

3) Richard Stallman: The Danger of Software Patents (1:57:30)

In 2005, Richard Stallman explains at the University of Calgary (Canada) thoroughly what he thinks about software patents.

  1. “I don’t have an opinion about ‘Intellectual Property’. I have opinions about copyright law. I have a different opinions about patent law. I have an even different opinions about trademark law. I think of these three different subjects separately, and I hope that you will too.” [2:13-2:35]
  2. “You might also think: Let me find out about all the patents that might restrict this program, and then I can try to deal with all of them; that is impossible.” [15:58-16:07]
  3. “They quoted an engineer saying: I can’t recognize my own inventions in patentees [claims].” [24:34-24:38]