Recently I’ve been thinking that Software Development is a game. The goal of this game is to discover and implement the best solution for customer’s needs. There are other important goals as making money, empowering business or keeping people happy, but they matter less for the purpose of the game.

Read full post >>

My wife worries about me. She worries when I’m staring at the monitor with the strange text for hours – sometimes desperately, sometimes in excitement. She worries when I skip movies, ignore parties and talk with my computer. She worries why I’m so excited about such boring activity as programming even outside my work. She shouldn’t worry – there are few good reasons to love programming. I want to take an opportunity to share these reasons with all non-programming spouses over the world.

Read full post >>

From the first sight biological evolution looks too unpredictable to have any value for the constrained software development. We just don’t have time, money and resources for these wild experiment, unlimited trials and errors. It really seems that Nature could learn from us how to make things fast and effectively.

However, there are some principles that helped evolution to come up with amazing and efficient designs that made life flourishing on the Earth. This post will explore what software development could learn from biological evolution. See my previous post for the review of evolution concepts and mechanisms and how they could be applied to software development.

Read full post >>

Software Evolution is similar to a Bible Story: we, software creators, have a plan and goals and pursue them to create the perfect solution. We carefully select and add new features according to our grand design. We try to keep design clean and optimal. Things sometimes go wrong and the software system goes berserk, but we intentionally intervene and fix the problems to continue fruitful functioning of the system.

Biological Evolution is a different story: chaotic raise and fall of different species, without any plan and goals. New traits and variations appear all the time and many are useless or even harmful. Small modifications accumulate over time, cause significant changes and emergence of new species, better adapted for the evolving world. Survival of individual organisms and species is the matter of chance, pressure from environment and competition with other organisms.

Intentional growth of software versus chaotic evolution of organisms… Do they have anything in common?

Biological Evolution

In biology, evolution is the process of change in the inherited traits of a population of organisms from one generation to the next.

Species - a group of organisms that can reproduce with one another and produce fertile offspring.
Population – a localized group of individuals belonging to the same species.
Traits – particular characteristics of an organism.
Genes -portions of DNA molecule, which control inherited traits.
Genotype - complete set of genes within an organism’s genome.
Phenotype - the complete set of observable traits that make up the structure and behavior of an organism. These traits come from the interaction of its genotype with the environment.
Variations – the variation in phenotypes in a population reflects the variation in these organisms’ genotypes.

Most of the genome of a species is identical in all individuals of that species. However, even relatively small changes in genotype can lead to dramatic changes in phenotype: chimpanzees and humans differ in only about 5% of their genomes.

Read full post >>

I can’t wait to share this simple secret with you right now.

The Secret: Effective Software Systems are the systems that easy to understand and operate with human brains.

Programmers are more productive with effective software systems. Programmers can better learn and grow these system. Programmers have less problems, work faster and make better decision with them.

Now, you can avoid spending time reading this post if you already know this secret and you know how to avoid building the software system that:

• almost impossible to understand in reasonable time
  
• has confusing and convoluted swamp of logic and structure
• scary to change as nobody has any clue what will be broken, but sure that it will be broken
  

If you are still interested, lets find out what makes software systems effective.

Software Development is a pure mental endeavor (except typing on keyboard) that includes 3 main activities:

• Understand - learn and know system concepts and implementation
• Evolve - build, modify and support growth of the system ideas in the code
  
• Share - communicate and exchange ideas about the system

Programmers should care about 7 areas to make the system better suited for our brains:

1. Knowledge Creation and Retention – parsing, memorization and comprehension of the system ideas
   
2. System Organization – elements, relations and structure in the system
   
3. Sustaining Emerging Order – support evolution of the system and gain control over chaos
   
4. Minimize Noise and Purify – avoid adding unnecessary stuff to the system
   
5. System Discovery and Learning – making sense of the system
   
6. Mental Models – our internal explanations for how things are working in the real system
   
7. Shared Knowledge – ideas exchange, reconciliation of opinions and creation of mutually enhanced knowledge.

Read full post >>

“Ruin in community is not caused by witches with broomstick but it’s something that starts in people’s heads.” – Prof. Preobrazhensky (Michail Bulgakov’s “The heart of a dog”)

The newborn software system looks beautiful inside after the few weeks of development. Several talented programmers put their souls together into this amazing software idea. But week after week the system become older and uglier. It could still look exciting for users, but the system rots inside. It is much more difficult to modify, it breaks often, development time and cost soars. Programmers become scared to work with it. The system becomes Frankenstein. Why could it happen?

Three reasons

There are hundred objective reasons why it could happen – complex technology, changing customer needs, management pressure, time to market and many more. But some teams still deliver a good system under these conditions. And some teams cannot deliver even in the most favorable conditions. Why?

Degradation of the system starts in the people heads and there are three main reasons:

1. Incomprehension – developers don’t understand the purpose, ideas, design or technology behind the system
2. Inarticulateness – developers unable to express ideas through clear and effective architecture, design and code
3. Inconsistency – developers cannot act consistently or don’t care about the system

Read full post >>

Thought-provoking and interesting author Nicholas Carr has published a new article in Financial Times, where he expands on his ideas about transformation of IT services into utility. He compares IT with electric power generation 100 years ago:

Like data-processing today, power generation was assumed to be an intrinsic part of doing business. But with the invention of the alternating-current electric grid at the turn of the century, that assumption was overturned.

Suddenly, manufacturers did not have to be in the power-generation business. They could run machines with electric current generated in distant power plants by big utilities and fed to their factories over a network of wires. With remarkable speed, the new utilities took over the supply of industrial power. Scores of private power stations were dismantled.

Read full post >>

We can consider software development as the translation of our theories, concepts and ideas into the machine code. Therefore, how we gain, evolve and verify this knowledge is very important for building successful software. There are two main views how we gain the knowledge: Rationalism and Empiricism.

Rationalists appeal to reason as a source of knowledge or justification. They claim that our concepts and knowledge are gained a priori, independently of experience. Empiricists claim that experience is the ultimate source of all our concepts and knowledge. Rationalists come up with a theory and look for the evidence to support it. Empiricists assembles evidence, and builds on the evidence to form a theory.

The main question for the both camps: How do we know that our theory is true knowledge and not a guess?

Rationalism and empiricism have various success in different areas:

• Mathematics is triumph of rationalists – all the complex branches and theories are deducted logically from few intuitive basic premises.
• Natural sciences, which are dealing with dynamic complex systems combine rationalism and empiricism using scientific method: empirical observations and experiments with rational hypotheses and predictions. However, empiricism has the main emphasis – observational experiments are necessary to understand the physical universe.
• Social sciences, politics, economics show inability to come up with reliable rational theories. However, empiricism in these areas has own limitations as it is difficult to make comprehensive social experiments and deduct from them (and history) any true knowledge and theory about human groups and their societies. Human groups are complex, unpredictable and often irrational systems. They don’t behave consistently and don’t submit to permanent laws as physical world does.

What view does work better for software development?

How do these views show up in software development? Pure rationalists would prefer developing complete concepts and knowledge behind the software system using intuition, logic and creative insights before start of programming. Pure empiricists would immediately dive into experiments, programming and getting early practical results and build their knowledge based on this experience.

Read full post >>

Wired magazine published a very interesting article about change in US military philosophy during the Iraq war. US started with idea of Network-Centric Warfare:

The US military could use battlefield sensors to swiftly identify targets and bomb them. Tens of thousands of warfighters would act as a single, self-aware, coordinated organism. Better communications would let troops act swiftly and with accurate intelligence, skirting creaky hierarchies.

The Army committed more than $230 billion to a network-centric makeover, on top of the billions the military had already spent on surveillance, drone aircraft, spy satellites, and thousands of GPS transceivers.

Advanced technology helped to achieve quick victories – the opposing forces in Iraq (and Afghanistan) were broken in matter of days. But years of struggle to establish the new order came after these victories. Seizing territory and destroying enemy forces was not enough for the success. American military have learned from these failures and started to change approach recently. They realized importance of winning trust, minds and hearts of local people to win the war.

General David Petraeus, commander of Multi-National Force in Iraq, knows all about these mind games. He oversaw the writing of the new counterinsurgency manual. The book counsels officers to reinforce the local economy and politics and build knowledge of the native culture, “an operational code’ that is valid for an entire group of people.” And the manual blasts the old, network-centric American approach in Iraq. “If military forces remain in their compounds, they lose touch with the people, appear to be running scared, and cede the initiative to the insurgents,” it says.

Sometimes software development projects are closer to military operations than to the engineering process. The situation often changes, pressure is building up and quick decisions are required. The software system is the end result of these operations and developers are in the forefront. The software system campaign is not finished after the initial development is over: people start using the system, administrators support it and developers continue evolving it over time.

What skills can developers learn to contribute to the overall success of the long software campaign beside coming with technical solutions?

We often rely on technology, new tools and smart strategies to win our software battles. But at the end, people will decide the fate of the software. Should we teach programmers how to win minds of people who use their software in addition to mastering superiority in technology solutions?

Agile approaches insist that customer cannot come up with the reliable requirements at the beginning of the project. Martin Fowler provides four reasons:

1. Software development is a design activity, and thus hard to plan and cost.
2. The basic materials (technology and tools) keep changing rapidly
3. So much depends on which individual people are involved, and individuals are hard to predict and quantify.
4. In today’s economy the fundamental business forces are changing the value of software features too rapidly.

However, the most interesting reason is inside customers minds – they cannot reliably predict what they will need from software in the future.

Lets face inconvenient reality – most of the software ideas, decisions and requirements are not the result of scrupulous research, well prepared theories and mathematical models. If it were so, software development would take so much time, money and energy that it will almost eliminate any business benefits. Also it is very difficult to formalize anything related to irrational human beings (who accidentally are the main users of the software). In the most cases, software ideas are born from intuition, insights, copying other ideas and own experience mixed with some vague expectations. This empirical mess becomes source of the vision, requirements and future problems.

Customer dissatisfaction with software is the problem number one in software development. And the root cause is that many of customer’s expectations and predictions are in vain – mostly because future is fundamentally different than it appears in their thoughts. Why? There are six challenges that customers are facing to predict the future and get their ideas about the software right.

1. Subjectivity and our individual experience

alikaragoz
Software ideas are mainly based on our individual experiences, thoughts and understanding. Our individual experience is unobservable to everyone except ourselves. It is very difficult to communicate it right and completely understand other people. Translations and interpretations of software needs are unreliable – too much depends on what experiences we had, our memory and level of knowledge.
We see problems and possible solutions through lenses of our individual experience and often they shape and distort what we see. In addition, even if software customers can get objective view on their problems, they would see it from completely different perspective than domain experts, developers and end-users – people who shape ideas, build and use software. Subjectivity makes expression and understanding of software ideas very difficult.

Read full post >>