Should An Effective Developer Innovate, Imitate or just Integrate?
Jul 6th, 2010 | Architecture, Concepts, Expertise, Skills
in·no·va·tion – introduction of new things or methods
im·i·ta·tion – the copying of patterns of activity and thought of other groups or individuals
in·te·gra·tion – an act of combining into an integral whole.
What is the best strategy for an effective developer – innovation, imitation or integration? Should you introduce new creative solutions, adapt other people ideas or just integrate existing components?
Software Development is an exciting intellectual endeavor without physical barriers. It is easy to start innovating – come up with new ideas and quickly submerge into their implementation. And I don’t mean here fundamental breakthroughs. I consider as innovation building of any non-trivial solution that is not directly stemmed from Google search results, development resources or available examples. And certainly, I pose the dilemma – innovate or not innovate – to skillful developers who are quite capable to innovate and who enjoy meaningful creative work.
Discount Machine
Lets start from a tournament organized by Kevin Laland of the University of St Andrews to find out what strategy works best to gain maximum pay-off:
- innovation – a new behaviour randomly acquired by individual learning;
- observation – a new behaviour acquired by learning from others or imitation;
- exploitation – using a previously learned behaviour to gain pay-off.
The participant had to build a strategy that their virtual agents would use to decide between these options in a computer-generated world. The challenge was to create the strategy that generated the most successful agents.
Therefore, a tournament showed that the best strategy is keeping up-to-date by learning what others are doing and using their successful solutions most of the time.
Strategies
You have three main strategies for approaching a new problem in software development
- Integrate into the system existing software product, component or service – commercial or open source (for example, Payment Gateway as PayPal, Blog Engine as WordPress, CMS as Drupal, UI Components as Telerik and so on)
- Imitate good enough solutions and adapt to your problem (Architecture Patterns as MVC, available code examples and guidelines as MSDN, borrow ideas from blogs, open source projects, Starter Kits, SDK and so on)
- Innovate and create new solutions or make significant improvements to existing approaches
Integrate | Imitate | Innovate | |
Time to market | ![]() ![]() |
![]() ![]() |
![]() ![]() |
Cost | ![]() ![]() |
![]() |
![]() ![]() |
System integrity (with system architecture and environment) | ![]() |
![]() |
![]() ![]() |
Required Expertise | ![]() ![]() |
![]() |
![]() |
Control over code and future development | ![]() ![]() |
![]() |
![]() ![]() |
Competitive advantage and uniqueness | ![]() |
![]() |
![]() ![]() |
Maintenance, support and improving capabilities | ![]() ![]() |
![]() |
![]() ![]() |
Learning curve, tacit knowledge, help | ![]() ![]() |
![]() |
![]() ![]() |
(*) Disclosure: I should confess that the table above has some assumptions. I assume that external components for integration have good quality, work as advertised and are backed by solid support and team . Also, I assume that internal developers involved in implementation have good skills and experience. They follow good practices and are motivated to do great job and know what they are doing. I fully realize that life is not simple, and my assumptions could be completely wrong and this would change the table and the whole game 🙂
- available solutions do not meet needs or compromises are not satisfactory
- non-conventional and state-of-art solution is required for challenging important needs
- the component is crucial for the competitive advantage and uniqueness of the software product
- full control is required over code and future development of the component
- the component has low compatibility with system ideas and core architecture, over-complicates technical solution and breaks integrity of the system that result in
- unnecessary code and rough system seams to make components work together
- limited refactoring and re-design options
- reduced ability to expand the system
Imitation is a middle ground – you build solution yourself but use other people ideas and experience as a guidance.
- Improvement and simplification of the system design to make it easier to evolve and support
- Removing technical constraints and solving technical challenges to make the system faster, more responsive and reliable
- Introduction of important business features where no standard solutions exists
- Significant improvement of users experience
- Reducing cost of development and support
- Developing system features or properties that are not required
- Building alternatives for good available solutions (reinventing the wheel)
- Playing with interesting ideas without customer awareness
The Effective Way To Build Software System

- Understand purpose of the system, essence of customer needs and desired outcome
- Break downthe system into components and research if
- standard solutions exist (for integration)
- implementation ideas exist (for imitation)
- innovation is required
- Can you change needs and requirements? Transform customer needs and architecture ideas to minimize development effort
- by moving from innovation to imitation strategy
- by moving from imitation to integration strategy
- Evaluateeach component from the system and business perspective
- Should you avoid integration and use imitation if:
- System integrity under the threat and the component is part of the system core
- Control over code and future development is required
- Competitive advantage and uniqueness are important
- Should you still go with innovation because of unresolved contradictions, challenging and unmet needs?
- Should you avoid integration and use imitation if:
- Build prototypes clearly separated from mainstream development to confirm selected strategy
Becoming an effective software developer
- Systematically study other solutions in your area of specialization (at least a couple in a month – understand strengths, weaknesses, high-level architecture and interesting tricks)
- Learn concepts and language of your business domain to be able to understand customers and shape their needs together
- Enhance abilities to find and brainstorm alternatives (improve techniques, make them essential part of your process)
- Become an expert in Google search and fast evaluation (no kidding, these skills become very important for any modern developer)
- Master rapid prototyping, apply solutions in practice and seek for rapid feedback (answer in short time if proposed solution is good, learn and correct if you made a mistake)
- Develop a holistic view and knowledge of the system, infrastructure and environment (understand subsystems, connections, integration options and trade-offs)
- Keep up with latest software development trends, technologies and approaches (subscribe to blogs, magazines and other sources)
- Achieve deep specialization in your core technical area and business domain (extensive experience and deep knowledge are great assets for innovator)
- Continuously develop creativity and problem solving (the post about creative problem solving)
- Enhance architecture and fundamental programming expertise based on own practice and ideas from others
- Master Evolutionary and Domain Driven Design
Great post, Andriy! Sent it to the whole team, definitely on the mandatory reading list.