The Imperfect Brain

Lets start with the brain – the most important organ for software development work (I would be surprised if you have even more important organ for this job). This biological tool, composed from 100 billion of neurons and many legacy structures inherited from worms, reptiles, mammals and other animals, is not really perfect for programming tasks.

I think I know – you want to have between ears obedient powerful and reliable machine like the shiny new computer on your desk that crunches tasks with the highest performance without taking breaks, emotional drops and losses of attention.

Unfortunately, our brain reminds more an old computer that barely runs your development activities competing with other processes for limited memory and processing resources on the top of overloaded unstable Brain OS.

Yes, writing software is not easy and not the most important biological mission for your busy brain. It is difficult to achieve top mental performance for your tasks, especially, if you are just doing your daily job and not writing the next Facebook in your basement.

How can we still squeeze good performance from our programmer’s favorite organ?

Problem definition

Goal:
Great mental performance for development tasks

Desirable Condition:
Focused & Productive Brain

Main obstacles

1. Unclear goals – brain confusion with lack of certain direction and understanding what to do
2. Dissipated Time – absence of dedicated committed time for the task opens rich possibilities to avoid hard work and procrastinate.
3. Multi-tasking – running several activities in the same time significantly drops your IQ.
4. Insufficient energy – tired, emotionally overwhelmed or indifferent brain is not productive at all
5. Distractions – frequent interruptions do not allow to immerse into the task
6. Mismatching task – too boring or challenging tasks prevent full brain engagement
7. Brain overload – complex, dull or voluminous information inhibits your brain operational abilities.

There are three elements of your performance

1. Tasks – what should be done.
2. Time – how long and what way you work on your tasks.
3. Mind – mental energy and abilities to get tasks done.

How to become Top Performance Master

A. Master of Tasks – Know Your Goals and Choose Tasks Wisely

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.”

-Mark Twain

Tasks define your work and results. Your performance and reputation (and quality of life in general) ultimately depends on tasks you chose. Make wise choice – you can work hard long time and achieve little or get amazing results in the short time.

Important considerations:

1. Know your goals, priorities and abilities – what you want and can achieve in reality.  Focus on the most important high return goals and tasks. Put away low priority stuff – don’t waste your time and valuable energy.  Delegate what possible to others.
2. Design your work for high speed? Break down goals to small and tangible tasks that have clear outcome and can be done in less than 30 minutes. Avoid working on big uncertain scary tasks that cause fear, disorientation and stomach upset.
3. Choose to work with ready tasks. Avoid bottlenecks or waiting – have all information and tools ready, otherwise postpone an unready task and prepare ground for subsequent triumphal completion.
4. Keep backlog for all stuff that you should do later to free your brain from worries about forgetting and let it focus on immediate tasks. Use systems as GTD
   or
   Kanban to manage your mental tasks backlog.

In short, be pragmatic to be fast and furious – work on important stuff and avoid working on tasks which are not ready, big, uncertain, mismatch your abilities and can be delayed or avoided.

B. Master of Time – Run Powerful Sprints

Time is the most precious and elusive element of your performance. You won’t get much done when time is insufficient or used poorly.

Important considerations:

1. Plan and prioritize first to establish clear path for achieving your goals. Beware – planning uses a lot of energy and meet serious resistance from the brain.
2. Start with the most important tasks! Your best quality thinking lasts only for a limited time.
3. Schedule and commit time for the sprints. Have enough dedicated time to accomplish something meaningful, but keep sprints short to avoid running out of energy and interest.
4. Do one conscious active task at a time. Brain has very limited working memory and processing capacity (about 4 items). Multitasking seriously reduce your IQ and performance as brain can work only in the serial mode.
5. Start your sprint on the full power and eagerly run until the end of your committed time. Put yourself in the champion mindset to achieve your goals. Forget about everything else and run, run, run…

According a recent biography of Henri Poincaré,

Poincaré … worked regularly from 10 to 12 in the morning and from 5 till 7 in the late afternoon. He found that working longer seldom achieved anything …

Poincaré made tremendous contributions to math and physics. His two-hour work sessions must have been sprints, working with an intensity that could not be sustained much longer.

C. Master of Focus – Remove All Distractions

Distractions kill your performance. Be serious about your time – don’t let others and yourself to spoil, skip or delay your committed time. Remove distractions to keep your powerful sprint.

Important considerations:

1. Commit to the task and sprint time and nothing else – don’t give chances for your social curious easy-to-distract brain to engage in any unrelated but tempting activities.
2. Isolate. Turn off phone, Internet, Facebook, Twitter, news – cut your connections to the World, friends and colleagues (exception is Pair Programming).
3. Recognize and remove distraction early – internal (dreams, stress) and external (interruptions).
4. Take unrelated pressure off – concentrate on work and leave all troubles far away.

D. Master of Energy – Charge Yourself

Thinking is an energy hungry process. You need a lot of energy and fresh brain to think well. In addition, you need high level of arousal and pull to achieve the top mental performance.

Important considerations:

1. Clear mind – strive for empty fresh ready brain before starting a sprint.
2. Entice yourself – bribe yourself or adjust perspective to make tasks appear interesting, exciting and alluring.
3. Scare yourself – start adrenaline rush (with reasonable level of stress or fear) – why the task is important and threatening if not finished.
4. Watch the time limit – keep pushing to finish within allocated time

E. Master of Flow – Achieve Peak Mental Activity

Flow is a mental state when you is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity

Flow state is not spontaneous – few conditions should be in place:

1. Clear set of goals – adding direction and structure to the tasks
2. Skills should match challenges – task is not too boring or challenging, just right to have confidence and interest
3. Clear and immediate feedback – helps to adjust performance to stay in the flow state and keep moving in the right direction

Therefore, the ideal task for programmers should

• have clear challenging end-state reflected in a working piece of software (verified by unit test, user interface or other means)
• done in small steps as you should continuously learn what works and correct approach

F. Master of Thinking – Use Right and Left Brains Right

Simplify and structure information for left brain and load right brain with visuals. Minimize exhausting brain work to maximize performance.

Important considerations:

1. Operate in small chunks. Brain has the limit on the number of concepts it can hold and manipulate in working memory (3-4). Ideally, you want to work only with the few most important ideas.
2. Keep focus on core problems – identify what is out of scope, too difficult or not ready for processing to avoid wasting your brain energy.
3. Work with simple concepts – your mind will operate better if you reduce complex ideas to just few simple.
4. Write down and visualize ideas? Interact with information, do not store – overcome mental and processing limitations.Turn on your right brain intuition, visual and parallel processing capabilities.

G. Master of Control – Monitor, Maintain and Improve Your Mental Performance

You have to put special effort to sustain top performance for a series of day sprints.

Important considerations:

1. Pay attention to your mind – what you think, emotions, stress, level of energy, fatigue. Should you stop, reset or change direction? Correct how you work to return to performant focused state.
2. Stay fresh during several sprints. Mix heavy with easy or completely different mental activities – to get rest and recharge. A new kind of task can raise interest and spark energy again.
3. Have mental breaks when necessary. Keep control – do not over relax or overburn yourself too much.

Learn yourself and improve your task execution system

1. Learn how to focus better on hard (mentally demanding) tasks
2. Increase performance on repeating tasks, consider automation
3. Reflect, review, regroup frequently

Final Thoughts

Controlling your powerful, but unruly brain and simultaneously managing external world demands is really hard. But this is the way to achieve Top Mental Performance & Great Results with three key elements – Tasks, Time and Mind

Fortune favors the prepared mind.  – Louis Pasteur

Resources

Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.

Agile Development

Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.

User Story is done when it is:

• Code Complete and Working
• Tested
• Accepted by customer

Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.

The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.

However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.

Market-oriented Development

Lean startup movement, Facebook and Toyota have some interesting ideas that can be applied to the development process and improve chances of software market success.

Market-oriented Development has three distinctive characteristics:

1. Requirements goal is to maximize learning, reduce risks and uncertainty
2. Build-Measure-Learn Feature Cycle
3. Delivery Mechanism – Continuous Deployment and Flow

1. Requirements – Business Model Canvas and Customer Development

Maximize learning (about what’s riskiest) per unit time. Systematically eliminate risks.

– Ash Maurya, Running Lean

Your software system carries more than just technical risks:

• product risk – do you solve right problem in right way?
• customer risk – do you know who has the problem and how approach them?
• market risk – can you build effective business and make money?

Each software system feature (reflected in User Story) has similar risks on the smaller scale. Every new feature is an attempt to improve software system and business. The process should breed successful and eliminate failing features.

Business Model Canvas is an excellent source of requirements – define areas of risks and opportunities to focus on what features should be built next.

Another great source of requirements is Steve Blank’s Customer Development process that helps to discover, validate and create customer’s needs.

The initial result is Minimum Viable Product (MVP) described with User Stories. Developers help to cross a bridge between business models and feasible technical implementation to form MVP.

2. Build – Measure – Learn Feature Cycle

Selected User Stories are transformed into Minimum Marketable Feature (MMF) for the release.

Use Scientific Method
Build features as experiments in proving hypothesis. An experiment is valid when you can definitely measure if hypothesis has succeeded or failed.

Follow Build-Measure-Learn Cycle

theleanstartup.com

MMF Extended Lifecycle:

1. Generate ideas (Theory) with Business Model Canvas and Customer Development – feature should improve business or increase learning
2. Survey (before development) – what are feature chances of acceptance and success (customer interview, surveys, marketing site traps for potential users)
3. Build Feature as Hypothesis avoiding expensive and long effort. Technology is not so important at this stage – inefficient or even manual solutions are ok.
4. Probe (run experiment) with
   • beta testing
   • usability testing
   • flip feature for a limited group
   • A/B testing
   • internal / close preview
5. Measure market success (validate with users, use analytics, get feedback, do cohort analysis)
   • If no clear market success (traction, positive feedback) – hypothesis is not confirmed, refine it
   • Outcome: validated learning – the feature is marketable!
6. Release (marketable feature) to wide audience
7. Adopt and Scale – make the feature reliable part of the core product
8. Monitor and Optimize – improve quality and performance of the feature
9. Improve feature and continue evaluating
   • Is it still good, marketable and usable?
   • Does it still confirm to 80/20 rule?
   • Does it escape over-complication and bloating after rounds of improvements?
   • Should it be replaced with something better and new?

MMF is done when it is :

• Code complete and Working
• Tested
• Accepted by customer
• Proved to be Marketable – users want and like this feature, and it can bring money / increase value

The Market-oriented Developers should target in parallel three completely different goals:

1. Traditional – design a solid system and lay stable foundation for the system expansion and usage
2. Agile – build a simple optimal system that can be adapted for the future changes
3. Market – create a minimum quick solution to prove viability of feature early and reduce product, customer and market risks. Be ready to radically change or scrap unsuccessful features.

Developers work with two types of features: Hypothesis and Core (proved by market). As a result two kinds of development activity streams run in parallel

• Form stable core for proven features – high quality, refactored and optimized
• Build isolated hypothetical features with options to flip or remove completely (without consequences). Lower quality and shortcuts are acceptable. The main goal is to prove the feature with minimal effort and system disturbance.

3. Delivery Mechanism – Continuous Deployment and Flow

Startups that succeed are those that manage to iterate enough times before running out of resources. Time between these iterations is fundamental.

– Ash Maurya, Running Lean

The software team that practice Continuous Deployment should be disciplined, professional and focused. Developers work in advanced mode – frequently release a system woven from features on different life stages instead of rarely releasing big slumps of monolithic frozen codebase.

The Flow

Input

• Business Model Hypotheses
• Core Feature Improvements

1. Develop

• Build in small batches – less disruption, easier to swallow
• Reduce work in progress – focus on features that can be completed and released in short time (otherwise reduce feature scope)
• Eliminate waste – keep only value-added code and activities

2. Test

• QA is the part of the development process, not a separate phase
• Automated Testing and Continuous Integration are core mandatory practices
• Jidoka – no failing tests, zero defect totlerance – stop and fix if a problem arises

3. Deploy

• One click deployment and rollback
• Feature flipper system (e.g. Flickr, Facebook Gatekeeper)
• Integrated Operations and Development – both teams are part of the whole process from requirements to launch

4. Monitor

• Build a Signal System that detects, alerts and recovers software system from errors
• Genchi Genbutsu – Go and See -thoroughly and objectively understand problem before making decisions
• Remove root causes – tolerate unexpected problems only once – use Toyota 5 whys and Kaizen.

This delivery mechanism enables fast product cycles for market validation, refining product and eliminating risks.

Outcome

Three mental shifts:

1. Each Feature should improve a business model or increase learning about it.
2. A new feature is a Hypothesis about solution that should pass Ultimate Marketability Test to become Core.
3. Create lean continuous flow to achieve just-in-time delivery.

A market-oriented team goes beyond regular development practices. Developers are not only building good software system focusing on technology, but they are improving product market chances, and become active contributors in the quest for repeatable and scalable business model.

Isn’t this kind of development the best process for any business?

Books

The main architecture goal is to strengthen and align system ideas, muscles and structures in areas most impacted by stress, changes and expansion.

In short, architecture covers every important aspect of the software system.

A good thoughtful software developer is torn apart by conflicting approaches for architecting complex software system:

1. Heavy upfront system design leads to rigid, costly and over-engineered solutions
2. Ignored business and technical perspectives cause business irrelevance or failure
3. Poor reliability, performance or flaws could kill promising beautiful software system

What is the best approach to build a sound and successful system?

Problems

Let’s consider several architecture challenges that a software team faces during system development.

1. Idealism (assumed known knowns) – mostly theoretical views, lack of practical experience, illusions. We often exaggerate our intellectual abilities to find right solution theoretically.
2. Open problems (known unknowns) – problems or needs without foreseeable solution. These evil inconvenient unknowns could seriously impact the course of the project
3. Uncertainty (unknown unknowns) – low predictability of the future in technology, business and Universe. Many good decisions could turn to be wrong after some time.
4. Over-complication – over-engineering for domain problems because of over-thinking, misunderstanding, lack of information or technical enthusiasm. Over-complication steals development time and increase cost and complexity.
5. Fragility – poor system quality (performance, reliability, uptime, security, etc.). Neglecting quality could cost reputation and harm system success.
6. Complexity – complex structures, unpredictable behavior and states that turn a system into the Ball of Mud.
7. Inconsistency – dissonance of the system approaches and parts; fragmented and incomplete knowledge in heads. Development teams produce incoherent system without coordination of ideas and implementation.
8. Inertia– difficulties to introduce disruptive changes (for business, users, operations). People and established processes resist changes and have inertia that is difficult to overcome.
9. Misalignment – with business goals, existing systems, infrastructure. Building a software system without considering business vision, existing IT landscape is the path to disaster.

Three Architecture Answers

There are 3 useful approaches to Software Architecture that address these challenges:

1. Strategic
2. Technical
3. Evolutionary

1. Strategic Architecture

“Plans are nothing; planning is everything.” – Dwight D. Eisenhower

Question: What are direction, constraints and external factors?

How: dedicated architecture group moves ahead of the main development activities to align ideas for business, development, infrastructure and partners.

Attacks challenges

• Misalignment
• Inertia

Outcome
Strategic Architecture defines a system playing field:

• Vision: system goals, purpose and desired end-state
• Domain: business needs and problems to solve; describe models and processes
• Constraints: budget, time and resources; acceptable system qualities
• IT landscape: existing infrastructure, required integration with internal and partner systems; standards and API
• Coordination: release planning, deployment and all necessary steps to build and operate successful systems.

Approach

• Business Canvas – strategic tool for business models
• Domain Driven Design – implementation of core business concepts
• Enterprise Architecture – organizing logic for complex business and IT fields.

2. Technical Architecture

“Vision without execution is hallucination.” – Thomas A. Edison

Question: How to build a solid well-engineered system?

How: Developers predict (based on experience and preliminary information) possible challenges and future requests and implement architecture elements early (system layers, databases, security, caching) keeping system consistent and meeting required system qualities.

Attacks challenges

• Complexity
• Fragility
• Inconsistency

Outcome
Technical architecture proactively cares about building an excellent engineering solution:

• Technology: technical and development platforms
• Organization: well structured software system, where all elements fit together without excessive dependencies and side effects
• System Qualities: reliability, performance and other quality targets; protection against failures and security threats
• Integrity: consistency in developers heads, their approaches and system implementation

Approach

• Architecture patterns and principles: open-closed, single responsibility, separation of concerns, dependency inversions, etc.
• QA; failure and performance testing
• Pair Programming, code reviews and threat assessment

3. Evolutionary Architecture

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

Question: How to find the most optimal design and adapt the system to unknown?

How: Architecture emerges as a result of iterative development and refining the system for the most important business needs and optimal design.

Attacks challenges

• Idealism
• Uncertainty
• Open problems
• Over-complication

Outcome
Evolutionary architecture grows a system by quickly adapting for new discoveries, changes and feedback

• Quick validation and refinement of ideas
• Optimal design – well-refactored system based on the best development practices and design principles
• Fast learning

Approach

• Agile practices: iterations, refactoring, continuous integration
• Start small with end-to-end simple, but working solution and grow based on learning what is needed and important
• Lean startup with ideas adaptation and validation

Selecting right Architecture Mix

The choice is not what kind of architecture is needed, but what is the right mix

One cannot embrace the unembraceable and deeply focus on all architectural dimensions at the same time. However, you can tailor your approach to your current situation and most pressing challenges.

Right architecture mix will greatly increase chances of your system success!

The software system in the period of active growth is a really wild beast. Excited developers with creative minds and feature obsessed marketers consistently add the fuel to this fire of software creation.

Uncontrollable growth, race for features and engineering wonders sometimes give rise to a monster – a software system bloated with useless features, over-engineered internals and erratic behavior.

At some point, developers stop understanding the system and start fearing it while doing less and less productive attempts to fix and grow it under pressure from screaming users and management.

What is happening during this transformation of the bright promising software idea into a scary monster system?

Here is a complete state diagram of a wild young software system growth:

The root reason of this scary transformation is get-out-of-control complexity. Eventually, Success Loop dries up and Failure Loop takes over and lead the software system to disaster.

What could prevent this pitiful descent and ensure long-term health of the software system?

Here comes Architecture!

The primary goal of the software architecture is taming complexity of the functionally growing software system under physical load from demanding users, harsh environmental impact and psychological pressure from managers. Architecture attacks and reduces effects of the software development Failure Loop.

Good architecture strengthens and aligns system ideas, muscles and structures in areas most impacted by stress, changes and expansion.

Three Architecture Responsibilities:

1. Explain and carry The Theory of the system. Align new ideas and needs with system realities.
2. Guide system Organization. Enable fast growth and modifications.
3. Support required system Qualities (stability, performance, security, etc). Make system behave well.

1. Architecture Carries The Theory of The System

A theory is the more impressive the greater is the simplicity of its premises, the more different are the kinds of things it relates and the more extended the range of its applicability. – Albert Einstein

Creating Software Architecture means building a common theory that explains the software system. It is an attempt to join many fragmented pieces into a package that is consistent and easy to digest for human brains Architecture creates bird’s-eye view on mundane torrent of code details, states and behaviors.

Architecture is the essence of what, why and how of the software system. It is a set of ideas and explanations that allow humans to make sense of the system. A small system require little help to understand. A large complex system requires a lot of explanation – volumes of information, pictures and tales from people who had firsthand account of the battle for the system.

 Concerns

1. Simplicity – fight complexity on every possible level. Simple systems are easy to grow and maintain. More complex system lead to stressed minds and broken hearts.
2. Clarity – tune everything about the system (ideas, design, code, documentation, etc.) for better digestion by human brains.
3. Interpretation – how close the system reflects the business concepts in implementation. Is it direct translation that guides system organization and logic or irrelevant pile of technical ideas?

Methods

1. Domain Driven Development is an excellent approach for translating customer domain into relevant architecture
2. Conceptual models translate vague business ideas into formal description of the problem space.
3. Metaphors and abstractions bring disjointed ideas into coherent whole that is easier to digest.
4. Shared language and domain-driven naming synchronize customer domain and technical ideas.
5. Storytelling, user personas and usage scenarios help to convert overwhelming information massives into easy to remember chunks that are friendly for developer’s brains.

2. Architecture Guides System Organization

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery

The software system is a system (not surprisingly) with elements, structures, connections. All this stuff is a projection of the theory into practice.

Concerns:

1. Flexibility – ease of change without painful struggle, breaking the system and causing unexpected butterfly effects (side-effects).
2. Integrity – alignment and good fit of parts with each other and overall theory of the system that create coherent tight assembly.
3. Preservation – ease of keeping original system intent and healthy organization without hacks and workarounds.

Structure and Dependencies

Complexity and problems are often coming from internal mess and tangled dependencies.

Methods

1. Separation of Concerns – breaking down and taming smaller groups of related elements reducing overall complexity of the system (modules, hierarchies, layers, etc.)
2. Restrain dependencies – reduce elements connections (with isolation) and side-effects (with orthogonality).
3. Generalization – rely mostly on abstractions and interfaces, hide concrete implementation on lower level.
4. Federation of specialized components – favor reusable smaller components with narrow responsibilities to big rigid elements or procedures suited only for one scenario.
5. Design and Architecture patterns are an excellent source of design ideas and their trade-offs.

Minimization

Every piece of knowledge must have a single, unambiguous, and authoritative representation within a system. – The Pragmatic Programmer

Producing more code inevitably increase complexity and reduce mental control. Architecture helps to focus on keeping clean minimal codebase for needed functionality.

Methods

1. Use 3d party – integration with existing libraries, components and services could significantly reduce system codebase and required effort. Certainly, there are some risks and shortcomings.
2. Maximize reuse & follow DRY – avoid duplication and cloning
3. Refactoring – continuously improve system design to keep it in minimal, optimal and clean state
4. Abstraction – synthesize system concepts and elements to avoid different solutions to similar problems.

Extensibility

A system should be open for extension but closed for modification – The Open Closed Principle

A software system should provide an easy way to extend and add new features without invasive surgery on already tested and working parts. Architecture helps to consciously establish this way.

Methods

1. Published API – stable and officially endorsed set of interfaces that open ways for safe and supported way to manipulate a system.
2. Extension points – clear definition of intent to extend through interfaces, inheritance, etc.
3. Pluggable architecture – allow to add elements in formalized way with open framework infrastructure and component specifications (WordPress, jQuery)

3. Architecture supports System Qualities

Better to be rich and healthy than poor and sick. – Russian proverb

Correct, secure and responsive system is much better than buggy, vulnerable and slow. However complex software systems under heavy unpredictable usage could easily degrade to a pitiful state of sick unruly monster.  Proper architecture could prevent this bad behavior and keep the system within borders of correct, well-performing and stable state in most situations.

There are three important characteristics: Stability, Performance and Protection.

Stability

1. Resilience and self-healing – ability to survive and recover from surges and failures
2. Elements packaging and release management – the way to package and release elements to avoid disruptive shocks to the system on updates.
3. End-to-end testability, automated testing and sandbox environments – ability to completely simulate the system live behaviour in short time before release into wild
4. Freeze published interfaces and provide legacy support for dependant subsystems
5. Monitoring,  signal system and self-assessment – promptly alert when something goes wrong
6. Operational manageability and control – easy to manage and configure

Performance

1. Optimize processing, data flows and storage – achieve right balance between fresh data and cache, throughput and latency, processor cycles and memory.
2. Scalabiliy – ability to scale the system with increased load (replication, distribution, partitioning / sharding)
3. Elimination of bottlenecks and easing of stress lines

Protection – from threats, disasters and surges

1. Security, proactive defence, threat assessment and detection – resist hackers and vandals
2. Backups, standby reserves / redundancy, multiple locations – avoid single points of failure and have ability to fully restore in case of bad crashes and losses.
3. Prepare for worst – closely monitor points of failure; simulate and train people to recover from disasters.

Raising Architecture

As any theory, software architecture could be bad or great, helpful or misleading, clear or convoluted. Architecture directly impacts the fate of any non-trivial software system.

The real architecture is not a static theory or prescription how to build the software system. This is a theory that emerges with the growth of the system, refined by discoveries and failures. Developers adapt this theory to fit harsh realities of the external world, confusing requirements, management pressure and user demands. And in return, good architecture helps to keep the system consistent, stable and controllable over the time.

The main benefit of architecture is ability to effectively grow the system that embrace demands, bring market success and makes people happy. Tame your software monster and make it obedient machine!

What does a customer wants?

Usually your customer wants to know a simple thing – when your team will deliver working software based on agreed requirements. They naively want to safely bet on highly uncertain future outcome – delivery of the complex never created before system that completely fulfil their dreams.

The customer wants reliable McDonalds experience, but with a little tweak – they want to hand in their own exclusive menu, often created by people who don’t have any idea how to cook.

In short, the customer requires creative flexibility of Cooking Master Chef fortified by ability to predictably deliver hamburgers as McDonalds.

But, is it possible in our development reality to chase two opposing goals – Predictability and Flexibility in the same time?

Predictability vs Flexibility

The best way to achieve predictability is standardization – formalize process, nail-down rules, follow and optimize them mercilessly. However, standards have negative effects – lower morale, inhibited creativity, reduced flexibility and slower response to changes.

Rapid adaptation is the best way to to be flexible – eagerness to quickly regroup and self-organize to address new challenges and creatively solve new problems. However, constant changes and creativity sparks lead to unpredictable and ad-hoc results without much opportunity to stabilize and optimize delivery.

Standardization is a crystallized answer to past events – how to repeat effectively something that was solved before and proved to work.

Adaptation is the response to current events – how to embrace unforeseen requests, challenges and events.

Standardization has own cost – processes and rules should be maintained, reviewed and optimized otherwise they will become source of overhead, rigidity and frustration. But if there is no standardization, lessons and best practices could be lost or not followed.

It is difficult, but possible to chase these two contrary goals in the same time. Build standards to solve repeating problems and optimize recurring activities. Adapt to meet new challenges.

Team Maturity Matrix

Development teams have different capabilities to strike both predictable and flexible delivery.

• Amateurs – do even simple things… unpredictably
• Explorers – capable of solving complex non-standard problems, but cannot guarantee time and budget (Ph.D guys)
• Mechanics – very efficient with standard solutions, but struggle with new stuff (anal-retentive guys)
• Regulars – predictability of delivery lowers for more challenging problems
• Strike Force – deliver reliable results for any type of problem

Any team should grow from Amateur status, but rare team could become Strike Force that mastered both – predictable and flexible delivery. Than what direction of growth to choose? It depends on nature of projects and problems the team tackle.

Finding sweet spot

Predictable delivery requires reduced variations in development process: uniform, ordered and consistent approach with focus on high efficiency.

Flexible delivery requires increased variations in the process: enabling more options, wider range of responses to improve fitness in changing environment.

These 2 goals could compliment each other. Predictability (with standardization) could bring consistency and stability in volatile and evolving development ecosystem. Adaptation helps to improve and find better standards and ideas for established processes.

So, can team deliver as McDonalds, but using exclusive menu? Yes, if they not only excel in programming, but also excel in the way they work – persistently re-evaluating approaches and improving both predictability and flexibility.

There are three simple requirements for the team

1. Follow standards (minimal, adhering to principles)
2. Challenge standards (not relevant, rigid, impeding, excessive)
3. Introduce and Improve standards (from lessons learned, best practices, enhancing flexibility and value stream)

And you will build powerful development machine that continuously transforming to embrace fluid reality while keeping steadiness and predictability as McDonalds.

Hit the road

A. Life Challenges and Systems

Your life continuously presents new challenges. And your success directly depends on your ability to meet these challenges. You can choose various approaches – react on problems as they come, appeal to supernatural forces or seek for advise.

But how many times

• you didn’t understand why thing happen and what to do
• you found that reality and challenges are more complex than they seem
• your solutions create new problems and make things worse

Welcome to the messy world of complex systems that encompass your life and compose our Universe.

1. You can be the master of your life if you can understand and influence systems involved in your challenges. That means that you should become the Master of Systems Thinking.

• what problems should you solve?
• should you reframe the problem?
• what would be an ideal solution?
• what systems should be considered?
• what belongs to these systems?
• what is out of scope?

2. Model – come up with a model that describe the problem and a preferable solution

• what is the structure of the involved system?
• what are goals and known system behavior?
• what system parameters can be influenced?
• what can be a solution – the system of responses and actions?
• what outcomes can be predicted?

• target feedback loops – amplify stale beneficial, minimize unstable harmful feedback (e.g. increase customer feedback, reduce team interruptions)
• stability – to remain unchanged, system should change: the system should effectively respond to various situations – even unknown!
• interconnections – you cannot change only one thing and you cannot change everything.
• beware of opposing reaction – The System always Kicks Back (Le Chatelier’s principle)
• avoid new systems – they always cause new problems
• evolve existing working solutions – it is better strategy than introducing new complex solutions
• the first solution is imperfect – be ready to scrap it after learning and building better models
• probe / stress test – try to run trial to assess impact of the changes before committing to intervention
• design signal / sensory systems for measuring result of intervention and establish clear information paths

4. Review results of intervention

• how well did intervention work?
• did you meet challenge or at least improved situation?
• did you create new problems?
• are you sure you’ve got objective and full information?
• have you got feedback from all participants?

5. Learn – analyze the gap between model and reality. Why did it work this way?

• studying mistakes and bugs
• evaluating prior predictions
• assessing assumptions
• dispelling delusions and biases
• exposing flaws of the model
• detaching yourself from the system for better perspective
• realizing real system goals, functions and interests (for humans)

Go to step 1 of the dance until you like results or run out of time and energy.

Finally remember: “Today solutions are tomorrow problems” [Fifth Discipline]

E. Circle of Influence

5. Focus on important challenges that you can really meet.

Proactive people focus time and energy on things they can control (Circle of Influence) instead of reacting to or worrying about conditions over which they have little or no control (Circle of Concern). – Stephen Convey

1. You can be the master of your life if you can understand and influence systems involved in your challenges. That means that you should become the Master of Systems Thinking.
2. Ability to predict and influence future is the most important skill of the Master of Systems Thinking
3. Inability to understand systems is the most serious obstacle for the Master of Systems Thinking. Unfortunately, most systems are complex and the master will not understand them.
4. You can still master complex systems if you realize that you cannot change complex systems as you wish and get predictable results.
5. Focus on important challenges that you can really meet.

You cannot change Universe laws and can barely affect economical situation, but you can make a difference for your projects and life by becoming the Master of Systems Thinking and mastering systems under your control.

Seasoned project managers will tell that delivery of software is result of many trade offs. The main trade off is between Time (when project will finish) and Scope (how much will be done). This post will show that using right tools you could gain improvement for both variables.

While it is possible to create orderly step-by-step process for increasing productivity of software teams, it will never be ideal – too many variations and situations will hinder it usefulness. I believe in set of useful tool that could be combined to craft custom optimal solution.

Strategies

There are several strategies that lead to increase in productivity – how many units of scope software team can produce within fixed time.

1. Increase Capacity (Capacity) – increase capacity by hiring more people or increasing work hours
   • productivity is increased as result of more resources and hours available
2. Improve Value Stream (Value) – increase added business value on each step and reduce waste and overhead
   • productivity is increased as result of optimized delivery of value
3. Adaptat to Reality  (Adaptation)– learn from practice and mistakes, validation of ideas by reality, adapt to changing situation
   • productivity increased as result of early corrections and improving how things are done
4. Empower Individuals (Individuals) – boost people knowledge, skills, morale and focus
   • productivity is increased as result of higher individual performance and motivation
5. Enhance Communication (Communication) – improve communication and mutual understanding inside and outside of the team
   • productivity is increased as result of availability of necessary information, clarity of what should be done and exchange of ideas for implementation
6. Organize Better (Organization) –  structure team and assign roles for better coordination and decision making
   • productivity is increased as result of better decisions and focus on important areas
7. Expand Expertise (Expertise) – increase range of skills and services offered by team
   • productivity is increased as result of better execution of necessary project activities
8. Scale Externally (Externality) – outsourcing and involvement of external communities
   • productivity is increased as result of involvement of more people outside of team
9. Tame Complexity (Design) – manage complexity and provide simple and well designed solutions
   • productivity is increased as result of reducing complexity burden on software development
10. Preserve Quality (Quality) – use defensive tactics to ensure high quality
    • productivity is increased as result of preventing system flaws and reduced effort to fix bugs

• People-oriented – people are the creators of software and have major effect on output
• Process-oriented – the way how people work has significant impact on outcome
• Development-oriented – development practices and approach to the system implementation matters a lot

People-oriented tools

Strategies: Capacity , Expertise , Communication ,  Organization

New people increase volume of possible work within the same time and new expertise increases range and quality of tasks. However, the increase in output is not linear and quickly diminishes, because more people cause communication and coordination overhead. In addition, compensation increase make this tool expensive and less attractive.

Resources:

• Methodology and Team Size, Alistair Cockburn
• Team Size Matters, schmula

2. Motivate

Strategies: Individuals , Quality

Happy motivated people are more productive, focused and concerned about quality and end result. While there is no common receipt for each individual, I believe there are some strong motivators: interesting and meaningful work, fair compensation, control over own tasks and outcomes, ability to learn and professionally grow, comfortable workplace and adequate tools, empathetical and caring management and so on.
Daniel H. Pink in Drive thinks that people are motivated by three elements:

• Autonomy: People want to have control over their work.
• Mastery: People want to get better at what they do.
• Purpose: People want to be part of something that is bigger than they are.

• Professional Growth

Tips: Motivate individually, but set also group targets to encourage cooperation

• Drive, Daniel H. Pink
• The Ideal Software Company. Utopia?

3. Professional Growth

Strategies: Individuals , Expertise , Quality , Adaptation

Software professionals should learn a lot to become productive and proficient. People learn in several ways and learning from mistakes is the most memorable, but expensive way. Learning by self-study, formal training and coaching by experienced colleagues are more effective ways. Encourage and direct learning to grow high performance experts and team. And certainly, continue learning as much as possible from mistakes and practice.

• How to Become an Expert. Top 7 Qualities
• How to Become an Expert. The Effective Way

4. Overtime

Strategies: Capacity , Individuals , Quality

Nobody recommends involuntary overtime for a long time as benefits will disappear quickly when a stressed team lowers quality and starts breaking apart.

5. Right leaders

Strategies: Communication , Organization

Good leaders jell teams, align people with goals, boost energy and remove barriers. Leaders vary from commanders to visionaries and each style has merits under specific circumstances. Right leaders are essential for the project success.

Tips: Adjust leadership style to situation

• What is The Best Leadership Style for The Software Team?

Strategies: Expertise , Organization

A software team requires range of skills and involved in different activities to achieve end goal – implemented software system for customer needs. Beyond software implementation the team deals with a customer domain, company vision, market demands, technologies, operation environments and other project aspects. The team is involved in research, analysis, coordination, design, architecture, usability, testing, deployment, hosting and other activities. Therefore team players should be able to play different roles and have expertise to cover various aspects to ensure good end results.

Resources:

• Why specialization in Software development is bad for business

Strategies: Capacity , Expertise , Externality , Organization , Communication

Tasks and challenges should match skills and experience of team players. It doesn’t make sense for backend developers to convert Photoshop files into html or conduct marketing research and focus groups. If team cannot afford to hire a permanent specialist, they should try to find professional mercenaries who will do work faster on higher quality level.

Strategies: Individuals

Flow (or Immersion) is a state of mental focus so intense that awareness of the real world is lost, generally resulting in a feeling of joy and satisfaction. When learning and tasks are too easy, people become bored. If they are too complex they become stressed and frustrated. Flow happens when perception and understanding are challenged near capacity without being exceeded.

• ability to focus
• clear goals
• immediate feedback
• control over actions, activities and the environment

• Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi

Strategies: Quality , Organization , Individuals

Few people will be always disciplined no matter what and few will always violate rules. Majority are context sensitive – relax than discipline is low and work hard when discipline is enforced. Build a minimal set of rules approved by majority and stick to these rules.

Resources:

• Lost Personalities: How our company alters us

Process-oriented tools

10. Increase feedback and early practical use of ideas

Strategies: Adaptation , Quality , Value

Reality is complex, fluid and unclear. Many assumptions and plans quickly go bust. The process that has built-in mechanism for signaling problems and self-correction is the most effective. Rapid feedback is the core part of such process.

Tips: Iterative development is one of the best examples of the process that relies heavily on feedback.

11. Build alignment

Strategies: Communication , Organization

People jump significant gaps to understand each other – sometimes without much success. Clear vision, smart priorities and honest evaluation allow team players moving in unison and enforce each other. Good understanding focus people on right goals and reduce wasteful activities. Communication and trust are important for alignment.

• vision – project direction and top-level goals
• interests – mix of personal, customer and companies interests (sometimes conflicting)
• understanding – clarity about what others mean
• trust – confidence in other people intentions and promises

12. Integrated decision making

Strategies: Communication , Quality , Adaptation

See Also:

• Self-organization

As project progresses you will find problems, wrong assumptions and challenges. You will have better experience and understanding. Even brightest ideas, best practices and excellent analysis and design could become outdated and ineffective. Continuously look for improvements, eliminate waste and bottlenecks.

Resources:

• How to rescue failing software projects: The Toyota Way
• Theory of Constraints
• Kaizen

Strategies: Individuals , Quality , Value

Highly productive team shouldn’t waste time on routine or non-core activities. Routine work should be automated and non-core work outsourced or covered by external components. The team should focus on high value-added distinctive work for business and application domain – this will bring maximum business results with minimal development effort.

• system thinking
• understanding what really matters and what are limitations
• broad vision and out-of-the box thinking
• knowledge of environment, context and system outside relations
• synthesis of concepts, information and experience

Strategies: Capacity , Expertise , Externality , Organization

Strategies: Value , Communication

You can better understand and change scope of application if you actively work with customers and become partners

• establish ubiquitous language – for better understanding of ideas and translation them into code
• tap into experience and get better insight for business domain and processes
• transform ideas – simplify and find better alternatives

• reducing scope
• simplifying solutions
• finding good enough alternatives

• Pareto Principle
• Ubiquitous Language
• Software Development is The Flow of Ideas. The Rest is Secondary

18. Select Right Process Flow

Strategies: Organization , Value

Select most optimal process for creating value.

• real-time flow –  immediately push tasks for implementation (continuous development flow for highly organized co-located teams)
• pull systems (Kanban) – pull tasks when previous batch is finished and the team is ready to continue (iterations and backlog)
• schedule the workload (Heijunka) – create schedule for contributors with limited availability (outside consultants or shared specialists as designers)

Tips: Use different flows for distinct stages of software creation. For example, a team process can internally use real-time flow, with external teams – Kanban and with consultants Heijunka.

Resources:

• The Toyota Way and Development Process

19. Self-Organization
Strategies: Communication , Individuals , Adaptation , Value

Tips: Not every team can self-organize – it requires maturity. And loss of direct control could be a problem for management if a project departs from company strategy and desired parameters (as budget, standards, resources).

• What is The Best Leadership Style for The Software Team?
• Organizing Self-organizing Teams
• Agile Self-Organizing Teams

Development-oriented tools

20. Increase reuse

Strategies: Design , Quality , Adaptation

Reuse code  (components, libraries, solutions) as much as possible to speed up development and minimize code base. Reuse will bring familiar tested solutions and prevent frequent re-inventions of the wheel.

See Also:

Tips: Design for reuse requires skills and time. It is easy to overly complicate the system by pursuing reusable code. Evolve and refactor code to achieve practically good reusability. Sometimes custome solutions are lighter and better suited for specific purposes than generic and reusable.

21. Generalize and Simplify
Strategies: Design , Quality , Communication

Complexity and poor understanding of the system is one of the worst problems in development. Design, code and concepts should be as simple as possible and clearly understood by the team. Simplicity and clarity are difficult to achieve and require special effort. It is much easier to produce convoluted over-engineered solution for complex problem (Ball of Mud) than simple and elegant solution.

Tips: Great design achieve simplicity by abstracting numerous details into simple concepts in process of solution evolution and learning from implementation.

• Big Ball of Mud, Brian Foote
• 11 Laws of The System Thinking in Software Development
• The Elements of Pragmatic Programming Style. Approach.

Innovation is expensive, uncertain and leave you with custom solutions on your own for support and future development. Piggyback on actively involving products, especially for non-core problems where good and proven solutions are available.Tips: Innovate to gain business advantage or solve serious technical challenges if you have an outstanding team and well-defined problems.

Resources:

• Should An Effective Developer Innovate, Imitate or just Integrate?
• Selecting The Best Strategy for Software Teams: Retreat, Evolution or Revolution

23. Domain Specific Design

Strategies: Design , Communication

Keep technical ideas and code concepts close to the customer domain. You will achieve consistency, better sync between system and business concepts. You can easier translate customer ideas into the system and customers will understand your implementation better.Tips: Domain Driven Design is one the best approaches to achieve synthesis of technical and business ideas for complex domains.

Resources:

• Domain Driven Design, Eric Evans
• The Secret of Building Effective Software Systems
• The Elements of Pragmatic Programming Style. Composition.

24. Evolution

Strategies: Adaptation , Value , Design

Start with the simplest primitive solutions, enforce early use and seek for feedback. Adjust and improve design before continuing adding new features. Look for better ideas and abstractions. Delay fundamental design decisions until you are confident about system development direction and validated ideas on practice. Do not over-engineer and add unnecessary features.

Tips: Evolution main deficiency is slowness. Modern businesses often don’t have time for many improvement cycles – they want results now.

Resources:

• What can Software Development learn from Biological Evolution?
• Ideas in Software Development: Revolution vs. Evolution. Part 1.

• How a beautiful software system becomes Frankenstein

25. Open architecture and API

Strategies: Externality , Design

Open your solution for external developers who can extend and add more useful features. If you are lucky, you will get much more functionality than you can build internally while still controlling a core solution (iPhone is a perfect example).

Also Open API (convenient and supported by good documentation) give developers eligible ways to interact with you system without hacking or completely ignoring it.

Tips: Once Open API is used it becomes liability – next design decisions will be affected by compatibility and legacy concerns.
Resources:

• API

26. Follow Design Principles

Strategies: Design

Some of design principles

• You should be able to extend system without modifying it
• A class should have one, and only one, reason to change
• Depend on abstractions, not on concretions.
• Make fine grained interfaces that are client specific.

Famous design patterns are built around these principles. Follow sound design principles to build flexible, easy to expand system.

Resources:

• Principles of OOD, Rob Martin
• The Elements of Pragmatic Programming Style. Approach.
• The Elements of Pragmatic Programming Style. Composition.

27. Shared Code, Ideas and Standards

Strategies: Design , Expertise , Communication , Quality

The team should collectively own code and pursue consistency and use of best practices. Otherwise the system will become clash of isolated impassible code islands – scary for people who didn’t build them. Share code and learn from each other to build outstanding system with high quality and integrity of every component.

Tips: Pair Programming is one the best ways to share code, ideas and best practices
Resources:

• Collective Code Ownership
• Pair Programming

28. Use Better technology and tools

Strategies: Individuals , Design , Value

Tips: Obsession with new technologies and race to use them is dangerous for project. Keep sanity until new technology is proven to be beneficial

• http://www.sdtimes.com
• http://www.computerworld.com

Guide for increasing team productivity

Questions

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

1. 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)
2. 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)
3. Innovate and create new solutions or make significant improvements to existing approaches

	Integrate	Imitate	Innovate
Time to market	Fast, if effort to integrate with other system components is low	Slow, but predictable, if not many hidden pitfalls or adaptation problems are encountered	Unpredictable as any innovative work
Cost	Low, if components are reasonably priced and not much integration work needed	More expensive and depends on complexity and adaptation effort	Unpredictable
System integrity (with system architecture and environment)	Acceptable if new components don’t screw and over-complicate core architecture	Good, if developers adapt ideas to existing architecture	Solution is built to match core architecture and customer needs
Required Expertise	Not much specialized expertise is required, usually external support is available for integration	Good developers can effectively adopt good ideas that are explained well	High level expertise, creativity and specialized knowledge are required for good innovative solution
Control over code and future development	Little control and you are on mercy of external developers	Good control if ideas are applied well and not over-engineered	Full control
Competitive advantage and uniqueness	Not much for the standard solution that many can use	Depends on quality and creativity in adaptation	Innovation is an excellent opportunity to gain advantage
Maintenance, support and improving capabilities	Work is outsourced to dedicated external developers who fix, support and improve the product	Your effort is supported in original source of ideas if you are lucky	Completely your own effort
Learning curve, tacit knowledge, help	Usually supported by help, tutorials, training and community involvement	Partially supported by original source, however can drift far as the result of internal implementation	Should be covered by you to enable effective support and future development by existing and new developers

(*) 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

• 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

1. Understand purpose of the system, essence of customer needs and desired outcome
2. Break downthe system into components and research if
   1. standard solutions exist (for integration)
   2. implementation ideas exist (for imitation)
   3. innovation is required
3. Can you change needs and requirements? Transform customer needs and architecture ideas to minimize development effort
   1. by moving from innovation to imitation strategy
   2. by moving from imitation to integration strategy
4. Evaluateeach component from the system and business perspective
   1. 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
   2. Should you still go with innovation because of unresolved contradictions, challenging and unmet needs?
5. Build prototypes clearly separated from mainstream development to confirm selected strategy

Becoming an effective software developer

1. 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)
2. Learn concepts and language of your business domain to be able to understand customers and shape their needs together
3. Enhance abilities to find and brainstorm alternatives (improve techniques, make them essential part of your process)
4. Become an expert in Google search and fast evaluation (no kidding, these skills become very important for any modern developer)
5. 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)
6. Develop a holistic view and knowledge of the system, infrastructure and environment (understand subsystems, connections, integration options and trade-offs)
7. Keep up with latest software development trends, technologies and approaches (subscribe to blogs, magazines and other sources)

1. Achieve deep specialization in your core technical area and business domain (extensive experience and deep knowledge are great assets for innovator)
2. Continuously develop creativity and problem solving (the post about creative problem solving)
3. Enhance architecture and fundamental programming expertise based on own practice and ideas from others
4. Master Evolutionary and Domain Driven Design