Boosting Developer Productivity: Tools and Techniques for Efficient Coding

From ensuring that our smartphones operate efficiently to creating the software that runs large enterprise systems, developers are the brains behind much of the technological advancements we’re seeing today. However, software development is neither quick nor easy. And neither does it come cheap.

In fact, it takes around 4.5 months for the average software development project to be completed at an average cost of $36,000. With demand for such projects at an all-time high, developers need to get into a flow and experience deep focus to be productive.

That’s why using the right tools and techniques to enhance coding efficiency are so crucial. And that’s exactly what we explore in more detail below. Let’s dive in.

Understanding Developer Productivity

Developer productivity can be understood by exploring some of the objectives and key results (OKRs) against which their work is measured. Some of these are time-to-completion, bug rate, and code coverage.

Despite working toward clear OKRs, achieving these goals is sometimes hindered by common challenges that developers face that hinder their productivity. Examples of these include:

  • Interruptions and meetings
  • Micro-management and tight deadlines
  • Vagueness and unclear prioritization
  • A distracting workplace environment
  • Uncontrolled changes in the project’s scope
  • Unclear product definition process
  • Tool multiplicity and hardware
  • Lack of documentation

Techniques and Strategies for Boosting Developer Productivity

Software team leaders and project managers who are aiming to boost productivity of their developer teams should consider the following strategies:

  • Minimizing distractions and multitasking: When developers write code, they are in a space of deep focus. The smallest distractions could lead to drops in productivity and have other negative effects. The same is true when you require your developers to multitask. Whether it’s attending to incessant phone calls or unplanned stand-ups, it’s necessary to create a positive space where they can thrive. Give them sufficient time to prepare for planned meetings in advance, ensure they are working in a quiet environment, and avoid micro-managing them to avoid frustration and poor productivity. You can also use task apps to organize tasks by priority and set time limits so your developers don’t have to waste time and attention preparing their to-do list. 
  • Optimizing the Integrated Development Environment (IDE): There are software apps that help developers operate more productively. Essentially, this is known as an IDE and it combines functionalities that include software editing automation, building, testing, and packaging. IDEs can improve coding efficiency through additional capabilities syntax highlighting, intelligent code completion, refactoring support, debugging, etc.
  • Clear project specifications: The importance of well-defined project specs in reducing misunderstandings cannot be stressed enough. Project team leads should introduce well-defined project deadlines with achievable milestones along the way. There should also be verification by the client or interested party of the expectations of deliverables that the project should produce upon completion. Other key criteria include having a clear budget, setting out quality assurance requirements, and software requirement specifications (SRS), including functional requirements, non-functional requirements, and technical requirements.
  • Eliminating unneeded tests: While testing may be a natural part of the software development process in ensuring conformity with business requirements and technical specifications, it shouldn’t go overboard. Instead, there should be processes in place that review and aim to optimize the testing activities. Ultimately, this can reduce the execution time for the final product. 
  • Utilizing No-Code Platforms: In recent years, the rise of no-code platforms has offered developers a new approach to streamline development processes. These platforms allow for the creation of software applications without the need for traditional programming, enabling developers to focus on higher-level tasks while still achieving efficient results. Integrating such platforms into development workflows can significantly boost productivity by accelerating the development cycle and reducing the need for manual coding tasks.

Developer Productivity Tools

While there may be many developer time tracking and productivity tools available, we’ve curated the top two to help you with different development tasks. Here are the tools that topped our list:

Sublime Text

sublime text

Developed by Jon Skinner, Sublime Text is a versatile text editor for code, markup, and documentation. It is incredibly fast in launching and can handle large files with ease. Available for Windows, macOS, and Linux, its cross-platform compatibility means switching between different operating systems is a breeze and no functionalities are lost.

For those developers who would like to customize their coding environment, its functionality can be extended using community-contributed packages. Meanwhile, there are plugins that can be used, too. With a minimalist and clean interface, it offers a clutter-free environment for distraction-free writing.

What is more, it offers the ability to make multiple selections and edits at the same time. It offers a command palette to help you access numerous functions quickly. And for more complex projects, you can split your code into numerous columns or rows for easy comparison and editing. Finally, it can be configured to automatically save your files regularly.



While there are distinct advantages and disadvantages of cloud computing, using GitHub is all about the benefits. This is a website and cloud-based service that helps developers boost their productivity. Think of it as a massive file where multiple developer collaborators can work on a project, store code, and implement version control to manage changes to their code.

It’s all about improving developer productivity and taking it to the next level seamlessly. What is more, it has a user-friendly interface, making it easy for novice and experienced developers to share, merge, change, and write code in one place.


With the techniques and tools mentioned above, project managers can ensure greater developer productivity without compromising the mental health of their team members.

Many developers experience burnout and this needs to be prevented with proper collaboration and communication, supported by the right tools.

Enhancing developer productivity in coding can be a more streamlined process as managers take their wellbeing into account.

Nikola Baldikov is a skilled SEO expert who is dedicated to helping businesses thrive. He is the esteemed founder of InBound Blogging, where his expertise lies in search engine optimization and crafting effective content strategies. Throughout his career he has had the pleasure of collaborating with a wide range of companies regardless of their scale and has consistently aided them in accomplishing their objectives online. During his leisure time. He finds joy in engaging in football matches and dance routines.

Community Tips

Protecting APIs by Merging Tools and Security Best Practices

Rapid uptake in adoption by industries ranging from banking to retail to autonomous vehicles of customer- and partner-facing and internal application programming interfaces (APIs) to drive internet traffic has resulted in an equally rapid growth in endpoint attacks – more than 11 billion over just 18 months according to a report from edge computing security leader Akamai. It makes sense that they are more vulnerable to threats from malicious actors, given API endpoints’ similarity to internet-facing web servers, and their role as pipelines between divergent platforms.

For DevSecOps teams, protecting APIs is a top priority; they are vital to mobile, SaaS, and web applications and paramount to a healthy software development lifecycle. API security is also a natural extension of DevSecOps’ push to break down silos between development, security, and operations and move toward automation and design that integrates security as a shared responsibility. 

Thus, it is time to view API security not as an external bottleneck, but as a part of a stable long-term strategy. This can be achieved by altering company attitudes and investing in API tools that facilitate testing, enforce governance standards, and automate recurring security tasks.

Adopt an API-as-a-Product Strategy

A primary reason digital transformation efforts have failed for many brands is because they do not see APIs adding value. As such, they’ve lost track of the potential return on investment (ROI) APIs can deliver. When APIs are not viewed as assets or value-generating, they aren’t subject to the appropriate level of protection or security performance oversight. In fact, Akamai’s report highlighted the fact that many enterprises relegate API security checks to the end of the lifecycle and rely on traditional network security solutions which aren’t designed to protect against the attacks to which APIs are subject.

This is starting to change, however, as API-as-a-Product strategies gain traction within the developer community. There is a notable shift away from delivering project features based on budgets and deadlines to holistically examining APIs as products and assessing their capabilities. Further, as the concept of monetizing APIs gains prominence, their protection becomes a higher priority at the outset, with organizations more inclined to adopt a human-centered design approach. 

What this means is moving API regression tests to the forefront rather than treating them as an afterthought. It means adopting a design-first approach – wherein everyone on the team speaks the same language and every tool is able to leverage the same design – from the outset with the help of an API management platform. This will also help ensure that APIs are built on established authentication and authorization mechanisms such OAuth 2.0, which is the industry-standard protocol for authorization, and OpenID Connect.

API testing tools are critical for protecting something upon which most services in use daily rely. These tools let developers see if an API is reacting adequately to unexpected inputs or possible security attacks. They show immediately if an application is running with optimized functionality, reliability, and security.

Whether it is running user authentication, parameter tampering, unhandled HTTP, or fuzz testing, it is imperative to test an API contract to ensure that services can communicate and that the data they share is consistent with a specified set of rules or standards. Further, there are many solutions in the API testing market, including cross-cloud API testing software, software that supports asynchronous testing and continuous integration/continuous deployment (CI/CD) integrations, and end-to-end testing – as well as solutions that support various formats eliminating the need for developers to learn new languages. 

Continuous testing is essential across the DevSecOps pipeline, as is robust test coverage based on API contracts that have been designed and approved. Plus, by chaining together complex API transactions and workflows, cases can be tested on-demand using continuous delivery or CI/CD to reduce downtime. 

Security in 360-degree Lifecycle Management

While API security considerations have typically been an afterthought to ever-increasing business demands, the reality is that no enterprise can afford for software security checks to be the last stage of an API lifecycle. Rather, security must be part of a 360-degree API lifecycle management strategy. It should be incorporated into every level, from planning and design to developing, testing, and release management – all the way out to deprecation.

Developers must also have oversight throughout the entire API lifecycle – which is where an API management platform comes into play. A dedicated platform can provide workflow visualizers that show an API’s complete lifecycle in a single view with issue alerts, which helps accelerate production using CI/CD in the DevSecOps pipeline to build trusted artifacts and more rapid iterations, thereby guaranteeing a security-first mindset. 

API tools also allow perimeter scans, which enable the discovery and inventory of APIs and allow for easy breakdowns for DevSecOps teams to work with. The best platforms will leverage a command line interface (CLI) – a unified tool for managing and controlling multiple services from the command line or with automation through scripts – to make APIs more easily discoverable. The team can easily determine where and how many APIs are deployed; a level of visibility that is mandatory for enterprises. 

Tools for Success

In short, an API team is only as successful as the set of tools at its disposal.

API security best practices are no mystery to seasoned security professionals – and they start with establishing solid API security policies through an API management platform. 

Finally, a collaborative approach to API governance – in line with the DevSecOps mission to eliminate siloes – is imperative for any organization’s security. 

About APIWizAPIwiz is a low-code, API automation platform allowing developers to build and release reliable APIs quickly. With APIwiz, API teams have complete control, visibility, and predictability over their entire API program, allowing organizations to stay open and connected.

Interviews Tips

How to build a debugging tool and turn it into a business

From a common developer frustration to an award-winning company that has clients like SAP, IBM and Mentor, what does it take to turn a problem into a lucrative business?   I had a chat with Greg Law who is the co-founder and CEO of undo. Greg went from founding his company in a shed to building a business with top enterprise customers. What we all want to know is – how? Read on and get inspired! Could you be the next Greg Law / Undo?

Vanessa: Tell us a bit about Undo.

Greg: Undo is a tool that allows developers to see what their software did and why, at any point in time. The tool (LiveRecorder) allows engineers to record the execution of a program and wind it back to see exactly what it did to identify software defects. You can step line by line in a debugger – forwards or backwards – and see all of the program state too.

Customers use us when they are completely stuck with an issue, and rather than guess what the problem is, they can pinpoint it. There were devs who would spend days, even months trying to figure out the source of a bug, and they try LiveRecorder and it enables them to figure it out in a few minutes.

The tool was originally aimed at the enterprise market, but more recently it has been used by more smaller companies, even those with small teams.

“The pandemic helped change this, there was no more travelling to meet with potential enterprise customers, and thankfully the tool was matured enough that it could be downloaded by people from our website, without the need to support hundreds of support requests.”

It was always part of the grand plan but the pandemic brought it forward.

Vanessa: How did you build your team?

Greg: It’s kind of the classic story. I founded Undo with a good friend of mine, Julian from when we worked at Acorn back in the day. We worked evenings and weekends together, it reminds me of a quote I heard recently, a programmers mantra of “We do these things, not that they are easy, but because we thought they were going to be easy”. We did eventually get to a v1, then bumped into an old friend that Julian and I had worked with at Acorn, he was looking for his next job. He joined us in the shed at the end of my garden, that was in 2013, and he hasbeen with us ever since.

Vanessa: How many are devs on the team?

We have 34 on the team.

Vanessa: Which collaboration tools do your team use to stay on top of the projects?

Greg: Git with GitHub on top of that, in fact in the early days it was just Git.  

We used a todo.txt file and when we had 3 or 4 people that worked really well. It’s quite nice that you mark things in different states in different branches and it all just works. But obviously, it doesn’t scale. We used Phabricator for a while but ended up switching to GitHub.

Google Meet – and all of Google’s G-suite. There were worries about locking into a giant corporation but the convenience of it is too great!

Collaboration is about culture more than tools. We were definitely an “in the office culture” prior to the pandemic, and felt that the facetime, building deep relations and trust were good face to face, and that worked really well. That said, we were already beginning to recruit remotely in some exceptional cases. And of course, that has now changed 18 months ago and we transitioned like everyone else due to the pandemic. 

If the pandemic happened ten, even five years earlier, it would have been alot worse for those in the knowledge industry. Even five years ago video conferencing was expensive so having Google Meet made things a lot easier. The most important thing with remote working is to write stuff down so that you can communicate asynchronously, not just remotely. Google Docs has been very good for that.

Vanessa: What kind of culture do you offer to developers in your company?

Greg: It’s one of those things that is quite hard to define. I cringe so often when I hear people’s answers to this question. It can be cheesy, and buzzwords. Often if a company publishes it’s values, they are actually aspirational values, kind of what they want to be better at, not what they are doing right now. So one of our values is no bullshit. Be honest with each other and ourselves.

That is a key component in building trust, and that’s the biggest one for me. There are the easy kinds of trust, like, do I trust that I can leave my wallet on the desk and it will be there when I get back? Then there are more difficult levels of trust such as:

1) Do I trust your intentions? Do I trust that we are trying to achieve the same thing? 

2) Do I trust your judgment? 

3) Hardest of all – healthy conflict. 

I can say to you: “I feel let down, you didn’t do what you said you were going to do or you didn’t do a good job with that.” I can trust you enough that I can say that, and it’s going to be ok between us. It’s much easier said than done, and though we are fairly multi-cultural sometimes we can be a little bit too English about everything! So we need to be un-English about it, and say what we feel, obviously in a respectable, polite way, to have that trust and transparency.

And that was actually part of why we were quite big in the early days of building the company, not remote first, but having us all together. Not that you can’t build high integrity and high trust remotely, you can, but it is harder.

We were already becoming a remote culture and had a remote office in San Francisco, and we hired people from across the country, like in London.  The first few people you hire will define your culture. As a founder, you have a lot less influence than you thought, culture is a self-defining thing.  With picking the right early hires, we just got really lucky, we had no idea what we were doing. Now we’re in this new world and we hire much more freely regardless of location, and we have the core culture that we can build it on, it actually works really well.

Getting to know you

Vanessa: Have you always wanted to be a developer?

Greg: I wanted to be a train driver! Once I got over that, I got a home computer at the age of ten, my mum sacrificed to get the computer. At first I was just playing games on it (Commodore Plus 4) and she strongly encouraged me to learn and program with it, so I picked up a book to learn, out of guilt really, and from then on I was hooked, all I wanted to do was program. 

Vanessa: Did you go to college and beyond or are you self-taught?

Greg: I took Computer Science at degree and also at A level not many six forms offered that at the time. I realised that it paid well to do something I’m good at. The world developer population is not growing that fast, which is surprising, We need to train more programmers, but we’re always going to have a big undersupply so we need to make that finite pool of programmers as productive as possible.

We need a healthy ecosystem to help people be more productive. Ten years ago, software tools were a brave business to be in. Now it’s one of the hottest places for VC’s to invest in. 

Vanessa: Have you ever been involved in mentorship, either as a mentor or a mentoree?

Greg: We’re all still learning every day, I have mentored. In fact many of our employees are a mentor to me. We’re lucky that there is a healthy ecosystem in Cambridge. It’s amazing really – you can email almost anyone you can think of, even when you’re right at the beginning and they’ll spend a bunch of time with you.

The Future

Greg: Core tooling, slowly they have evolved compilers, IDE’s. Debuggers have not changed much over the years, new tools have come along but the fundamentals have not changed much over the decade

We see waves of tech. There are rapid periods of changes, computer operators were like train operators – if you used a computer for work that’s all you did, and no-one else would be let near them. Then in the 80’s people started using computers as part of their other job, now everyone is using them, and now there are smartphones. As these waves went by, the way we developed changed too – i.e. it goes in waves. Between say 1990 and 2010 the way we develop code was all evolution not revolution. Then suddenly it all changed again, first with agile, then CI/CD, huge amounts of reuse of open source, etc. With these big changes comes an explosion of tooling. It’s really hard to imagine what will continue. I think most of the tools we use today will still be in use in ten years, but they will have been added to. Like how GitHub compliments git, or our stuff does with Jenkins. I’m sceptical on the AI writing code thing – understanding of requirements through context and delivering creative solutions to that – it’s a million miles away from the state of the art. But I do totally see computers helping us to write code – the GitHub Copilot stuff promises to save a bunch of time. But it’s not quite as exciting as it looks because if you think about it, Copilot saves you time typing in the code sure, but what proportion of programming time is actually spent typing the code in? Pretty small. A much larger chunk of time is spent figuring out why that code you typed in this morning doesn’t do what you thought it was going to do! That’s why we started Undo, and I think we’re going to see a lot more around this notion of understanding or auditing exactly what happened.

Collaboration will be key. Asynchronous collaboration. Once you sever the link, you no longer require people to be geographically in the same place, well then you no longer need to be in the same time, either. This has potentially profound implications for how we might work. We have used version control in development for decades which allows people to collaborate remotely and asynchronously; I think these practices have a lot to teach a wider audience in asynchronous collaboration. In kind of the same way that the first word processing applications were actually code editors.

We’re good at writing code, but not at debugging, most devs spend alot of time debugging – remote and asynchronous collaboration through debugging would be great. 

Vanessa: It was great to talk to you Greg!

We love to hear your development stories, get in touch to share yours.


DevOps CI/CD usage trends

To understand DevOps CI/CD usage trends, SlashData has, over the past three and a half years, tracked the usage of continuous integration & delivery (CI/CD) tools and services among mobile, desktop and web developers. While DevOps is technically a culture rather than a set of tools, CI/CD is at the core of the collaboration process between operations and developers. These tools enable some of the most important benefits of the shift to this new culture. As can be seen in the chart below, the majority of developers are not using these tools and usage is not growing. 

While many firms in various studies have indicated that they are adopting DevOps, our data suggests that this shift in culture is not ubiquitous across organisations. Has the use of CI/CD tools reached as many developers as it can or are there certain market barriers?

CI/CD Usage

% of developers using CI/CD tools

DevOps CI/CD usage trends - CI/CD adoption trends by mobile, web and desktop developers

Profile of CI/CD users

Understanding the profile of developers using CI/CD compared to those that are not can provide more insight into why usage is not as high as one might expect. In general, developers who use CI/CD tools are professionals working for companies with larger development teams and are more experienced compared to developers not using CI/CD.

Data from our most recent survey shows that developers that are using CI/CD tools are much more likely to be professional developers than those that are not. Web developers using CI/Cd tools are 20 percentage points more likely to be professional developers compared to developers not using these tools. For mobile and desktop developers this differential is 22 and 18 percentage points respectively.

DevOps CI/CD usage trends - Profile of CI/CD users DE
% of users and non-users of CI/DE who are professional developers

Our most recent survey also shows that 46% of developers using CI/CD tools work for organisations with more than 20 people involved in software development. This compares to only 32% of CI/CD non-users who work for firms with more than 20 developers. The fact that CI/CD users are less likely to work in smaller developer teams points to lower demand at small firms. This may be due to less complex development operations requiring less automation and integration of developer and IT teams.

DevOps CI/CD usage trends - Number of people involved in software development in company

58% of developers using CI/CD tools work for firms with 10 or more people involved in software development

How big are the development operations adopting CI/CD?

Developers who use CI/CD are also more experienced than developers who have not integrated CI/CD into their development process. Of web developers using CI/CD, 44% have six or more years of experience compared to just 28% of developers who are not using CI/CD. For desktop developers, we see the same trend, with 49% of these developers using CI/CD possessing six or more years of experience compared to 34% of developers who are not using CI/CD. Mobile developers using CI/CD are slightly less experienced, but the overall trend holds true, with 49% of developers using CI/CD having three or more years of experience, 17 percentage points more than those not using CI/CD.  

Experience in web development, desktop development and mobile development

As developer operations adopt DevOps culture, to improve the odds of success, developers should have an understanding of the entire development process. This may be easier for more experienced developers to manage. 

While some may struggle, other developers have fully embraced the shift to DevOps and bring a variety of skills to the table and have carved out a role as a DevOps specialist.

The DevOps Specialist

DevOps specialists play an important role in driving DevOps culture and are often evangelists. These practitioners are relatively uncommon with only 5% of developers in our survey identifying as having this job. This lack of evangelists and experts may be an important factor limiting the culture shift throughout an organisation.

Finding professionals with diverse skill sets to occupy these roles may be contributing to the low number of DevOps specialists. One of the keys to successful DevOps implementation is merging of cultures so it is important that professionals driving the process have an understanding of and empathy for how both IT and developers work. 

Developers who identify as a DevOps specialist are a diverse group and indicate that they play additional roles in organisations beyond just DevOps specialist. The majority of survey respondents identify as software developers but DevOps specialists are 8 percentage points more likely to also be a software developer compared to developers who do not identify as a DevOps specialist.

DevOps specialists are also much more likely to be architects, administrators (both data and system), engineers and testers. These skills play an important role in the implementation of DevOps. Architects are needed to automate processes, administrators are required to manage release schedules and testers and QA engineers are needed to test software as it moves through each step of the iterative development process.

What else do DevOps specialists do?

DevOps CI/CD usage trends - What else do DevOps specialists do? % of DevOps specialists in other roles vs developers that are not DevOps specialists

Digging deeper into the DevOps specialist’s skill sets we can also observe that many have more than one role beyond DevOps specialist. From the table below we can see how these developers describe themselves and how their roles overlap. Twenty-three per cent of DevOps specialists are both programmers and system administrators and 27% are programmers and architects. Having development skills and an understanding of how to manage and design systems are an important combination of skills for leading a DevOps strategy. 

DevOps specialists’ additional roles

DevOps specialists' additional roles

While DevOps is a very popular strategy already adopted by many organisations, based on the number of developers using CI/CD tools, not all developers are buying in. The DevOps culture has been slower in reaching less experienced developers and ones at smaller firms. The need for more experienced professionals with diverse skills may be a barrier to more developers benefiting from DevOps tools such as CI/CD. 

If you are interested in learning more, here is some additional reading.You can voice your opinion in our current survey to shape the next State of the Developer Nation report and contribute to future DevOps CI/CD usage trends.


[Infographic] The latest trends on developer tools, skills and salaries.

We recently announced the  State of the Developer Nation Q1 2017 report which is based on the 12th edition Developer Economics survey, which took a 360° on developer tools, skills and salaries. The report sheds light on current developer trends based on responses from over 21,200 developers globally, across multiple research areas including Cloud, Mobile, IoT, Desktop, Web, Augmented & Virtual Reality, and Machine Learning.

For the first time in the history of Developer Economics, VisionMobile asked developers how much they earn in salaries and contractor fees, to explore what projects and types of development are more lucrative around different locations. What’s more, the report uncovers how technology battles continue on the web front with Angular vs React Javascript, Amazon Web Services is in a price war with their public cloud competitors, the IoT market is underdeveloped and highly fragmented, and Machine Learning developers are striving to identify what is the ideal programming language to use.

Check out our infographic on some of the many interesting  insights from  the State of the Developer Nation Q1 2017 report.

Developer trends 2017- Infographic

VisionMobile is very lucky to be supported by the entire developer community: from the largest Internet and software companies to the smallest local Meetups. Partnering  with these organisations, big and small, ensures that there is a representative sample across all developers so that something valuable is delivered  back to the community. The following are the top contributing communities for  the State of the Developer Nation Q1 2017: Amazon, SitePoint, Outsystems, 51CTO, Microsoft, Intel, The Linux Foundation, Android Weekly, InMobi, SellMyApp and Ubuntu.

The full report with more insights and graphs is available for download here.

We are currently running our new survey and it is sci-fi themed! Would you like to contribute ? Take the survey 

Platforms Tools

[ Infographic ] The State of the Developer Nation Survey – Tools & Technologies featured

The State of the Developer Nation Survey (H2 2016) was by far the largest in participation. The best way to illustrate this is by an infographic, highlighting important facts and figures. Further down you  will be able to find out the total number of respondents and the countries of their origin as well as all the development areas covered and the  number of tools featured per development area.

Clicking  on the Infographic will redirect you to the full list of tools falling under 7 different development areas namely: Desktop, Mobile, Web, IoT, Cloud, AR/VR and Machine Learning. In total there are 21 categories under all development areas which amount to a total of 226 tools.




Agile tools for the Samurai Coder

This post is not meant to help you understand agile methodologies. A simple Google search will be enough to reveal tons of posts presenting, explaining, analyzing and suggesting how to make agile methodologies work to your advantage. And we have to keep in mind that they all usually apply to teams of 3 or more people. This post is about the freelance developer who just needs a simple way to manage tasks and projects. I do not claim that I present the absolute and irrefutable Truth; every person has their own way of working. This post simply intents to be a starting point to another way of doing things.

Meet Sally. Sally is a developer, a Samurai Coder, a hero of the day and she absolutely loves writing code. She works as a freelancer and the other day she got a new project from a customer.

Before starting work, she picks up a piece of paper. She writes down the day’s tasks (to-do’s, appointments, ideas etc) and crosses off the completed ones. She repeats the same process every day. These sheets of paper pile up and follow her everywhere… until she finds Evernote. Evernote replaces the paper and uploads her notes to the cloud, but still…. The notes multiply just as much and just as quickly as the papers do. They only stop creating piles on her desk.

Sally is desperately in need of solution – a way to capture and track her customer’s numerous requests as well as the 100+ things she has to do. What about a bit of agility and organization? How about combining simple methods and tools to get things done? Sally gave it a thought and found out the 5 most important things to her:

  1. Ability to separate projects and tasks.
  2. Clean visual overview, i.e. understand what needs to be done, watch the progress or the big picture, and prioritize accordingly.
  3. Sharing and Collaboration features.
  4. Accessibility, i.e. ability to retreat her work through any device in real time.
  5. Speed, i.e. Sally’s work is programming, not using tools. Tools should work for her, helping her save time, and not the other way around.

The simple process

  1. Here’s a really simple and basic five step-process that Sally could follow. This kind of flow is Kanban-like (but I will talk more about Kanban on another post).
  2. Create a repository for every project.
  3. Separate it virtually in 3 areas: to “To Do”, “Doing” and “Done”.
  4. Add new tasks, requests or bugs in the “To Do” area.
  5. While working on a task, move it from “To Do” to “Doing”.
  6. Move the task to “Done” when completed.


The tools

There is a great variety of software tools in the web; tools for small teams, big teams, distributed teams… But how about one single person? We will see how Sally can follow this process with the use of 3 simple tools: a) Trello, b) Asana and c) Wunderlist

a) Trello

Trello’s visual layout is very intuitive. Imagine a dynamic whiteboard with columns (lists) and cards (like advanced sticky notes).
How to use it:

  1. Create Project with the use of Trello Boards: Each Trello board represents a project. Add lists (columns) to simulate progress. Add cards as tasks. And that’s all…
  2. Managing Tasks: A new Board has by default three basic columns: “To Do”, “Doing” and “Done”. You can drag a card over these columns anyway you like and you can always visually track both the card and its status.
  3. Handling of requests or bugs: Trello has a color mapping that you can apply on the cards (e.g. red color for bugs). You may add lists, comments and much more.


b) Asana

Asana is an advanced task list oriented application with an equally intuitive visual layout to Trello. It is fast, easy to use and quite popular.
How to use it:

  1. Create Project with the use of Asana Projects: Start a new project and add tasks in the center column.
  2. Managing Tasks: Tasks added in the center column get a level of hierarchy and may be stacked. You can start by creating the three high level tasks “To Do”, “Doing” and “Done” and then fill them with specific tasks accordingly. You can easily create a task, drag it to move and edit its details on your right hand side (add sub lists, comments and more). There is a checkbox in front of every task and may be checked if the task is completed. By doing so the task is removed from sight but if you prefer you can manually drag it bellow “Done”.


c) Wunderlist

Wunderlist is a pure task list oriented application, though their newest update has many improvements including Collaboration and Public Lists. It has a clean UI and is much simpler than Asana, quite fast and user friendly.
How to use it:

  1. Create Project with the use of Lists. Add a new list and add tasks in the main column. Just like a true boss…
  2. Managing Tasks: Add tasks in one column. In order to create some kind of flow for your tasks, create more lists (see the example in the pic below). Wunderlist is quite easy to use, but not as advanced as other tools, i.e. missing collaboration features, ability to assign subtasks, etc.


All of the above tools are equally fast, have the ability to collaborate (add more people to your list/project) and can sync to other available devices.

Quick Verdict:



+ Nice visual and collaboration.


– No task sub lists (there is a great checklist feature, but there is a minor problem: you cannot assign tasks to these lists. As a result you need to create separate cards).


– The visual style with the cards may overcrowd the board making it look messy.




+ Nice interface, quick.


– Not a nice “big picture” or “flow” visibility




+ Nice simplistic UI, powerful task list.


– Missing advanced features the other tools offer.


+ Their recent update added collaboration features.


Sally in our story has therefore many great tools in her disposal. All she has to do is put her pen and paper aside and work easier and faster. And you can all join her!


HTML5 performance is fine, what we are missing is tools

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools?


In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).


We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.

Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.

Experts point to a tools gap

As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).

It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.

Ran Ben Aharon, head of front-end development of, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”.

Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?

HTML5 is like a car without a dashboard

[tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.

With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.

Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.

Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.

Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.

Better tools are needed

HTML5, as far as performance is concerned, is adequate for most use cases. And tools like and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.

With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.

Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.

What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.