Developing software is often viewed by most and by large organizations as a mechanical task with a defined path from idea (A) to product (B). Akin to a product being built over an assembly line.
Is this assessment correct? And does knowing the true answer to this question even matter?
While opinions on any aspect of software development often differ greatly, in this article we share our bias and cover some of the potential impacts to larger organizations.

Paint by Numbers or Picasso?
Our experience has led us to believe that developing impactful software– the journey of taking an idea to functional solution– is truly an artistic practice. Why? Because of the amount of choice involved.
The journey from A to B, from idea to product, has virtually infinite paths. True artistry reveals itself when the chosen path and pivotal decisions along the journey produce great results and inspire peers. Ultimately, the more choice you have, the less you can rely on numbers being there to help you paint. Without a defined path, creating software or starting from A, is like looking at a blank canvas.
When looking at the desks of accomplished developers, you will see arrays of sketches, doodles, and hand drawn diagrams. To the casual observer, the images are nonsensical. But in the eyes of the developer, these images convey their unrealized ideas. The images can often represent a long internal reflection and debate they've had while trying to determine the best solution to move forward with. And given the seemingly infinite ways to produce solutions in software, early ideas can have lasting impact through the process.
If we were to continue this as a philosophical exercise, the true answer to our question would lie somewhere between the extremes and is dependent on several factors. However, from a pragmatic standpoint, it is more useful to understand where the bias is and how it may impact your organization.
We acknowledge that there are portions of the development process that are highly mechanical and procedural. Often, certain adjustments to solutions can require very trivial effort. And often, observing the speed of trivial changes with beneficial impact can bias perspectives when considering the entire development process.
With software development having strong intersections with writing, architecture, graphic design, and leadership, it is hard to dispute the artistic nature of the craft.
We believe that organizations can greatly benefit from acknowledging that major parts of the software development process require creativity and artistry. Organizations will greatly benefit in the long term from learning how to create environments and provide leadership to support and foster artistic talent.
Evaluating Artistry
Another angle we can use to make our point is by understanding which factors make some artistry or software better than others. The artifacts on the desk of a developer might be similar to an artists, but how similar are the metrics we use for evaluating their quality.
Beautiful Writing - Akin to reading the works of great authors, it takes a great talent to write beautiful code that others can read and understand with ease. Peers will often be in awe of truly artful creations.
High Performance - By understanding how various algorithmic techniques can be applied to a problem, there is beauty in designing optimal algorithms for a specific problem. Again, discovering a truly optimal solution to quickly solve a problem is an art in itself.
User Experience - Where software meets the user is often the first place where people evaluate a system. Developing great user experiences requires artistry and has become a field of study in of itself i.e. UX Design. Building great user experiences blends into other artistic fields and can often work as an amazing way to mitigate other system deficiencies.
Delivery Time - Many will equate quick time to deliver as attribute of a talent that is a master of his craft. Quick delivery time with very limited issues is a very impressive talent and can be an indication of commitment to the craft.
Given the infinite paths to follow, developers who tend to display desirable results often have talents that must be recognized. While all the above factors are definitely applicable to differentiating talent levels among software developers, we have observed that the following factors serve as great value indicators:
Ability to Focus on Business Objective - Many developers will get drawn into design decisions without consideration for the business objectives. For anyone who has managed development groups, they have most likely witnessed team members debating nuanced issues that have little to no impact on the final product. The ability for developers to understand business objectives throughout the process is rare.
Delivery Speed on Iterations - The speed at which a software solutions are modified in future iterations is highly correlated to the design choices made by developers. True talent can almost predict future needs of a business, ensure agility in their solutions, and turn around relevant changes in a timely manner. This is where true talent shines.
Value Add Feature - The ability to deliver valuable features with your solution that were unspecified is also a talent and ability that is rare to find.
These factors have a common thread and are linked by how well a developer or development team can understand and integrate with the business goals.
Software Iterates, Always
An aspect of software development that is a constant truth is that for any "final" product, there are always iterations. Business needs are always evolving. Business environments and pressures are always changing. And in turn, businesses leveraging software need their software to adapt and evolve.
There are seemingly infinite ways to create a software solution. Two pieces of software that demonstrate the exact same functionality can have underlying code that looks completely different. How do we know if one version of the code is better than the other? As mentioned above, one true indicator is the ability for the developer to make impactful modifications to their software in a timely manner.
Turnaround time on future changes is a great indicator of the talent level that developed the original software.
The Constant March Towards an Assembly Line
While software development may be an art, there are many valid reasons to want software development to be a mechanical process. Having exact delivery times and guaranteed functionality by certain points in time is advantageous for business planning, sales strategies, etc. This desire pushes organizations to explore ways to push software development towards an assembly line function.
We also acknowledge that software development is often pressured to become an assembly line operation. Especially, and for valid reasons, in large organizations. From our experiences, we have seen how this trend often ends with organizations unable to grow and evolve effectively, and enter a cycle of reaching out for external assistance.
The Blind Desire to Leverage Software
In this day and age, it is often the case that teams within an organization focus on other aspects of their business and require some form of software solution to achieve their objectives. Often times, the success of the business is highly dependent on the quality of the software. Team leaders, not familiar with software development, can often form a very simplified opinion of the process of software development.
Leveraging technology without fully understanding the nuances of development can create expectations out of misunderstanding and can also lead to very disastrous consequences. The objective functions of business units often requires timelines to be met. Because of this necessity, leaders impose timeline constraints on software development which can be misaligned with the process.
Pressures on software teams to deliver will always produce results. However, the damaging impacts are often seen down the road as iteration become challenging. While issues can be averted by talented developers, we have seen that organizations that don't understand the software process will usually lose the talent.
A Desire to Scale
Organizations that want to scale up will explore various ways to efficiently use technology. Outsourced solutions for common functions becomes standard practice. Leaders will also look to reduce or eliminate key-man risk. This objective certainly requires leaders to mitigate or dismiss the notion of Picasso like developers and expect all developers to be interchangeable assets in a system. For anyone with experience in a large organization, this will sound very familiar.
While the ability to scale is valuable, avoiding using top talent for fear of key-man risk can be detrimental to your future ability to evolve. They're called key-men for a reason: again, many factors play into this decision, but if your organization is looking for an edge with technology, then understanding the importance of retaining true talent is paramount.
From our experience, Picasso-like software developers in supportive environments, always outperform large teams tackling the same problem. A 10x to 20x advantage is not uncommon in our observations across many organizations. We believe that many large organizations are losing talent because of their misunderstandings around true value in software development. We leave this as a topic to explore another time.
The Cost of Averaging Ideas
From the perspective of developers designing software, even small pieces, this too is a creative process. Managing creative people brings with it a different set of challenges that existing managers in your organization might not familiar with. Having your creations scrutinized or dismissed can be an emotional experience for someone who put a lot of work into their idea. Emotional elements of data driven business conversations can be hard to deal with. The added volatility to output in terms of time and results can be very challenging to manage up.
Growing teams often become less productive and effective. Managing personalities and feelings becomes a difficult dynamic to address. Often, managers in an effort to ensure everyone is engaged, will average out ideas to produce solutions. For the sake of easier management, great ideas can be diluted and often compromised.
Alternatively, smaller teams or individuals can develop their creative ideas with minimal resistance. If the individual is extremely talented, this can be a true blessing for the organization.
The Cost not Supporting Artistry
Anyone who has been in a large organization, will be familiar with development teams being siloed– akin to other departments. There is nothing out of the ordinary about silos forming in large organizations and is a natural progression for many valid reasons. In order to engage development teams, internal clients are asked to create user requirement documents that describe, in detail, the functionality of the software they require. This allows development departments a chance to manage timelines and expectations.
This process, which is common practice in large organizations, tends to make people within an organization look at software development as a mechanical task. A client selects desired functionality and features and is given a timeline to expect the output. Again, at large scales, this can be an effective practice to follow as a centralized service provider. However, as many with experience can attest to, friction between client and development departments quickly develops an issue and can become a seed for bad organizational culture.
Growing organizations, trending toward the currently accepted mode of operation often focus on its advantages. We have observed that the costs are not often understood by leadership. Top talent is hard to maintain in a factory like environment. Most large organizations will lose or drive away top talent due to management style.
Building separation between business units and software development also hinders talent from delivering exceptional value. Mismanaging a creative process will also cost organizations when it is time to pivot software due to business pressures.
Typically the path of technology departments ultimately leads to high turnover and an increase in engaging outside organizations to evaluate issues, help drive organizational change, or deliver the value that is vital to the business.
Concluding Thoughts
Software development is an occupation with a very artistic bias. While we may have breezed through our position we hope the reader understood how our bias was formed. As we explored this topic, we talked about how observations around software iterations can reveal true talent. While we touched on how organizations should address maintaining talent, we could explore the topic further. As a result of helping organizations to create supportive environments that attract top talent, we have many points to make.
Our article quickly pivoted to describing factors that can help talent can be discovered. We also highlighted that supporting talent is crucial for organizations in an environment where everything has become digital. Leaders need to demonstrate they are able to manage this resource effectively because the loss of real talent can be extremely detrimental to any organization.
We touched on the current trends in technology departments of large organizations, and touched on how the natural pressure of efficiency may lead to terrible results if issues are not addressed. A topic to explore another time, is the current drive of large technology departments to commoditize all their responsibilities. The potential end result for organizations is that there there is no intellectual property or competitive advantage to be leveraged.
We touched on behaviours that organization exhibit as issues arise. A trend to look externally to evaluate issues, spark their teams towards something better, or deliver a valuable results is commonplace. This is often where we are engaged. Our experience has shown us that effective engagements truly happen when leadership can acknowledge the issues and provide an environment for progress.
To continue the discussion and learn more about our perspective regarding any of the topics introduced, please feel free to reach out to us.
Opmerkingen