Credits: Appdevelopermagazine

Credits: Appdevelopermagazine

Application developers are increasingly reliant on open source component parts because pre-fabricated components speed up innovation and save developers the time (and money) of having to write code from scratch.

But with 6.1% of component downloads containing a known security vulnerability it’s inevitable that defective parts will make their way into production – especially with component management practices lagging. Up until recently it’s been difficult for organizations to fully grasp the enormity of what it means to have to work backwards to fix the use of defective, outdated, and risky components in applications.

We sat with Derek Weeks, VP and DevOps Advocate at Sonatype to chat about the prevalence of defective components in the software supply chain and applications, how the cost of rework and bug fixes negatively impact innovation, and what companies can do about it.

ADM: What is a software supply chain?

Software supply chains are just like supply chains in other manufacturing entities used around the world. A typical supply chain has buyers who build parts and make those available to manufacturers through a number of distribution channels. Those manufacturers get those parts and use them to assemble finished goods that they then sell to their customers. In software supply chains, the parallels are very common to traditional supply chains but the suppliers are open source projects that create open source and third-party components. Those components are then made available on the internet through large public warehouses of open source components.

Any software development team around the world that is manufacturing software using these parts as building blocks to assemble their own applications can freely access these warehouses. These components are then assembled through the software development teams into finished goods, which are software applications that all of us either rely on for services or as end products that we’re purchasing.

ADM: Why is software no longer written from scratch?

I think a lot of people who are not familiar with how development has changed in the last decade believe that software is built from scratch, and that there are developers out there who code every single line within an application.

In reality, use of open source and third-party components over the past 10 years has become a commonplace development practice. Developers are sharing their best code by packaging it up into components for other developers to reuse. So, rather than write my own logging framework, web application framework, or encryption functions for an application, I can actually go to the internet and source those for free from developer’s open source projects that have supplied the parts. What this means is that as a developer I don’t need to write from scratch anymore and I can accelerate the pace of developing new applications. The proliferation of open source has added a tremendous new velocity to software development practices around the globe.

ADM: How many open source components are being consumed, and are all parts created equal?

Open source components are being consumed at almost unimaginable volumes today. In the Java realm of software development last year, we saw more than 31 billion download requests happen across a global population of about 10 million Java developers. While Java developers are consuming billions of these component parts, component use is not limited to Java development alone. There are different component formats for different development languages – component formats like npm for JavaScript, NuGet for .NET developers, PyPI packages for Python developers, etc.

Within these billions of components, one of the secrets out there is that not all of these parts are created equal. There are millions of parts available to developers. Of those millions, versions could be as young as one day or as old as 11 years. The average open source project releases about 14 new versions of their component parts per year. Some of those new releases are to make the components higher performing, less buggy, more functional, or more secure.

Last year in the research that we did,we saw that more than six percent of the components that were being downloaded had a known security vulnerability. Across billions of downloads, about 1 in 16 components had a known security defect on the day they were downloaded.

ADM: How are organizations vetting the quality and security of components in their software supply chains today?

The evolution of software development requires the need for more DevOps-native tools that allow developers to automatically evaluate millions of components. An example I like to use is that of a big healthcare company with 2,000 software developers, that’s consuming 16million parts annually. There’s only one person employed at that business to assess whether those parts are good or not, and that person only looks at the software licenses of those components. That one person doesn’t look at the version, how old the components are, or any known security defects. Additionally, that one person alone cannot keep up with annually auditing the 16 million parts being consumed by their developers.

The day-to-day reality inside that organization is that the person in charge of approving components is busy 100%of the time. Even if they could employ 100 more people in that role, the organization could not keep pace by manually evaluating what they are consuming.

ADM: Are existing practices to identify and track defects in open source components keeping pace with development?

The existing practices in the industry today are really more manual than automated and when manual practices are in place, those practices cannot keep up with the volume of activity that is happening across the industry. An average organization consumes about 225,000 components a year in the manufacturing or development of its software applications. For an organization to try and evaluate every one of those components and determine whether it is good or has a known defect is very difficult and time-consuming.

In fact, the volume of consumption has out-paced manual approaches to evaluation and governance of these components for probably six or eight years now. Many companies have chosen to approach automated ways to identify, track and trade, and set policies for which components are acceptable to use in their organization and which are not.

For example, a company I know in the financial services industry has a governance practice in place around defining which components their developers can use. They told me that they had more than 800 components approved across their application development portfolio. However, when we worked with them to analyze how many components were actually used in their portfolio, they found that developers were actively using 13,000 different open-source and third party components.

ADM: Can you share an example of where open source governance practices are not keeping pace?

Part of the discrepancy between the number of components that were approved (800) and the number that were actually in use (13,000) had to do with the approval or governance process that was in place. What developers wanted to immediately know was which components were safe or unsafe to use, or which fit or did not fit with the company’s policy. As a result they were forced to wait anywhere from two to nine weeks for a response from the governance body within their company. When developers want an instant decision and don’t get one they will find a workaround. This workaround led to more than 12,000 components being actively used in development, skirting the approval process.

This workaround led to lower-quality components being used actively throughout the development organization, and that’s something that they’re now asserting more control over while allowing their developers to use the highest-quality components permissible from open-source projects worldwide.

ADM: What lessons can we learn from traditional manufacturing to improve how software is developed?

There are lessons from traditional manufacturing practices, especially high velocity, high volume manufacturing that can be applied to software. Many of these lessons originate from those learned at Toyota through Deming and other manufacturing thought leaders. The key practices that I’ve seen employed through a number of organizations relate to relying on the fewest and highest quality suppliers. The leading organizations are also tracking and tracing use of components across their software supply chains; in a situation where any of them are discovered to be defective, you can immediately locate those components and begin to quickly remediate them within the organization.

In the 2016 State of the Software Supply Chain report, one of the common practices that we saw being applied from traditional manufacturing into software development was the use of a software Bill of Materials. We highlighted how organizations like Exxon and the Mayo Clinic were using a software bill of materials to identify what components they were using in the applications they were developing in-house, as well as applications that they were purchasing from other development organizations. They were using these software bill of materials to determine what component parts were used in those applications because they wanted to understand if any of them had a known defect — and in particular did they have any known security defect.

ADM: If open source software components have so many defects, should we stop using them?

Most organizations that hear how many open source and third-party components they’re consuming and also understand the defect rates, have an initial reaction of believing they need to stop using these components. They get scared and feel that they can’t allow that volume of risk to come into their organization.

However, the reality is software development practices rely so much on these components that most organizations that would make the decision to stop using components would simply have to stop developing software. The use of components has proliferated so much it’s nearly impossible to stop the consumption.

Given that scenario, it’s important that we learn to manage software supply chains, just as other manufacturing organizations have learned to manage their supply chains. Organizations can do this in a high volume, high velocity environment while maintaining quality. If we think about manufacturing organizations around the world, like an Apple, a Ford Motor Company or a Pfizer…they are using a huge number of parts to assemble or produce the goods that they are then delivering to customers.

These companies have figured out how to work with their suppliers and their supply chains to vet the components before they come in the door. They use the highest quality and latest versions of parts in there in order to deliver the best products to their customers. By managing these supply chains they’ve proven they can reduce the cost of producing goods by using the highest quality parts.

ADM: Have organizations quantified the value of better managing their software supply chains?

Absolutely. We have worked with a variety of different organizations that have utilized DevOps-native tools to reduce the number of defective components they use. This has been done by using high quality components and reducing the variety of components across their software supply chain. We’ve seen organizations not only increase or improve the quality of their software application by as much as 50 or 60 percent, but we’ve also seen them improve the productivity of their development organization by as much as 30 to 40 percent in the same time frame.

Organizations can see the same type of results by using the highest quality parts from the start, and as a result those development organizations spend less time and work fixing these defects that may be caught later in the software development lifecycle or even out in production environments.

Organizations that choose to manage their software supply chain from the earliest stages and bring in the highest quality parts can reduce the amount of time, effort, and money that they’re spending to remediate these defects. They then can apply that money towards their innovation budget to continue to differentiate their businesses and make them more competitive.

Credits: Computerweekly

Credits: Computerweekly


Software development practices in the enterprise have traditionally focused on delivery high-quality code built on proven platforms. But the web and the emergence of apps, built on web scale infrastructure, are rewriting the rulebook.

In fact, businesses struggle to compete with startups that can somehow maximise the value of the new economy, and are able to undermine traditional business models.

“Over the past 20 years, IT has been set up for efficiency, cost reduction and doing things as safely as possible,” says Benjamin Wootton, co-founder of Contino.

He says companies are now driven by the need to work faster and are becoming more agile in order to improve the customer experience.

“This is applying pressure on IT and how we develop software,” he says.

Whereas IT heads previously implemented heavyweight internal IT processes and used outsourcing to reduce cost and maintain quality, in Wootton’s experience, this style of running IT slowed down IT departments. “DevOps and continuous delivery allow organisations to operate faster, which is what enterprises want to do today,” he says.

But Wootton argues that among the challenges for IT leaders is the fact that big enterprises are risk adverse and tend to stick with a tried and trusted formula, often contrary to contemporary best practices.

Shifting the enterprise mindset

Kingsley Davis, a partner at Underscore Consulting, adds: “You want to deliver quickly and at pace, which means having a clear strategy about what things are not important for the product.”

Technology such as Docker, to enable developers to create code that can run in their own containers, along with the ability to have short feedback loops, helps businesses to adapt more quickly. Such technology and techniques form the basis of the cultural shift that companies of all sizes need to make to enable their developer teams to become more adept at delivering software quickly, says Davis.

“Culture is very easy to instil when there is a small group of people,” he says. “Hiring is key.”

Davis recommends that IT leaders plan in advance, and hire people appropriate to the direction the IT strategy is taking.

Russ Miles, lead engineer at Atomist, believes IT leaders can learn much from the way webscale organisations approach software development. “Organisations of any size have to compete,” he says.

The speed of change is such that IT leaders cannot afford not to adapt their business processes. “People look at what Netflix is doing and the thing to take away is that agile software development will only get you so far,” says Miles. “The software itself needs to be as adaptable as the process.”

What this boils down to, says Miles, is that IT leaders need to figure out how to adapt systems and the work IT departments need to do, to achieve the speed and flexibility required by the business.

A case for smarter analytics

If they cannot meet the needs of the business, business users will go elsewhere, or even develop the systems themselves.

“Business users are driving software development,” says Frank Ketelaars, big data technical leader for Europe at IBM. This is a form of shadow IT, he adds. “They use spreadsheet data warehouses as their own analytics platform.”

Given the need for developers to be productive and create applications quickly, Ketelaars says technologies such as Apache Spark make it possiblefor businesses to develop machine learning capabilities more easily than before.

Also, the availability of deep learning services is pushing the boundaries of analytics in terms of the massive computational intelligence such algorithms can bring to bear on hard-to-solve problems. But with such technological developments comes new challenges.

Ketelaars says the plethora of analytics tools available makes it hard to validate data models. “It is extremely difficult working with the variety of analytics libraries and tools that are available,” he says.

What developers need, says Ketelaars, is a route to analytics services via a common programming interface, giving them the features of an analytics tool within their own applications.

Another challenge facing analytics applications is how to make sense of the data. “Deep learning is here, but one thing that is missing is context,” says Ketelaars. “If I have a picture with two people running after each other, and one has a frisbee, I know this image is about playing.”

Deep learning algorithms can instantly recognise the image of two people running, he says, but adds: “The context changes dramatically if one of them has a chainsaw. This is where context controls what you should do with the image.”

For Ketelaars, understanding context will be a key requirement in applications, to understand the meaning behind the analytics. “You have to start thinking about what data you have to control the behaviour of your application,” he says.

Essentially, applications become smarter, providing users with the information they need based on a deep contextual understanding of what it deems relevant or important.

Improving tooling

Arguably, there is room for improvement among the array of tools, building blocks and techniques that developers use to create software, says Phil Trelford, founding member of #F Foundation. “A general-purpose programming language is a bit like a spanner and we are all trying to build large systems with spanners,” he says. “What I would like to see is precision tools.”

In fact Trelford goes further, saying the industry needs better “meta tools”, in other words software tools to help the developers of programming tools build precision instruments, rather than generic spanners.

While, as the saying goes, “a bad workman blame his tools”, software developers are keen to see improvements in the tooling they use. In part, this helps them cope with the added complexities when coding and operations become one, as in DevOps, says Trelford.

“Personally, I would like to be able to say, ‘I need to make this thing happen’, then make it as quickly as possible,” says Miles. But today, developers need to draw together a lot of threads to create and run applications successfully, and complexity is increasing all the time, he says. “Smart tooling will help them handle the cognitive overhead,” he adds.

Enterprises appear to be following smaller companies in adopting new, more productive ways to code. For instance, WhatsApp, which was developed by a handful of Erlang developers, was sold to Facebook for $19bn, while Walmart recently acquired the F#-based e-commerce platform for $3bn.

While procedural programming languages such as Java and C have been the bread and butter of enterprise software development, what has been particularly interesting for software development is the uptake of functional programming in recent years, particularly among companies that need to support large numbers of internet customers.

As Trelford explains: “Apart from Java, which has huge user groups, the biggest programmer user groups in London are those of the functional programming languages. I run the functional London meeting here. We have been meeting here for about six years and we have over 1,000 members. Scala, I believe, has 1,500-2,000 members and Clojure has been growing, as has Erlang.”

Many proponents of these programming languages talk about how little code they need compared with using a procedural language, which makes them attractive for writing code quickly, says Davis.

But among the reasons for the interest in functional programming is reliability. Malcolm Sparks, director and founder of Juxt, says: “One of the issues we still face as developers is how to build really big software systems. The bigger the project, the more likely it is to fail. It is easier to build small software systems.”

Sparks argues that, ideally, software developers should look at architecting systems by integrating many small software components, each of which has been developed to be highly reliable. “We are moving to a world where individual software systems are becoming so critical and so important that we had better build them using the best tools and the best languages, and this is why we are seeing a rise in interest in functional programming,” he says. “Functional programming is a better approach for writing highly reliable systems.”

Changing software development landscape

Among the changes Miles is seeing is that software development is no longer a factory floor to churn out new products. Rather, he believes software development is evolving into a continuous R&D practice.

“Companies that regard software as a driver for them are the ones that will win and one of the pieces of advice I give to company boards is that they should not think of software development as a general problem that we can solve by throwing more people at it,” says Miles. “Think of software development as a place where you might be surprised what comes out.”

Enterprises do not often have the luxury of greenfield development, but as Trelford points out, where enterprises need a new system, there is the opportunity to experiment with the least risk.

Wootton says: “Everyone is always excited about the new greenfield stuff, but there is a real business case with legacy.” Often, the real business case is actually the J2EE or .Net code that has been running for a decade or more and requires a big support team.

“You might do something crazy like services on your mainframe, but it turns out this may be where you get the biggest return on investment,” he says.

“Legacy is a bad thing,” says Sparks. While it is exciting to create new code based on microservices and perhaps functional programming, the biggest challenge faced by corporate IT is often how to handle a growing legacy of old stuff.

“It can be the millstone that drags you to the bottom of the sea,” says Sparks, who urges CIOs to look constantly at what can be decommissioned, and have development teams write new applications. These not only help to move the business forward but, at the same time, enable IT to decommission something else.

Davis believes that the new techniques available to developers, such as reusable microservices, containers, functional programming and continuous delivery, offer enterprises an ideal opportunity to reduce risk and improve reliability.

“It is all about safe, small-scale scalability,” he says. The tools and techniques discussed enable IT departments to avoid the risk of modifying mission-critical applications by augmenting them in a highly controlled way, adds Davis.



Some of the best software developers I know didn’t start out their careers with any interest in software development.

It may be difficult to believe, but sometimes having a different background — in a completely unrelated field — is a huge benefit when going into the field of software development.

I’m not entirely sure why this is the case (although I have some ideas, of course), but time and time again, I’ve seen software developers with only a few years’ experience, but broad experience in another field, end up surpassing software developers with much more experience.

If you are thinking about becoming a software developer but you’ve been in another, unrelated field for some time, hopefully this chapter will provide you with encouragement and some ideas of how to best make that transition.

The Benefits of Switching Mid-Career

Mid Life Career Change

Most of what I am going to be talking about here is my own speculation, since I started out my career in software development and later transitioned into the role I am in now, rather than starting out in some unrelated field.

However, like I said, I’ve met enough really successful software developers who started out in completely different fields to have at least a rough idea of what makes them so successful.

One huge benefit I’ve observed for people who have switched into software development from another field is that they often bring with them a large swath of people skills and soft skills that are more rare in the software development field.

It’s no secret that software developers sometimes tend to lack these people skills and other soft skills, and that I find them to be extremely valuable (obviously, since I wrote a book teaching them and have pretty much built an entire business around the idea).

I find that those soft skills that may be developed in other professions translate really well into the software development field and have the tendency to move people who possess them ahead of the normal learning curve. Having them may give you a distinct advantage, especially if you worked in a field where soft skills or people skills were highly valued.

I’ve also found that the mindset of success tends to be widely applicable and that if a person is successful in one professional vocation, the chances are they’ll be successful in any vocation they pursue.

You’ll likely find this to be the case if you are currently in another field — even a very distantly related one — when beginning to make the transition.

Finally, I would say that the ability to think outside of the normal constraints that many software developers and highly technical people think within can be a huge advantage, as well.

There is a high tendency for what is called cargo cult programming, where programmers are likely to do things not because they work, but because other developers are doing them and they are seen as best practices. Having an outside perspective can give you the advantage of thinking in a way that is unclouded by preconceived notions and ideas that are a bit pervasive in the programming community.

While brand new software developers without any experience in any vocation may also have this same perspective, they are often more susceptible to falling into the same traps because they lack the depth of experience and confidence in their own thinking that someone with more experience likely possesses.

Again, I don’t know the exact magic formula that seems to make software developers who started in a different background so successful, but those are a few of my ideas.

The Disadvantages

Job Disadvantages

I don’t want to paint an overly rosy picture of switching into software development from another field. It’s certainly not easy, and there are definite disadvantages. It’s also true that you are not guaranteed to be a stellar programmer just because you used to be a nurse.

One huge disadvantage that blindsides many transitioning developers is the complexity and amount of knowledge required to be a computer programmer.

There are plenty of fields where you could learn something in college or even have some on-the-job training, and in a few months, you’d be able to do the job.

I’m not saying that software development is the only difficult field there is or that anyone can do another vocation without training, but software development is many magnitudes more difficult than the average profession.

Yes, that statement may piss some people off, but it’s completely true.

In fact, if you are having a difficult time accepting that statement, you might have a difficult time making the transition because you will likely not be prepared for all you need to learn.

So, it can definitely be a disadvantage to come into this field thinking it’s just like any other field or job that you can learn.

You will have to do a good deal of studying and intentional practice to become even mildly proficient in this field, which is part of the reason for writing this long volume.

Another major disadvantage is, obviously, time.

This can be overcome somewhat by the advantages I listed above, which can accelerate your learning curve, but you are still going to have to play some catch-up if you want to fill the holes in your knowledge caused by a lack of direct experience.

Even if you have only spent three years in the field and are as good as a software developer who has spent 10 years, you are still not going to have seen as many situations and problems as that person (in most cases), so that lack of experience may make some things a bit more difficult.

How to Do It

OK, now that you’ve got some idea of what you may be up against, let’s talk about how to overcome some of these disadvantages and how to be as successful as possible when transitioning mid-career into software development.

Plenty of people have done it. I’ve even received emails from software developers who’ve made the transition late into their fifties, so it’s certainly possible.

Here’s how.

Transition at Your Current JobTransition At Your Current Job

It’s difficult to break into the field of software development. I’ve already spent a good deal of time in previous chapters talking about how to get your first job because it definitely isn’t easy. No one really wants to hire a software developer without prior programming experience.

How, then, do you get that job if your resume says you’ve been an accountant for the last 20 years? Well, one way is to start transitioning into software development from your current job.

Many software developers I know started out in a completely different field and found that they could learn a little programming here and there to help them with their work or to build some kind of tool that would help everyone at their work.

If you are interested in becoming a software developer, you might want to look around in your current work environment and see if you can find places where you could start using your newfound skills.

This is a great way to transition into software development because if you start programming at your job — even if it’s just small projects — you can then put that on your resume.

You may even find that you can create a software development role for yourself within the company you are working for just by automating things or building tools that end up being valuable enough that your current employer will pay you to keep doing what you’re doing.

Start by taking on some of these side projects at work during your own time and then perhaps ask for permission to start transitioning some of these activities into your full-time position.

If you can pull this one off, you may not even need to go out and apply for a programming job. Once you are officially programming at work, you can always find another programming job somewhere else.

Look for a Way to Use Your Existing Background

Another tactic I’ve seen successfully employed is to use your existing background in an unrelated field to give you valuable domain expertise at a software development company who develops software for that unrelated field.

For example, suppose you had 20 years of experience as a nurse and you wanted to get into software development.

Yes, you could learn programming and then try to apply for any software development job that came along.

However, it might be a much better idea to look for software development companies that mainly operate in the healthcare industry or even healthcare companies who might employ software developers. By specifically applying for these kinds of jobs, you’ll be giving yourself a distinct advantage over other applicants who lack the domain expertise you have.

In software development, domain expertise can be enormously valuable because understanding the why and purpose of the software in a particular industry can prevent many errors from being made.

It may be much easier for a software development company to hire a developer with 10 years of software development experience, but someone who knows software development and has 10 or more years of domain expertise is going to be a much rarer find.

I was just talking to a developer who had a genetics background and ended up getting a job with Oracle because his previous career was in genetic and biological chemistry and Oracle was looking for developers to work on a product they were creating that involved genetic research to help cancer treatment centers.

Try to use your existing, seemingly unrelated experience by finding a way to make it related. Just about anyone can do this because software exists in just about every major industry.

Be Willing to Start From the Bottom

Start At The Bottom

Finally, I’d say that if you are switching into software development mid-career, you need to be willing to start at the bottom with the knowledge that your previous work experience will ensure you don’t stay there long.

It can be difficult to make a transition from a high-paying job where you have seniority and perhaps a reputation to being a lowly grunt being paid peanuts, but if you want to switch careers, you are going to have to be willing to do that — at least in the short term.

The software development world is more of a meritocracy than other industries, so it doesn’t really matter how much experience you have or who you know so much as what you can do (although reputation obviously plays an important part).

I’d advise you to plan on starting from the bottom, realizing that most of your skills are not going to carry over, and to be okay with that.

This will help you to avoid the frustrations you might otherwise face if you expect to make a lateral transition into this field.

Like I said, though, if you already have experience in another industry and have achieved success there, many of the soft skills you have developed will be likely to accelerate you through the ranks of software development.

You just have to be patient to begin with.

Credits: Dzone

Credits: Dzone


While developing Spring Boot Applications using Intellij IDEA, it was so annoying to restart the Spring Boot app after each and every change. Spring Boot provides live reload (hot swap) of application out of the box using the following dependency.

But it didn’t live reload the application/container, and the hot deployment didn’t work for changes. Further researching found that following changes needed to be done in order the hot deployment to be worked correctly.

1. Open the Settings –> Build-Execution-Deployment –> Compiler

and enable the Make Project Automatically.

2. Then press ctrl+shift+A and search for the registry. In the registry, make the following configuration enabled.

3. Restart the IDE.

That’s it! Now the hot deployment works, and you don’t have to restart manually after each and every change.

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

Credits: Htxt

Credits: Htxt

Here’s a pro-tip for those leaving tertiary studies who are still undecided about their job path: study to become a Java developer.

Job search engine Adzuna recently conducted a study to find out what are the most sought-after skills in the country, and ‘Java Developer’ topped the list. It’s also not that surprising to find an incredible amount of jobs in the technology space.

“While not every job in demand is posted online, the trends shown by the sample data are clear and meaningful. Companies must dig deep to explore new ways of attracting programming and engineering skills, as well as some of those in the financial or accountancy area. Management skills too, represent a challenge,” said Jesse Green, country manager for Adzuna South Africa.

Adzuna explained that “engineers and developers, together with financial skills, are clearly the hardest to find, with the most demand from firms, yet with the least available candidates. Interestingly, recruiters are now a hot skill with many organisations and agencies requiring recruitment specialists in their HR departments.”

It added that the technology space is definitely  the place to be working in. “Now, with finance skills showing an increasing difficulty to recruit, it will be interesting to see how companies, and hopefully the South African government, ensure that South African firms are able to hire the right people with the best competencies.”




For the past couple of years, government and societies have been trying to make “Geek” cool again. Presidents and prime ministers are recommending that computer programming be part of schools’ curriculum. Politics aside, becoming a competent programmer today is more challenging than ever. Just being an introvert genius no longer suffices.

Companies and organizations are looking for people with cognitive skills to add to their technical abilities. It is difficult to put a number on this as it is very company-dependent, but the 70/30 rule could be applied here. That means that people should possess roughly 70% technical skills and 30% soft (cognitive) skills. A “hardcore” developer hardly moves into management if he/she lacks the soft skills required. I have managed many teams across multiple verticals and developed some job descriptions and career progression paths along the way that are in use in some of the largest companies in the world. Let’s try to sum up a few aspects of what seems to be the pattern when companies are recruiting or promoting.

Technical Skills

Well, this is a no-brainer; your technical skills will get you the interview. When recruiting a Java developer, companies are looking for several factors.

The Fundamentals

An understanding of the fundamentals of the Java programming language.

It is good to know how to write code, but knowing the reasoning behind your code and/or your chosen algorithm will make you stand out from the crowd.

Mainstream Programming Tools

Today, the fact is that you cannot be a jack of all trades (master of none). You have to pick which tool you are going to master. This is sometimes dictated by the environment you are working in, but let’s say it is a good bet to go with the following:

  • Build tools: Maven or Gradle.
  • SCM: Git (not GitHub. Big difference).
  • Build automation: Jenkins.
  • IDE: Netbeans or Eclipse – not just for writing code, but also code refactoring and debugging from the IDE. I came across plenty of developers who did not how to debug from their favorite IDEs.
  • Bug tracker: Bugzilla or Jira.

Mainstream Programming Frameworks

Application Servers

  • All Java developers should know how to deploy in Apache Tomcat.
  • As Glassfish development is halting, the next best thing is JBoss WildFly.

Cloud Development

Cognitive Skills

It’s great that you have a deep knowledge of the Java programming language and various tools, but your employer/clients will also be assessing you on the following aspects.


Communication is key to everything we do. We have to interact with the environment around us, whether it is in our private or professional lives. This is not just the ability to put words together, but how to communicate problems that we are facing, or proposing solutions to those problems. A great communicator knows how to express herself in front of various groups; remember that something that makes clear sense to you might not be the same from someone else’s perspective.

Problem Solving

Developers are problem solvers, philosophers, and thinkers. Don’t be one of those programmers who only writes code and doesn’t get involved in the discussion about how to solve problems. Don’t be the programmer who says, “Tell me what to create and I’ll create it. Don’t ask me if it is the best way to do it.”

Team Player

All developers work as part of a team, whether it’s with paired programming or a large project. You need to contribute to the team’s objectives and goals. Help mentor junior members along the way or assist struggling members in overcoming their hurdles. Don’t have an “I’m just here to do my job and then go home” attitude. Be part of the team. You don’t have to make silly jokes to become “team clown” or always go out on team events but be a team player.


This is a very important skill to have; the ability to acquire new skills on your own time. Do not always wait for the company to provide you with training. You need to go out there and learn new technologies and advance in your field. From front-end development to architecture patterns, there is always something new happening. Read blogs and articles and try to join local meet-up groups. What you learn can open up new vertices for your career.

This blog post was not supposed to be this long, but the aim was to tailor it to be useful for aspiring developers — or even veterans.

Drop me a line if you want to have a quick chat or join me on one of my courses to develop your technical skills.

Credit: Techtarget

Credit: Techtarget

ShoutOutPlay is a mobile app built with NativeScript that lets users record personal dedications and attach them to music tracks that play in Spotify. In this podcast, developer and ShoutOutPlay creator Nathan Walker discusses his choice of NativeScript for cross-platform app development to yield native iOS and Android apps from a single code base. He also explains how the app links and syncs with Spotify and shares what he learned and how it can benefit other developers of cloud-based mobile apps.

To use ShoutOutPlay, users record a message (called a shout out), attach it to any track from Spotify and add it to a playlist. As the song plays, its volume drops and the shout out is mixed in and heard clearly. After the shout out plays, the song resumes playing at its normal volume. Frivolous fun, perhaps, but dead serious when it comes to application development.

ShoutOutPlay could not have been built on the web,” says Walker, “because it uses Spotify, which allows only 30-second previews of tracks on the web. I had to use the native SDK in order to integrate with Spotify.” The app was built as a test using the NativeScript cross-platform app development framework.

Walker’s day job is as a senior software engineer at Infowrap in Portland, Ore. Infowrap is a software as a service application that allows users working on projects to collect, organize and share different kinds of content with other collaborators. Walker is investigating using NativeScript’s cross-platform app development capabilities in future versions of Infowrap.

Link and sync

The first step to using the ShoutOutPlay app is recording the shout out greeting as an .M4A file on an iOS or Android device. The second step is more complex — linking the separate shout out and music files together. To do that, another tool is required.

“I integrated [Google] Firebase into this NativeScript application,” says Walker. Each shout out is recorded locally on the phone and then synced and backed up to a Firebase database. Walker called an API from Spotify to access the streaming service’s full music player.

The choice of NativeScript as a cross-platform app development platform came about as Infowrap researched moving its platform from a hybrid Apache Cordova app to a true native app, Walker says. “I was trying to find something where we didn’t have a pure Objective-C or Java app because of the time involved.”

As an experiment, Walker wrote several plug-ins in NativeScript that found their way into production. ShoutOutPlay uses 16 plug-ins, all of which passed app store scrutiny from Apple and Google. Only one issue popped up: Spotify’s spotty support for IPv6.

Ultimately, Walker chose NativeScript because developers can write both iOS and Android UIs with one single, concise XLM language, he says. “If you have ever looked at an Apple app versus an Android app and looked at the UI construction, they’re not the same at all.”

In the remainder of this podcast, Walker discusses using NativeScript to leverage Angular 2, avoiding Objective-C and Java code and sticking with JavaScript. He also comments on the profound changes wrought by Angular 2 compared with its predecessor, including its ability to be used with multiple platforms.

The ShoutOutPlay mobile app is available in the Apple App Storeand on Google Play.



How’s your career going? how do you think it’ll go? Read on for some tips to help prepare yourself for the future.

So… quick but powerful question: What’s the future of software development?

A lot of people ask me about the future of software development. What the future holds for software development and for new and old programmers? Are there going to be new programming jobs in the future? Are there going to be new and exciting job creations when it comes to software development?

All those things really need to be discussed because we really don’t know how things will turn out in the future. So, what is it going to be? How are we going to face these changes in software development?

Watch this video and find out!

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

Microsoft Type Script


Javascript is one of the most used programming thanks to the support of all major browsers, but it is also a language with restrictions that have led to a growing stream of different frameworks in recent years has expanded Javascript with features sought after by developers.Microsoft Type Script goes in a slightly different direction and offer a programming language that provides many of the features known from the large application-programming language, but translated into Javascript.

As the name might suggest, it is one of the useful features of Type Script possibility for type-resistance, so when compiler his Type Script, do the compiler a type check, so you all get a type of real output in JavaScript, even Javascript in itself not type fast .

Version 2.0 of Attraction Script was released recently , and Type Script is now so established that several of the major frameworks for Javascript is about to switch to it, and the example was Angular 2 written in Type Script.

Among the novelties in Type Script 2.0 is that null and undefined are now actual types, and it makes it easier to take into account that you sometimes risk getting either one or the other return.

“Undefined and null is probably number one source for bugs in Javascript. Now is undefined a type in Type 2.0. It is especially useful when you have some data from APIs, and they send a undefined back. It tends to give a crash if you do not handle it in his code, “says lead front-end developer Dennis Haulund Nielsen from development house Nodes to Version2.

To utilize this feature in Type Script 2.0 must, however, beat the strict null checks to. The Microsoft recommends that you do, but it may cause problems with existing code, and therefore it is so far optional.

New syntax and object-oriented programming

One of the special things about Type Script is that ordinary Javascript code can be inserted as part of a program written in Type Script. Type Script is a ‘superset’ of Javascript. ‘Del’ means that all Javascript – including the features that are coming in future standards – is a proper subset of Type Script.

But it gets a little more complicated than that, for Type Script uses a slightly different syntax than Javascript.

“I had never coded anything other than Javascript. There is a learning curve, but it’s worth it for large projects. If you have a small project, then it is probably not worth it to put all the tools up to Type Script, “says Dennis Haulund Nielsen.

Type Script defines example return types of methods such as the syntax of Swift, but a little different than languages ​​like C # and Java, but like the two languages, then type Script also thought to support object-oriented programming.

“It is often used as an argument against Type Script that they have taken an overall architectural choices. But we’re still object-oriented in this house, “says Dennis Haulund Nielsen.

Compatible with all browsers

Javascript is already used for many types of applications, but it takes time to introduce new features in the language. It’s one of the reasons why there are so many frameworks for Javascript.

Type Script translator for Javascript standard ES5, but there is also a ES6 and ES2016 + underway.They are supported yet by all browsers, while you have to return to Internet Explorer 8 to run into trouble with ES5.

ES5 is also a subset of the more recent standards, and they are also subsets of script type. This means that code written in Type Script should be compatible with future versions of Javascript.

As these newer versions of Javascript is also included in Type Script, it also provides the opportunity to tag them as part of a Type Script application that so right now will translate to the older ES5.

Help for major projects

For developers provide Type Script opportunity to use some more advanced tools than is possible only with Javascript and various frameworks. For example it is easier for multiple developers to work together.

“With a good IDE you get autocomplete and Intellisense. It’s easier to work on a team when colleagues can quickly see such arguments to a library. It flies more along, when codes, “explains Dennis Haulund Nielsen.

At Nodes developers are in the process of transferring the core components that are being used in several projects to Type Script inter alia, increasing the quality assurance of the code.

“We recycle the modules in many projects, so it makes sense that they will be as flawless as possible.Therefore it makes sense to put the time in to port them, “says Dennis Haulund Nielsen.

Another new feature of Type Script 2.0 is also helpful to the larger projects, namely the ability to make properties read-only. It can help to prevent that two developers working in their own part of the code gets introduced code that will overwrite each other’s objects.

Credit: NDTV

Credit: NDTV

Media reports about the demise of the Indian software industry are grossly exaggerated and very premature.

Let us take stock of the situation today. The Indian software export industry is about $110 billion. It employs around 4.25 million people. It has a 60 per cent market share of global outsourcing and is globally dominant. Of the 10 top software service companies globally ranked by market cap, five are Indian. Of the top five, three are Indian. All of them have a massive presence in India. Of the total number of employees, amounting to nearly 2 million, in these top 10 companies, about 70 per cent are based in India or travel out of India. The Indian offshore software industry dominates the software services world and has no parallel.

Concern has been expressed by certain observers saying that the software industry died on Friday after a short battle with digital technologies. If you look around, only one company has done well in the last one year, and that is Accenture. This is primarily because Accenture engages in enterprise transformation and at a pan-project level. With no proprietary technology to support, unlike an IBM, it is not tied down to specific solution sets, and so it has a lot more lateral flexibility than most other companies in its space. However, this does not imply that every other large company in this space is doomed.

At a time when the developed world is growing between 1.5 to 2 per cent a year, this globally competitive industry is growing between 7 to 9 per cent, more than three times OECD (Organisation for Economic Co-operation and Development) growth, and with most of its business coming from there! Despite Brexit, the banking crisis, and the threat of increasing federal interest rates, this is certainly an extraordinary achievement by any standard, especially when the industry has become massive and a universe in and of itself. When an industry is this large, it begins to reflect the growth of the economy and to grow 3/4 times the rate of economic growth is a significant achievement. To believe that a large industry can grow at 20/25 per cent a year in services with very low inflation is an unrealistic expectation.

Some commentators have stated gleefully that the end of the industry came when the business stalled in the last quarter and because they were unable to adopt a new stack of digital technologies. These all-knowing commentators seemed to lack a fundamental understanding of the industry because they made statements that the Indian industry would not have tanked if we had been able to embrace SMAC or Social Mobile Analytics and Cloud-based technologies early. The Indian industry has done very well on the legacy side of IT services. Web-based technology, which was cutting-edge not so long ago, is also now legacy! Indian IT also has a growing practice in SMAC.

While clearly dominating the global legacy segment, in the newer segments like SMAC, there is still plenty to be achieved. There are too many smaller players locally available across developed markets, while a few bigger players have also emerged. SMAC is certainly going to grow because it is all-pervasive and it permeates all technologies and most of the solutions have become horizontals. This is a natural evolution of the internet economy.

When the internet first burst forth, smaller companies in the United States enjoyed high valuations, took the lead, and then soon after that the Indian IT companies grew and took over in a very large substantial manner. Similarly, in SMAC, the Indian companies are now growing their skills, talking to their customers and evolving their practices. SMAC is permeating the entire offering across services, and in two or three years, SMAC will become the new horizontal layer.

Yes, in the last two quarters, growth has stalled – especially for the larger companies. But when you are an 18 billion dollar company with more than 370,000 employees, you are global, and you are growing at 6 to 7 per cent, in most countries of the world, they will applaud you for still creating jobs and for still growing. If you are a 10 billion dollar corporation working globally and growing at 7 to 9 per cent, and enjoying profit margins in excess of 20 per cent and generating free cash flows when the world’s growth is so slow, in most countries of the world, people will applaud you and buy your stock.
What is happening to the IT industry in India is a mismatch between people’s expectations of high growth on a very high base and the hostile external environment with rapid technological change. Certainly, the growth rates of the past are no longer feasible, and most of the large global IT service companies will grow in the range of an estimated 2 to 10 per cent. The Indian offshore players might grow at rates in the range of 7 to 10 per cent. One must understand that the growth in revenues of 7 to 9 per cent with an offshore model actually implies a growth of 11 to 13 per cent on a comparative basis for a purely onsite oriented company, in terms of hours that are actually utilized and billed. The use of revenues alone to map the growth of Indian IT is not the right measure, and neither is it right to compare the growth rates with companies in the West which are more or less local companies with local practices. The total hours billed is the pre-eminent parameter when the billing rates can vary from an offshore rate of 20-24 dollars an hour to an onsite rate of 70-90 dollars an hour for the same kind of work.

As far as technology is concerned, such shifts have happened before and Indian companies have done very well when faced with change since they have a younger and more trainable workforce and are much responsible with costs. They are the only companies that can handle the entire gamut of technology work in large global enterprises from main frames, AS 400, Cobol, UNIX, and C++, to web-based technologies and now SMAC. You will be truly surprised by how large these legacy systems are, and how much of the world’s largest economies still rely on them. The total installed base of software on which global corporations operate is around $4 trillion, and this is not going to disappear tomorrow. Yes, the nature of work will slowly evolve, as it has often over the last 20 years, but Indian IT companies will understand this evolution and will manage the change.

At the end of it, Indian offshore companies are poised to assimilate new technologies. As when the internet economy first burst onto the scene, these companies are slightly behind the curve because they are still handling large complex systems. However, the skill levels here are tremendous, the management is extremely robust, the quantum of cash on the balance sheet is gargantuan, and they control high market caps that allow them to make acquisitions. This will make sure they continue to dominate the industry for at least the next 3 to 5 years.

All talk of demise based on a quarter or based upon a lower growth rate are figments of overactive imaginations.

(Mohandas Pai was the CFO and then the head of HR at Infosys. He is now Chairman, Aarin Capital Partners.)

Disclaimer: The opinions expressed within this article are the personal opinions of the author. The facts and opinions appearing in the article do not reflect the views of NDTV and NDTV does not assume any responsibility or liability for the same.

Disclosure: Mohandas Pai is an investor in NDTV Convergence’s e-commerce site,