All posts by bolarotibi

The Future of Programming May Not Involve Coding (Part 2)

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 2 in a 2 part series: Read Part 1 Here

Developers: I’m better than you and I need my code

The most significant barrier to adoption has perhaps been the developer. Within the development community there can be a snobbery about writing code. A hierarchy of developers often exists in which those who are closest to the metal are better developers. So a C++ developer is far superior to a JavaScript developer. Therefore a developer who writes no code at all is perhaps not even a developer. Aside from this unofficial cast system there has always been a desire amongst developers to write code. Becoming a developer to not write code is like choosing to be a racing driver and not driving a car.

Finally there is the niggling suspicion within the minds of developers for whom the low-code approach might be appealing is that a requirement will come along that cannot be fulfilled. If you are writing the code then this is highly unlikely to happen, any requirement can be met. This has been true in some cases such as the early days of .NET when developers discovered that something which was possible pre-.NET was not possible within the framework. Anyone who remembers the challenge of needing more than one form in an ASP.NET page will know what I mean.

These issues, in many cases more emotional than real, have managed to drown out the many sensible reasons for adopting low-code development tools. Had software development been any other part of a business it probably would have shifted to this approach many years ago as the business case for it is overwhelming. But, within IT the old guard of developers has stemmed the tide and most development today, especially within the enterprise, still means many, many lines of code being written, tested, deployed and maintained.

The rise of a new breed of developer

Just as technology has changed so has the developer. The 2015 Stack Overflow survey found that the average developer does not have a computer science degree (almost half are self-taught) and has only been coding for 2-5 years. They are a product of the micro-service, API, framework, born-on-the-web world. These are not the Fortran or Mainframe or even Visual Basic guys of old. The most popular language in the survey was JavaScript with C#, PHP and Python beating out C++ and C. The main driver for this generation is speed and technology choices largely flow from that.

This is highlighted by many of the new coding bootcamps that have sprung up. These are very short training courses in which people with usually zero coding experience learn how to develop in a few weeks. In order to operate in these timescales they choose technologies such as Ruby on Rails or Node.js simply because the more traditional technologies take longer to teach.

Then there are the micro-service based applications often built on Platform as a Service such as Heroku or Cloud Foundry. These are also popular with the bootcamps because even quite complex applications can just be a few lines of code that knit together a few services. In this world some developers do not even see themselves as developers but merely curators of services. For them the issue of whether they are a “real” developer is irrelevant. Their aim is to create an application as quickly as possible. They would rather invest time in making it a great user experience.

The applications that this generation have been creating are those that have disrupted many traditional industries or notably impacted society in recent years: Facebook, Netflix, Twitter, Dropbox and so on. The result is that now traditional enterprises and SME’s are having to respond in kind. Innovation, agility and time to value are the buzz words in today’s business with respect to IT. Developers are having to change and that includes languages, technologies and tools. We see this reflected in the products that their traditional vendors are producing such as Microsoft and IBM’s PaaS platforms.

The future demands change

Then there is the challenge of mobile and Internet of Things. Whereas for a long time developers just had to worry about building a desktop application (often for a very specific OS) they now have to worry about the web, phones, tablets and potentially many other types of device. Codebases need to be able to serve many different clients. If every line of code is going to be written by hand then building an application that works on desktop, multiple phones and tablets and beyond is going to mean a lot of lines of code across numerous languages, technologies and tools. All of which must be tested, maintained and evolved.

This will push developers, development teams and budgets to their limits. And with speed being an overriding factor the old ways simply won’t work. Coding and creation of applications is opening up to a wider group. The advent of the citizen developer: regular folks building mobile apps in their spare time; or people at work building apps to aid their productivity; the iOS Gold Rush saw many designers begin writing Objective-C in order to push out iPhone apps. Everyone is getting in on the act and they are not playing by the old rules or caring about the developer hierarchy.

This evolution began with the web when many people (such as myself) who had no development background or training became developers at the forefront of technology. That change has accelerated and continues to do so. This is being enabled by and driving the growth in low-code tools and technologies. As I said in the beginning, it is ironic that as governments push for the better training of software coding within the younger generation, the need to actually write code is rapidly diminishing.

Many software application developers should look willingly to embrace this evolution not least because of the act of development is to build to deliver value. Code is a construction asset like bricks are in the building trade. In the building trade, ultimate value comes from the finished product and the way it is architected and the function it delivers. Of course the quality of the bricks also helps to cement that value but at the end of the day it is a commodity component. The analogy works for the business of programming with many tools now are able to auto generate the building block code to a consistent standard and quality: i.e. a commoditised function.  Full and lasting value must surely then lie not in the construction of code but in the application that is devised and the way it is architected or modelled to deliver the function required. The resulting experience of engagement for the user is intrinsically tied to the value perceived and this is rooted more in the application model and architecture than the underlying code.

The Future of Programming May Not Involve Coding

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 1 in a 2 part series

It is perhaps ironic that we live in a time when governments and many others are calling for young people to be better educated with regards to writing code, yet at the same time the software development industry is requiring developers to write less code. Microsoft’s Azure App Service or Salesforce.com’s Lightning are recent examples of new tools that aim to eliminate code writing from the process of developing an application (desktop or mobile).

The principle of this approach is not new and tools such as Uniface have long aimed to increase developer productivity and application quality by reducing the number of lines of code that need to be written. The terminology, approach and experiences have evolved and differ but the aim has remained the same.

Even in the world of code writing the popularity and growth in frameworks from .NET to JQuery have sought to reduce the amount of code written. As has tooling like Integrated Development Environments such as Visual Studio and Eclipse. For example, tools provide drag and drop controls with properties windows that mean a developer can add a control to a screen or web page without writing the underlying code. We saw this in Visual Studio, Adobe FlexBuilder and others. Perhaps the question is why it has taken so long for low-code development environments to see wider adoption?

Making the complex simple is a challenge for tooling

Part of the reason may be technology. It is inherently difficult to make the complex process of writing applications into something that can be done in a way that involves no or little code. Modern applications are incredibly complex, often using multi-tier architectures and integrated with other applications. Creating a visual development experience that can work with these complexities and provide the myriad possibilities that the modern developer requires is inherently challenging. Changes in technology have made it easier in recent years.

The wide spread adoption of the API economy and the proliferation of micro-services has changed application architectures and exposed capabilities in more simplistic and easy to consume ways. Let’s take a rather modern concept such as mobile Push notifications. Each mobile platform (iOS, Android and Windows Phone) implements this capability differently and it involves a degree of complexity and quite a bit of code to manually create. Instead there are a number of services exposed as APIs (Web Services) that abstract all of this complexity and allow developers access to the capability via a few simple calls.

By basing these APIs on common programming concepts such as RESTful Web Services and JSON formatted data it allows development tools to more easily create a further level of abstraction that means developers do not need to write the few lines of code required to work with them. SOAP made consuming any service from within a development tool even easier as the WSDL allowed tooling to auto introspect and understand any service. REST is not as simple but is now widely accepted as the way to build modern services. Modern tools are finding ways to make working with RESTful services very simple.

Part 2 (coming soon):  Developers: I’m better than you and I need my code

When thinking Desktop “first” still matters (Part 2)

By Clive Howard, Principal AnalystCreative Intellect Consulting

Read Part 1 Here

Great experiences are not just for mobile

In an era of high user expectation and the demand for great user engagement, Application User Interface (UI) design has never been so important. We’ve heard this message before of course, when the virtues of Web 2.0 and Rich Internet Application were espoused in the mid 2000’s and browser based applications along with the proliferation of smartphones, tablets and mobile apps cemented that reality.  Many organisations have now caught up and are starting to realise that users demand more usable experiences and providing them can have productivity benefits. The results can often be seen on a business’s bottom line or through competitive advantage. I worked on a call centre application where improvements to the User Experience (UX) dramatically reduced call times and improved the quality of data collected. This led to efficiency within the call centre and improved outcomes for both the business and the customer. Costs were reduced and customer satisfaction rose.

In a desktop first world designers will still need to provide users with great UX. At the same time they need to appreciate the potential for different end user form factors. Application interfaces will need to adapt to alternate screen sizes. The modern desktop could be a traditional 20 inch monitor or a 10 inch touch screen. Where the desktop application spawns mobile apps they will need to have consistency with the desktop experience. A user should be able to move from desktop to tablet to mobile very easily because the app experience is familiar to them. This is best achieved if the original design considers the possibility of mobile from the beginning.

Plan for a “multi endpoint first” future

For all of those development professionals out there who have spent their careers building desktop applications their future should be secure. But they will need to adapt their skills, thinking,  tools and possibly their processes to a new world in which mobile may not always be first but will be relevant. Many desktop applications will remain installs but many others will be delivered via a web browser. Equally for the IT decision makers they need to think about investments that are not just about mobile. It is very easy in the current climate to think that the future is mobile and therefore investing in mobile only platforms is the way to go.

Instead they need to consider that the desktop is going to be around for a while and they need to invest in platforms, tools and skills that will support a broad portfolio of applications. Essentially this comes down to being efficient with the code base. Not replicating code should always be a core aim. Creating code that can be tested at all levels of the stack should be a further key ambition; making the functions of that code base available through services to multiple end points should be another. With a services based architecture, the application may be spread across both the company data centre and public cloud environments.

Where development moves to being Agile, development will need to work with Operations in order to speed application changes into production. This will most likely mean embracing a DevOps culture, processes and tools. The modern desktop app will require more regular updates than the old fashioned quarterly release.

There will certainly be many situations where a mobile first approach will make sense in future. Studies show that people are accessing the internet more from mobile than desktop and so for websites mobile first will probably be a good idea in the majority of cases. However, the future will be a combination of mobile, tablet and desktop experiences. Developers and organisations will therefore need to consider each application and in some cases it will make sense to go desktop first.

When thinking Desktop “first” still matters

By Clive Howard, Principal AnalystCreative Intellect Consulting

A few months back, I registered for Mobile World Congress 2015 in Barcelona. As an Analyst, there is a different registration process to the one used for regular attendees. This is so the organisers can validate that someone is a legitimate industry analyst. As well as entering a significant amount of personal data, additional information such as links to published work and document uploads are also required. Crucially, there are a number of screens to complete the registration and accreditation process. But more to the point, many different types of data must be entered – from single and multiple line text entry to file uploads. Some data (such as hyperlinks) requires cut and pasting.

I’m sure that I could have done this using a mobile phone but it would have taken a long time, been awkward and irritating and probably highly prone to mistakes. In short, I would never have considered doing something like this using my phone. Could I have used a tablet? Without a keyboard and mouse it would have been problematic, especially if the screen is small. Using a tablet only Operating System might also have had its problems in places: such as uploading documents from centrally managed systems. Actually I did use a tablet but one connected to a 20inch monitor, keyboard and mouse and running Windows. In that traditional desktop looking environment the process was relatively quick and painless.

Rumours of the desktop’s demise are greatly exaggerated

It is not just complex data entry scenarios such as this that challenge mobile devices. Increasingly I see people attach keyboards to their tablets and even phones. Once one moves beyond writing a Tweet or one line email many mobile devices start to become a pain to use. The reality of our lives, especially at work, is that we often have to enter data into complex processes. Mobile can be an excellent complement, but not a replacement. This is why we see so many mobile business apps providing only a tiny subset of functionality found in the desktop alternative; or they are apps that extend desktop application capabilities rather than replicate or replace them.

One vendor known for their mobile first mantra recently showed off a preview version for one of its best known applications. This upgrade has been redesigned from the ground up. When I asked if it worked on mobile the answer was no, they added (quite rightly) no one is going to use this application on a mobile device. These situations made me think about how over the last couple of years we have heard relentlessly about designing “mobile first”. As developers we should build for mobile and then expand out to the desktop. The clear implication has been that the desktop’s days are over.

This is very far from the truth. Not only will people continue to support the vast number of legacy desktop applications but will definitely be building new ones. Essentially, there will continue to be applications that are inherently “desktop first”. This statement should not be taken to mean that desktop application development remains business as usual. A new desktop application may still spawn mobile apps and need to support multiple operating systems and form factors. It may even need to engage in the Internet of Things.

The days of building just for the desktop safe in the knowledge that all users will be running the same PC environment (down to the keyboard style and monitor size) are gone in many if not the majority of cases. Remember that a desktop application may still be a browser based application, but one that works best on a desktop. And with the growth of devices such as hybrid laptop/tablet combinations, a desktop application could still have to work on a smaller screen that has touch capabilities.

It’s the desktop, but not as we know it

This means that architects, developers and designers need to modernise. Architects will need to design modern Service Orientated Architectures (SOA) that both expose and consume APIs (Application Programming Interfaces). SOA has been around for some time but has become more complex in recent years. For many years it meant creating a layer of SOAP (Simple Object Access Protocol) Web Services that your in-house development teams would consume. Now it is likely to mean RESTful services utilising JSON (JavaScript Object Notation) formatted data and potentially being consumed by developers outside of your organisation. API management, security, discovery, introspection and versioning will all be critical considerations.

Developers will equally need to become familiar with working against web services APIs instead of the more traditional approach where application code talked directly to a database. They will also need to be able to create APIs for others to consume. Pulling applications together from a disparate collection of micro services (some hosted in the cloud) will become de rigueur. If they do not have skills that span different development platforms then they will at least need to have an appreciation for them. One of the problems with mobile development inside enterprise has been developers building SOAP Web Services without knowing how difficult these have been to consume from iOS apps. Different developers communities will need to engage with one another far more than they have done in the past.

Those who work with the data layer will not be spared change. Big Data will affect the way in which some data is stored, managed and queried, while NoSQL data stores will become more commonplace. The burden placed on data stores by major increases in the levels of access caused by having more requests coming from more places will require highly optimised data access operations. The difference between data that is accessed a lot for read-only purposes and data which needs to be changed will be highly significant. We are seeing this with banking apps where certain data such as a customer’s balance will be handled differently compared to data involved in transactions. Data caching, perhaps in the cloud, is a popular mechanism for handling the read-only data.

Continuation of the Testing challenge

Testing will need to take into account the new architecture, design paradigms and potential end user scenarios. Test methodologies and tools will need to adapt and change to do this. The application stack is becoming increasingly complex. A time delay experienced within the application UI may be the result of a micro service deep in the system’s backend. Testing therefore needs to cover the whole stack – a long time challenge for many tools out there on the market – and the architects and developers will need to make sure that failures in third party services are managed gracefully. One major vendor had a significant outage of a new Cloud product within the first few days of launch due to a dependency on a third party service and they had not accounted for failure.

There may be trouble ahead for mobile commerce; Part 2

By Clive Howard, Principal AnalystCreative Intellect Consulting

Read Part 1 of this blog post here

Payments made easier and more secure with a good mobile wallet

Once again the most likely solution to this issue is mobile wallets. By using a mobile wallet the customer does not have to enter any payment information. This greatly reduces the work that they have to do to make a payment. The customer is simply passed into the mobile wallet which already has their payment information, they complete the transaction and are then handed back to the website or app.

A further benefit to this approach is that the actual payment element of the process has been both optimised by a third party payments specialist and tested by them as well. This removes two major burdens from the development team.

Mobile wallets are therefore the answer to the two top reasons why consumers are reluctant to make payments on a mobile device. If this mobile wallet is provided by a bank or credit card provider then people are more likely to try it. This should be good news for any organisation looking to increase revenue from mobile consumers. Especially when one considers that eMarketer has found that there is a desire to buy via mobile, particularly in the younger age groups. 48% of 18-34 year olds said that they would like to pay this way.

Mobile payments present new opportunities

Within the many different markets with an interest in mobile commerce one of particular note would be travel and transportation. This market has been working with different ways to incorporate mobile into a customer’s experience across the end to end lifespan of a journey. An example is the number of airlines that now offer mobile boarding passes. A further example would be the use of the mobile device as a ticket using NFC such as on buses. With many journeys having multiple stages that may involve different modes of transport from a variety of providers a single form of fast payment is obviously interesting.

Imagine taking a journey and being able to both use the mobile device for payment and as a ticket to travel throughout. This is not just in the context of transport itself (trains, buses, aeroplanes and so on) but other stages of the journey like paying for car parking, hotel accommodation or purchasing refreshments.

There are a number of challenges to this vision of the future. Many of them are physical and cost based such as the price of installing NFC enabled equipment into the transport network. However it will still require customers to want to use their mobile and that means addressing the concerns of security and user experience that have already been discussed.

What this brief look at a particular industry does however, is to highlight the new possibilities that mobile presents in the field of payments. For many organisations it may simply be that they want to take a traditional sales process and mobile enable it, such as purchasing an item of clothing from a retailer’s website. For others though it might present all new customer experiences and revenue opportunities.

Developers: be armed with the right approach

What we see in the m-commerce market is a history of solid growth and desire amongst consumers to buy via mobile. But we also see challenges ahead in the form of security concerns and the poor experience that many customers are currently receiving. Mobile wallets address these concerns and customers are prepared to try them as long as they are provided by organisations that they trust such as banks and credit card companies.

Development teams working on mobile projects, whether websites or apps, should begin looking into how they can integrate with mobile wallets. Coupled with the importance of having in place a good mobile wallet strategy, is the support of a robust testing strategy. This will mean looking for accessible tools and services that can address any performance challenges that might present themselves as a result of network traffic. The latter will be one for future blog discussions.

Crucially, the potential for m-commerce goes beyond the type of retail experiences that many of us are used to but it is one that opens up a future of new possibilities as well. So, while there may be trouble ahead for Mobile commerce in the future, there are strategies and tools in play today to enable you to buck the trend going forward.