We live and work in an increasingly software-led world. This means more and more businesses that don’t consider themselves software shops are, in fact, dependent on software to succeed. But changes in how software gets built means the composition of these teams is changing. You still need specialists, but what kind? Do you still need coders, or just developers—and what’s the difference?
This article looks at how changing software-making tools are redefining the composition of software-making teams. If you deliver software to customers either internally or externally, it’s important to understand these changes. This ensures you’re getting the most for your money and taking full advantage of the expertise you already have on staff.
PART I: Our Shifting Relationship with Software
“Every business is a software business”
Tech leaders have been saying it for a while, most recently Microsoft CEO Satya Nadella. Regardless of how much topline revenue you earn through software development, you might already be thinking and acting like a software maker. A lot of this is due to the deep integration of software into your processes and priorities.
This integration means that when you want to update a process, the software needs to be adapted. And, inversely, when a new feature is rolled out in a system you’re already using, you will adapt best practices to leverage the innovation. And your customers are experiencing a traditional SDLC, as they way for new features to come to whatever product or service you sell.
But how those businesses work is changing
If you run a large dev organization, you’re probably aware of some of the innovations shaping the software industry. If you don’t, we can look at a related industry (web design and development) to understand the shift from coding to building objects.
- In the beginning, web development depended on mastering markup/programming languages, most notably HTML. This meant you either need to hire an expert or learn the language yourself.
- Over time, new interfaces and platforms emerged that made the whole business slightly more DIY. You still needed a good understanding of web design best practices, but you didn’t need deep coding skills.
- Today, there are lots of popular tools and platforms that let almost anybody create a website. Enter copy, drag and drop some images, make some style decisions, and you’re ready to publish.
Similarly, software developers have worked hard to create libraries of reusable objects and micro-applications. This means that when you want to, for instance, create a login page, you don’t have to start from scratch. You can find an already-built object, solve some integration details, and add it to your application. This is especially true in a world increasingly dependent on web applications designed for mobility and consistency.
What it means to your processes
These developments mean that even as software remains critical to your success, the building of the applications and services is changing. And this means you’ll still need software specialists, but different kinds. We’ll now look at the different roles and explore some of the innovations that make these shifts possible. As we do, remember it all goes back to the dynamic discussed earlier: less raw code, more reusable objects.
- Write once, use many times
- Write once, use in multiple places
- Write once, deliver to multiple devices and interfaces
PART II: Evolving Software Roles
Before looking at some of the new tools, let’s look at software team roles. And while they all still have a vital role to play in most software organizations, the balance of power is shifting from coders to developers.
Coders
Coders work with raw material to create pieces of software applications. A coder will often be assigned to a specific component of an application. It might be the calculation of two numbers, or a request to a database for a specific record. Coders often specialize in a single programming language. In general, they have deep knowledge of that language.
Programmers/developers
Some organizations use the terms interchangeably, as we’ll do the same here. While coders are often hyper-focused on a single language, and work closely on very narrow tasks, programmers and developers take a broader view. While coders work on a single piece of the puzzle, programmers and developers are tasked with putting that puzzle together. Where coders think in statements and expressions, developers think in patterns and algorithms.
In general, it seems like the term developer is now favored over programmer. Some of this is just fashion, since programmer seems antiquated to many. New ideas like DevOps are part of this trend, where development and operation are unified into faster processes and more nimble best practices.
Software engineers
If there’s a hierarchy working here, engineers are probably at the top. Software engineers are typically responsible for taking the work of coders and developers and optimizing its impact. This means finding ways to make an application work faster, or perhaps porting it to a new operating system or device. It might also include the challenges of scaling a particular application, moving from services that can support 10,000 users to a platform that can serve millions.
Engineers are also responsible for problem solving. Whether it’s an infrastructure challenge or how to diagnose and solve complex usability issues, software engineers are the best match. This is due to their ability to think across multiple programming languages while pursuing high level objectives of integration and efficiency. For large enterprise-grade software initiatives, an engineer’s expertise is invaluable.
Part III: New Tools and Technologies
Software objects and libraries
Moving from code to object is probably the first step on the journey to a ‘no code’ end state. Object-driven libraries are nothing new, and Java especially has been essential in our digital transformation to date. Reusable objects, optimizable for different environments, have been helping developers save time for a long time.
This modular approach to software has some obvious advantages. If you need to include a wheel somewhere in an application, there’s no reason to reinvent it. And lots of and lots of advanced software development is done this way, especially for the web.
Since building libraries obviously requires code, why are we including them in the discussion? While the objects (and then the libraries) are driven by code, the objects themselves can be deployed without recoding. This enables developers, not coders, to create.
Integrated development environments
An integrated development environment (IDE) is a software platform simplifying how software gets built. It combines several critical tools into a single graphical user interface, or GUI. For the purposes of our discussion today, we’ll consider them “low code” platforms.
A typical IDE combines:
- A source code editor that’s optimized for ease of use. This means using color and other visual cues to provide autocomplete, offer options, and even spot errors.
- A local build tool that automates many of simple, repeatable tasks required to turn code into a delivered application. This enables developers to easily turn source files into a binary that can then be offered as an executable.
- Integrated debugging: While standard software development relies on separate testing and quality assurance phases, an integrated development environment builds debugging into the edit, compile, and deliver phases.
While IDEs don’t always mean less programming, they reduce the time spent on other adjacent tasks. And it enables a smaller team to get more done, since they don’t waste time learning new tools or trying to integrate technologies across the different phases. Their “low code” nature again shifts the balance of work from coders to developers.
No-code platforms
Finally, no-code platforms are the closest to “developer” only software building. As the name implies, these platforms enable the creation of applications without a single line of code. And, since these environments are designed around well-tested objects and interfaces, your teams will spend more time making and less time testing.
While the details of each platform vary, the goal is the same: make software development as simple and straightforward as possible. Whether building inside application frameworks like Salesforce, or using a polished library like Microsoft’s Power Apps, most no code platforms:
- Rely on a combination of drag and drop interfaces and easy rule setting
- Use verified objects that means you don’t have to worry about version incompatibility
- Automate testing throughout the process
- Integrate with other advanced DevOps best practices like CI/CD
The last bullet above might be the most significant. In a SaaS-ruled world where organizations need to be able to quickly bring new features or fixes to market, no code platforms enable teams to move with maximum agility. Instead of traditionally long and complex cycles of writing, building, and testing, they can quickly solve customer or business challenges on the fly.
PART IV: The Big Picture: Production Line vs. Problem Solving
If there’s a common thread running through these innovations, it’s efficiency. Why are you paying developers to reinvent the wheel? How could you better use the enormous time and talent you have at your disposal? If we look at the software development lifecycle (SDLC), we can begin to make sense of these opportunities.
Whether you’re operating inside traditional waterfall parameters or leveraging new ideas like agile, software development means:
Understanding and translating business requirements
Best practice dictates that business requirements should be gathered by business analysts, not software specialists. This prevents teams from “thinking in solutions” before they truly understand the challenges.
These analysts can then work with developers to begin to frame these business challenges in the context of software. By working together to map workflows and identify information needs, the edges of the application can begin to emerge.
Designing betas and prototypes
Once those edges are seen, developers can begin to create a prototype. Inside traditional processes, this is a document, in Agile it’s typically a functioning piece of software. This is where developers and coders might work together. Developers will assess their “inventory” of choices and begin to assemble. If they find gaps, coders might be brought in to create objects to solve them. Once the prototype or beta is complete, it’s time to move to assessing usability and efficiency.
Building out and testing software
Once an application moves past prototype, it’s time for the organization to start ‘kicking the tires’. This means comparing the application to original requirements. Are users needs being met? If not, why? Is the application working well with other services? Is it performing well on the chosen infrastructure? Developers and engineers will work together to answer these questions.
Scaling solutions up and out after launch
Once the application is meeting those initial business requirements. It’s time to move to production. This typically means delivering that same application experience at scale. This will require more infrastructure resources and require foundational services around everything from user authentication to data security. This is where engineers earn their keep—solving high level challenges around and outside the application itself.
PART V: Do We Need Coders?
Where you might still need coders during development
As we can see above, even the best designed ideas begin to show seams and gaps once implemented. This is where coders often are invaluable. They can dive deep into the application and its architecture to fix issues and extend functionality. It might be slightly modifying an object or rewriting a service. It could be as simple as fixing an incorrect calculation.
So, as we see the software world move from mastering language to leveraging objects, the need for coding throughout the process diminishes. But when their assistance is required, it’s invaluable and can make the difference between success and failure.
New best practices
As new best practices around agile development slowly dominate the software space, the ideal software team is also evolving. Instead of working in large, siloed structures, agile and similar ideas thrive on cross-functional team collaboration. So rather than managing large teams of coders who hand projects off to engineers, you’d build a smaller nimbler team that included both.
In this world, coders aren’t less important, they’re simply used differently (and less frequently). An expert engineer (who started as a coder) can focus on big picture challenges, and then deploy for those deep dives required to update or customize objects. This enables organizations to get the most from both their talent and available technologies while producing software that works well.
What’s your ideal blend?
The ideal software team is the one best suited for your specific application needs. In some cases, development can take place entirely inside a low/no code environment and the results will be remarkable. More complex challenges, especially those heavily dependent on infrastructure, will require a broader skill set. This means having broad access, to a full array of specialists, is your path forward.
Take control of your I.T.
Ready to take control of your software development process? While the internet is overflowing with resources to help you take the next step, beware! Not everything you find will set you on the right path. It’s easy to get lost in a sea of tutorials and advice that will set you three steps back before you can even start moving forward.
The good news is, at Kintone, we have your back. We’ve gathered advice from some of the greatest experts in the field, sprinkled in our own personal experience and expertise, and arranged all of the information into our simple, clear and concise ebook: We’re All Software Developers Now.
As a matter of fact, we’re so confident our tips and advice that we’re giving the ebook out completely free! Just register and begin retaking control of your software development process today.
About the Author
