Posts Tagged ‘software’

You’ve no doubt heard of us at Glorry, the exciting Silicon Valley startup that is taking the world by storm. We’re best known for raising £17 billion in funding on Kickstart in less than 38 minutes, despite having no discernable business model. Still, that’s what they said about Instagram and look who is laughing now. Mark Zuckerberg, that’s who.

We’re pushing the limits of Agile delivery to see how we can deliver the most value to our customers. But our Service Delivery team are also looking to ensure a consistent and stable customer experience that doesn’t allow new features to compromise on quality.

The result is a methodology we’ve called “No-Release” and I’m excited to share some details of it with you today.

What is No-Release?

Simply put, we don’t release any code.

What are the results like?

They’ve been outstanding. Since we adopted this approach, we’ve had zero bugs introduced to the live system. That’s not a misprint: zero bugs. Not one single incident has been released related to the new code we’ve been writing.

Since adopting this approach, our velocity has increased. Developers feel more confident that their work will not cause issues in live. Product Owners are happy to prioritise tech debt because they know it won’t delay new features arriving in live. Service Delivery is less jittery about degradation due to changes to the product.

How does it work?

We based our workflow on a traditional Scrum methodology. We operate in two-week sprints with a backlog of features prioritised by the Product Owner. Each ticket begins with a Business Analyst sitting down with a Developer and a Tester to work out how we can deliver and test the acceptance criteria of the ticket.

When a ticket is complete and signed off, including going through our continuous integration pipeline where a series of automated tests are run, we then merge the ticket into our develop branch. At this point, the ticket reaches our Definition of Done and we can close it.

Our master branch contains a copy of the code deployed to live, while our develop branch contains all of the new features. Because we operate under No-Release, we almost never have to deal with merge conflicts because we never merge develop into master. Or anything else for that matter.

What are the drawbacks?

One of the biggest drawbacks to No-Release is that you do not release any code. This means that no new features and improvements ever make it to the end user.

Making this work requires buy-in across the organisation. Without everyone being on board you can easily get developers saying “this is pointless, what am I doing here” every stand-up, and upper management suggesting they can fire the entire team and get the same results for much less money. Therefore, it’s important to get everything to embrace the methodology before starting.

Each organisation needs to make its own decision as to whether this drawback is acceptable to gain the benefits discussed above.

Conclusion

No-Release methodology allows you to increase your development velocity while eliminating any risk of service disruption to the end user.

As a software consultant, I spent a lot of time going into big, slow-moving organisations with legacy software and helping them sort it out. One persistent feature of these organisations is regular but infrequent releases of their platform and a fear of moving to anything more rapid.

By infrequent, I mean they might release a few times a week (Tuesday and Thursday are fairly common), or maybe each weekday, or maybe even just once a week. In the world of agile, all of these schedules are infrequent. Modern, agile platforms release constantly.

Typically, these companies will be afraid to move to anything more agile because they have a system in place and they think that it works. They say things like “we can’t risk continuous delivery (CD), people depend on our platform”.

This, in my view, is a mistake. And in this post, I am going to set out the reasons why it is safer to use CD. Not why it is better for the product owners, makes more money and keeps your developers happy, though those are all good reasons. I will make this case purely from the view of change management and their worry that it will damage the integrity of their system.

Big bang releases do not work

The old model involves people from every team merging their code into a release branch, that branch being put on a staging environment and then manual tests being run against this.

This is a terrible way to do things. As everyone merges in their code you get conflicts. Some of which will be resolved correctly, some will not.

The changes interfere with each other in ways that you cannot predict and there is just too much ground for the manual test engineers to cover.

Worse, when everything does break because you have pushed 20 features live at the same time, it is then really difficult to do anything about it because you have to check whether you can roll back, then check whether there is anything critical that needs to go out, then do a fix branch or a new release branch and rush through the whole process again.

And it produces a huge number of incidents. If you have zero incidents right now, you have a good system. But does anybody have that?

It created an automated testing culture

Such companies often say “we will move to CD when we have 100% automated test coverage”. But this is an unrealistic standard because they do not have 100% manual test coverage now.

Worse, because people rely on the manual test engineers to do the regression test, they don’t bother to put in place the correct level of automation. Maybe someday there will be a company that magically finds out how to do that. But nobody I have seen has so far.

The only way to force your engineers to do it is to move to a CD model and let them know that if they don’t put the automation in place there is no safety net and it will be traced back to them.

You don’t get features interfering with each other

Under the CD model, you release one feature at a time. So, gone are the days when two changes are merged in and don’t play nicely with each other. Each change goes out separately having passed all of the tests.

Critical features don’t get blocked

Sometimes, you have to push something out that is really important.

Under the traditional model, this is a major issue. Either you push it out as part of the scheduled release, and risk another feature breaking and you having to rollback your critical change. Or you block out the entire release and stop everyone else releasing for a few days. Which, as you can imagine, creates an even bigger big bang release later down the line.

These problems are eliminated with the one-feature-at-a-time CD model.

It is easier to roll back

If you do get a problem, it is super easy to roll back. You just hit the rollback button.

Under the traditional model, you have to check if you can roll back (due to all of the dependencies) and then if you are allowed to roll back (checking with the product owners that they are all okay with it) and then do some complicated rollback script.

All of this is simplified under a one-feature-at-a-time CD model where if it doesn’t work, you just roll it back straight away and don’t block anything else from releasing their features.

You can get fixes out faster

If something does slip through the net, you can get a fix out of the door faster than ever before. Gone are the days when you make the fix, try to work out what release branch it needs to go in, do all of your manual testing and then push it out the door.

Instead, you just write the fix and release it. And it’s fixed, way faster than it could be using the traditional model.

Summary

Yes, continuous delivery will make for happier product owners, happier developers and a faster-moving business.

But, and this is most important of all, it will also make your platform safer and more reliable. People think it will make things riskier, but, as I have outlined above, this is simply not the case.

With the CD model, you isolate every feature and every release, which is the gold standard of good change management. And, if anything does go wrong, it’s easier than ever to rollback and push a fix out.

Companies often believe that they cannot risk moving to a continious delivery model. However, if their platform truly is important, then they cannot risk not moving to the CD model.

Many people imagine that software engineers spend most of their time writing code. Even in a perfect world, that would not be the case. A properly planned and designed system is always going to beat out a rushed and poorly designed one. But regardless, we are not in such a world. In reality, our time looks like this.

AppSpotr is a cloud-based service that allows you to make your own apps for iOS and Android.

I had a very brief play around with it so I won’t pretend this is anything like an in-depth review. It allows you to create apps using a drag-and-drop editor. You can add a number of different pages to the app, the basic ones are free and then there is a monthly price for the rest of them.

So, for example, if you want to add a form to capture people’s details, that costs $5 per month. Or the enhanced content pages which you need to add videos costs $1 per month.

It seems like a useful service if you are, for example, a restaurant or hotel that needs a little app with a simple menu and some content pages. But, for anything more advanced, it probably will not provide you with what you need. There is no logical, for example, it is just a list of pages.

You also need a developer account with whatever platform you want to publish to.

Recently I trialled using iA Writer as my word processor of choice for writing. Previously I would use Google Docs, which has been very good. It has all the features you would expect from a word processor and automatically generates a navigation structure on the left hand side so you can quickly jump around the document.

iA Writer is very different in that it is a pure text editor. It uses the Markdown syntax, so instead of a WYSIWYG editor, you get text on one side, that you have to use markup in, and a preview pane on the other. The big advantage for me, over Google Docs, is that it can handle large files. Google Docs works great, but as you start getting up to 50,000+ plus it starts to really struggle.

iA Writer handles these large files fine, but the rest is a mixed bag.

It looks really nice

The idea behind iA Writer is to allow you to concentrate on the words. This is does very nicely. You get a simple interface that you can take full screen to remove all distractions, and the layout and style are well thought out. You can enable typewriter mode so the current line is always centred on the screen, though this feels a bit like a gimmick so far.

The image support is not great/strong>

Preview panel scrolls independently

This is one of the most annoying features: the text panel and the preview panel are not properly synced. As I scroll down one, the other one scrolls, but at a slightly different speed. Therefore the text and preview panel are always out of sync. You cannot see what you are working on, and if you scroll to that point in the preview panel, you lose your place where you are writing.

There is no navigation

Google Docs automatically generates a navigation bar on the left, based on all of your chapter titles and sub-headings. iA Writer does not do this, so the only way to navigate around a large document is to remember all of your headings and use the text search to locate them again.

This comes up a lot because you have to put references in the bottom of the document, so I am constantly scrolling down to the bottom, adding a reference, then trying to find where I was writing so that I can insert the appropriate footnote marker and continue working.

Summary

iA Writer is a nice piece of software. However, it feels like nobody has put a really large document in there and thought “is this usable?” Given it is specifically targeted at writers, I am not sure how they imagined it would be used, or maybe did not think through the use-cases beyond somebody writing fiction linearly.

In How to Build a Billion Dollar App George Berkowski takes you through the stages of coming up with a mobile app from concept to being a billion pound company. It is based on his story co-founding taxi app Hailo.

As you might expect it is a pretty whistle-stop tour of each stage of the business. However, it provides a good overview with various comments and advice that Berkowski brings from his experience at Hailo. He stresses the importance of getting the product right for the market and how you should be measuring growth, two of the keys to getting a successful product out there.

While it is a good overview, I am not sure how much I am going to take away from it. Compared to something like The Hard Thing About Hard Things which offers plenty of specific and useful advice, this is more of a general guide to the journey. The one thing I did really like was a list of concepts that have universal appeal to humans. This is great for brainstorming ideas from.

I also found it interesting that he recommended having one Scrum Master for around 12-15 engineers. I have worked at a number of companies that do agile and a typical setup in the UK would be one Scrum Master to around 3-5 engineers, a considerably different ratio.

As part of my push to attend more conferences this year, and get out into the real world, I recently attended PHPNW12, a PHP developer conference that took place in Manchester.

I arrived on the Friday night and checked into the hotel across the road from the conference, the Britannia. With it’s sweeping balconied staircases it felt like I was in a 70s horror movie. The floors creaked and the light in the corridor outside my room flickered on and off constantly – indeed, it rather ruined the mood when they fixed it.

The Friday night featured a hackathon, though not feeling too well due to the tail end of a cold, I spent about 20 minutes hacking, then ate my pizza while I checked my emails for an hour and headed to bed, not to emerge until 12 noon the next day when I felt a bit better.

The talks were on the whole good – there was a real range in there, some had really interesting topics but due to their lack of experience presenting talks, where rather dull. Others were confident and entertaining speakers who despite presenting quite dull topics (caching is not going to be mega interesting) presented brilliant talks. On balance, I would certainly prefer them to focus more on speaker quality over topics next year.

On the Saturday night there was a social including dinner, at which I spent quite a bit of time getting to know some of the other people at Sky – I didn’t realise they were going as I hadn’t gone with Sky, but it was great to see some familiar faces there.

Overall, I found I learned a lot from it. If I can bring back just a few ideas to my own business then it will have been worth the expense.

Staircases in the hotel. I also tried the new panorama function on iOS6, on it’s side:

By this point, most developers have realised that Firefox is a cludgey pile of crap that eats up all your memory, and made the switch to Chrome, those developer tools long since surpassed Firebug.

Recently though, I’ve been running out or memory a lot and I don’t think it’s accurate to say Chrome isn’t to blame. As it runs everything in different processes, it’s easy to miss how much memory it is eating up, but I found it using 620MB of memory with just four tabs open.

Of course having Netbeans eating up so much clearly isn’t helping either, but IDEs are always a bag of crap (Eclipse is worse, I miss Notepad++).

You know, except for the fact that I don’t have a dubiously serviceable spaceship named Serenity (I don’t have a perfectly serviceable one for that matter either). Nor do I have a crew, rugged good looks or such a free-spirited approach to whether to follow the law or not.

Look at him there, what a man.

Pioneers, out there, working for themselves. Well, that is what I will be doing. I recently handed in my notice at Buzz Sports. It has been an amazing three years, but the time has come to move on and establish my own technical consultancy, which will be opening its doors in April.

So if you need help with your software project, get in touch. With expert knowledge of scalable web application architecture and a reassuringly expensive price tag, you’re in safe hands.

I recently requested an evaluation of Go, an agile release management tool from ThoughtWorks Studios.

I filed out the form but unfortunately it insisted I hadn’t filled out my city, even though I had. So I sent a support request to them and a few hours later, someone emailed me back asking where I was based so they could direct my query. I told them, but never heard back from them.

A month later I got an email from one of their sales guys asking me how I had got on with my evaluation. I emailed them back saying I never actually had an evaluation because they had never got in touch. He apologised and sent through my license key. However, at this time I was on my Mac, so I had to download the Mac client. I went to the website and this time I managed to register and download the software. Great, I thought.

Unfortunately, I didn’t get time to look at it until I was back in the office and by that time I was back on my Windows machine, so I needed to download the Windows version. I went to the website and tried to enter my email address I had used last time I registered to download.

But I just got an error. So I tried again. Another error, different this time. So I tried to go through the whole registration process again, but this once again went back to telling me that I hadn’t entered my city when in fact I had.

I sent their support another email asking for the direct download links and having been sent them, I was finally able to download and install the server. Huzzah! So I did that, but then didn’t really know what to do. It said it had started the sever, which was fine, but there was no indication of what to do next.

After some googling, I eventually found the URL I was supposed to access the dashboard with and entered that into my browser, but didn’t get anything. I tried restarting the server, no luck. I tried running it from the jar. No luck. I even tried uninstalling and reinstalling it. Still nothing.

I decided to boot up my CentOS virtual machine and try installing it there. I downloaded it and tried to run the installer but it told me I needed JDK 1.6 or greater. A quick search through yum and I had it installed. I tried to run the installer again and I got the same error, even though I now had JDK installed.

Eventually, after searching the web for awhile, I found out that they didn’t support OpenJDK yet (you know, the JDK that everyone on Linux uses) so you have to install it using the ignore dependencies flag. Finally, it installed.

It then said that Go Server was up and running and so I tried to access the URL, but it did not work. I tried Apache, and that was working fine, so my virtual machine was working fine, it was just Go Server. By this time it was quite late so I turned everything off and headed home.

The next day I got in early to have a play around with it. I booted up the virtual machine and tried to start Go Server using the service command. All I got was “Error starting Go Server”. I tried googling the phrase, but apparently, it had never before been seen on the internet.

I tried googling some more and eventually found a post that seemed to have the same problem that I had. They eventually found that the problem was to do with the hostname. I couldn’t find any way to change the hostname though, so decided to try the Windows approach and remove and reinstall it. This didn’t work either.

I tried to go look it up in the online documentation, but their website was down again with a 500 error. I waited a few minutes and did a couple of refreshes and eventually it reappeared, but I couldn’t find a solution.

By this point, I had wasted far too much time on this, so I gave up. My advice is, go elsewhere for such software.