Jason Cohen posted an interesting and provocative argument against Release Early, Release Often principle followed by many agile teams.

His main points:

• Ideas. The best ideas are not coming from users and they are bad in providing feedback (iPod). So, there is no point to release early to get their opinion and ideas.
• Features. Minimal early set of features could be unattractive for majority of users and will turn them down for future use (Apple Newton)
• Quality. A buggy and unpolished product could ruin your reputations
• Architecture. An incorrect initial architecture creates waste and serious problems down the road (Netscape, Twitter)

Therefore, Jason against releasing early and often. I don’t agree.

My answer: it depends!

Evolution is the process of small frequent changes to improve and adapt to environment.

Read full post >>

The manager slams a door and tells us that we are in a big trouble. Our old customers complain about many bugs and bad performance, new customers complain about delays and lack of dedication. And, top management considers our department financially unsustainable and wants to deeply cut expenses.
The manager tells that we are brilliant programmers, work very hard and create cool software solutions. But there is something wrong and we cannot work this way anymore.

Anxiety started to penetrate our souls. We know what is wrong: our team is short of people, we have too many commitments, our code is becoming a big mess, new technology and our new software version makes something bad with servers. A snowball of different problems makes us stressed, distracted and incapable of productive work.

What could our manager do next?

1. Distrust. Become a dictator, make own decisions including hiring external consultants to recommend what to do or even replace us. However,
   • we are good programmers and know our business well – the problem is not in lack of skill and knowledge
   • external people will take a lot of time to understand the system and they will have different motivation and won’t care about the long-term success
   • people will be demotivated and the manager cannot make effective decisions without active team involvement
2. Faith. Give to team the full power to fix a problems and make own decisions in hope that smart people, motivation and technical expertise will do magic. However,
   • fresh outlook and thinking out of box are hard when a team immersed for a long time into difficult situation
   • a team possibly doesn’t have understanding and control over external forces – management, customers, finances
   • changing of reality is tough (especially in people heads) and requires more than technical experience

There is a third way. Place improvement practices in the core of development process. Make self-improvement inevitable and required for any activity. Do it every day.

Toyota Way is the best example of large-scale reliable self-improvement process. It focuses on eliminating waste, solving problems at root cause and making right decisions. Toyota Way reduces problems, increases internal efficiency and makes a company successful. This is the best receipt for coming out of crisis.

Targets:

• Problems - emergencies, fires that require immediate fix: bugs, server crushes, deadline slips

• Waste - inefficient and non-value adding activities: waiting, misinformation, stress

• Challenges - adaptation to external forces (market, competitors, customers, society): new trends and technologies, changes in users expectations for user interface and functionality

Read full post >>

Reality is merely an illusion, albeit a very persistent one – Albert Einstein

An expert have much better models of reality and methods to build them than an ordinary specialist. The expert, armed with these models, can quickly put pieces of a problem puzzle together, find explanations and solve the problem.

Models can be related to anything – software systems, business domain or your personal relationships. Read full post >>

experts are made, not born – Scientific American

Disclaimer: This post is devoted to a person who wants to become an expert – the top player in a specific field as programming, soccer or chess. This post will be not interesting for people who are satisfied with their current performance and not interested to be the best.

If you want to become an expert, it is not enough to follow your work assignments or occasionally play with interesting stuff at home. You have to push yourself hard in specially designed way.

@Work
Your paid work tasks and projects are not designed to make you an expert. Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal – make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods. We cannot blame our organizations – this is part of the deal – they pay for your work and expect specific results. But… is this the best way for you to become an expert, acquire new skills and gain knowledge? To become an expert, you have to make many mistakes, learn from them, experiment with alternatives and work hard on your weaknesses. How many organizations do allow this risky, unproductive and unreliable way of working?

@Home
Your play at home with interesting stuff has problems too. To satisfy your programming instincts and curiosity, you will probably select what you enjoy to do and eager to try. You’ll immense in this activity and find great satisfaction from doing it. But…  is this the best way to become an expert by doing only what you like? Becoming an expert requires hard, sometimes unpleasant work, specifically designed to improve your performance and push you over comfort zone. Read full post >>

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