A really great talent finds its happiness in execution. – Johann Wolfgang von Goethe

source

Qualities of well composed code:

1. Quick discovery and understanding of programming logic and components
2. Clear organization (for human brains)
3. Ease of reuse, modification and evolution
4. Close connection between customer ideas and system implementation

Read full post >>

I was always against Copy and Paste programming. I condemned people who use this practice as discrediting the honorable profession of The Programmer. This evil activity inflates application code without adding anything useful. This shameful practice causes various complications – more code, more things to remember, needless complexity, and difficulty to manage and synchronize related changes in the future. But at some point, I admitted to myself – things are not so black and white. I do Copy and Paste in my code, it is difficult to resist this seductive activity.

The only indulgence is that I’m very keen to eliminate bad effects of Copy and Paste before finishing my task.

I use two main approaches for writing new code. The first is Top-Down – I have clear design ideas how I should program and I know what classes and components to use. I go ahead and write code from scratch using my memory and power of intellect :). There are few problems with this approach. Unfortunately, my memory is not so great and knowledge is not so vast. Regularly I have new tasks that I don’t know or don’t remember how to program. Sometimes I don’t get immediately what other people programmed without debugging. And often I want to save time and avoid re-implementing the same idea again. And that is why I also use the second approach – Bottom-Up. I copy and paste code first. And after I figure out how this code works, how to use, fit and improve it. Read full post >>

Pair Programming is a great way to build software systems. When Pair Programming works, it has significant benefits:

• better ideas – continuous brainstorming, larger knowledge pool, less gaps in understanding and more brain power to solve design problems;
• better quality – fewer bugs, instant validation of ideas, consistent approach and stricter adherence to team conventions;
• better knowledge – experience and knowledge sharing, deeper understanding of why, how and what was done;
• increased productivity – better focus and higher intensity, pushing each other and motivating to achieve best results, less procrastination and wasting of time;
• more enjoyment – most people like to work in groups and solve together interesting problems.

Extreme Programming leaders insist that all significant development should be done in pairs. But can we say that Pair Programming is the best method in all situations?

Read full post >>

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 approach to programming is concerned with finding the best ways to translate programmer’s intention into the good system design and code.

The programming is communication. The programmer continuously add, change and refine ideas in the code. Source code has two important goals: tell a computer what to do and tell people what the computer should do. The program code is the only true medium for storing and communicating ideas about the software system behavior. Quality of the ideas expression in the code directly affects overall quality of the system.

So, what are characteristics of the good code?

1. clear – easier to work with ideas;
2. minimal – less effort to understand and change ideas;
3. testable – easier to validate ideas.

These are 6 top reasons for bad design and code:

1. lack of expertise
2. unrestrained technical curiosity and creativity
3. missing big picture: system purpose and customer goals
4. blindly following popular methods and over-using technology
5. sloppiness; lack of attention to details
6. over-complicating design to have more work or increase job security

The programmer can write better code (and avoid most of these problems) by improving programming style and approach.

Read full post >>

“I made this program longer than usual because I lack the time to make it shorter.” – paraphrasing Blaise Pascal

The Elements of Pragmatic Programming Style is the collection of rules for pragmatic programmers. This collection doesn’t pretend to be comprehensive guide how to program. Rather it concentrates on fundamentals: how any programmer can build better software for the customer. Some of the rules are obvious, but, surprisingly, many programmers don’t even think about them. They make same mistakes over and over again. I hope this post will inject a healthy dose of pragmatism into your programming style and make it a bit better .

Style Components:

• Intention – understand your task and how to get it done
• Approach – basic principles of writing code
• Composition – organization of code
• Expression – expressing ideas in code
• Object Oriented Pragmatic Style

The goals of Pragmatic Programming Style are

1. Building reliable software fast.
2. Delivering maximum value for the customer.
3. Writing code that is easy to understand, change and share.

Intention

“Everyone hears only what he understands.” – Johann Wolfgang von Goethe

Understand your task and how to get it done

Sidereal
Read full post >>

No man is an island unto himself every man is a part of the whole – John Donne

It is possible to program a web page or small application with little knowledge of programming. Use Google to search for examples and if you are lucky, you will find ready code and your are almost done. Even experienced programmers often retreat to search to save time and effort for finding solutions for their problems.

Modern effective programming is unthinkable without using search, the  Internet and collective intelligence. Therefore, search skills are becoming primary for an effective programmer.

Now we don’t need to know and remember how to solve many programming problems – we can use search. We are becoming more effective, productive and able to solve wider range of problems. But does it mean that good search skills are enough for building software? This post will review the role of search skills in forming programmer knowledge and how to use search effectively.

Types of knowledge and how it grows in programmer’s brains.

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 >>

Can we say that clearing house from rubble and debris after home repair is a necessary waste for construction workers? Can we say that making design of the car that could be easily supported and repaired by mechanics is a necessary waste for engineers? Can we say that making ideas clear, easy to follow and understand is a necessary waste for the influential writer?

Amr Elssamadisy posted an interesting opinion on InfoQ about refactoring:

… there are two types of waste in Lean: pure waste, and necessary waste. Pure waste is one that has no value to either the team building the software or the customer using the software. Necessary waste, on the other hand, is the best way we currently know how to do a job even if it does not have customer value. Refactoring is clearly an instance of the latter.

Amr tries to make an important point – minimize refactoring that doesn’t contribute directly to customer requirements under development. It is a reasonable point, but I don’t like word the ‘waste’ and belittling of one of the most important practice of the modern developer. This post sparked a very interesting discussion around value of refactoring with many insightful comments (including Kent Beck and Tom Poppendieck).

We, software professionals, sometimes forget that source code is the most important representation of our ideas about how software should work and what it actually does. In the essence, software development is communication, processing and coding of people ideas. We substantially reduce value of our software if we leave messy, convoluted and difficult to understand software ideas, though correctly implemented. This code will waste time and effort of people who evolves and supports our software (including ourselves). And therefore, it will reduce value of the software for the customers who expects that it will be well supported, easy to change and become better over time. Refactoring is the practice that forces us to improve code and represent software ideas better.

Certainly, as with any complex human activity, we should learn when, how and why we should do refactoring. We should learn how to balance refactoring and development of the new features – software consolidation and expansion phases (read an excellent article from Brian Foote and William F. Opdyke). Refactoring should be not only targeted to reduce technical debt, but also to reduce comprehension debt – understanding, refinement and enhancement of implemented ideas. Finally, refactoring is the essential part of our professional mastery, which distinguish ace programmers from amateurs or indifferent hirelings.