Tuesday, April 29, 2014

Applying the 4 R's of conservation to Software Development

Refuse, Reduce, Reuse and Recycle. It works to reduce landfill, It also works to ensure our code and documentation does not end up in the virtual landfill and it is properly used by future generations

Here is how I relate it to code in particular, and as you will see, applying one makes it easier to apply the others. (Note, this is a short post as I am on vacations :) )

Refuse
Do not write code you don't need to write. This applies at different levels, here are some examples
- Avoid automating one-off tasks
- Before automating a process, ensure it has been properly re-engineered. A bad process automated is still a bad process
- Don't write code already exists just because you don't understand it or like it

Reduce
When it comes to code, less is more. Less to maintain, less opportunities for bugs to creep in, easier to extend.
- Don't write code you "may" need. Write it as you need it. There are many techniques to allow extending the functionality as needed.

Reuse
Reuse existing code. The likelihood you are the first person facing a problem is fairly low.
- Search around for existing code, either in the form of libraries, frameworks, the internet and your own code.

Recycle
Code for Reuse: Follow techniques that allow others to reuse your code.
- Write libraries, frameworks, code with dependency injection in mind, Expose extensible interfaces, etc.

In future posts I'll review practices that directly relate to these 5 R's.

This week I will close my computer and continue my vacations. I think I will write my next post on my way back from Mexico.

Tuesday, April 22, 2014

Making choices

A good enough choice made on time is better than a belated best choice

This has been my motto when making decisions. Do not get paralyzed by the fear of not making the best decision. As long as you make good enough decision.

After all, Software systems are complex and there is hardly ever a "perfect" answer to a problem. If spending 20% of the effort you can get an 80% good enough answer which is probably the right answer why waste your and everybody else's time.

Be lazy: Reduce the effort you put making choices. 

Of course, we know that making a quick decision does guarantee a good enough answer:

- The teacher asks little Johnny: Jonnny, quickly, what is 2 times 5
- To which little Johnny immediately replies:  It is 11, teacher
T - Johnny that's wrong!
J - You asked for speed, not accuracy.

But there are techniques to help you make quick "good enough" decisions

Some of those are explained on the TED talk How to make choosing easier.

In future posts I will expand each of them showing specific examples on how to apply these techniques to software development.

Cut - Reduce the number of alternatives;
Only decide between options that make a difference. In fact, in some cases you can reduce the options to 1, which reduces the effort to 0. To help you cut on the options you can use Patterns, Frameworks, Standards Guidelines.

Concretize - Make it real;
When evaluating options, weight the actual project requirements to make the final decision relevant. 
I've seen people evaluate designs, libraries or tools based on "features". While that makes for a good magazine article, it is usually misleading and usually leads to a least than optimal decision. Compared feature by feature one of the options may have more customizations or better support or be the favourite of (insert your tech guru here) but it may not be the best option your project. 

Categorize - we can handle more categories, less choices each
Don't try to make all decisions at once. Categorize the decisions by impact, area of the system or areas of responsibility.
A very common trap when making architectural or design decisions is trying to make all decisions at once. There are so many decisions to make that we get paralyzed and feel that we cannot start the project until we have made the right choice for each of them.

Condition for complexity - Gradually increase the complexity of the decisions.
This one of course goes along the three techniques above. After cutting, concretizing and categorizing; start by making the decisions with less options earlier, That will give you a sense of accomplishment and will probably drive other choices down the road. In fact, having many options usually means that the difference between them is not that big.

But wait, there is more!
As you see all of those techniques provide frameworks to help you make decisions, but they are not the only ones. In future I will tag as "Choices" post that I identify a posts, that can help you make better decisions. 

Do you have your favourite techniques?


Monday, April 14, 2014

Welcome to the Developer practices Blog

Developer practices? not a typo for Development Practices
The goal of this blog is to share my personal experience and findings on what makes a successful developer. Yes, part of it is how we code: Designing, programming, debugging, etc; but also what do we do when we aren't coding: Communication, preparation, time management, networking.

When I am coaching and mentoring other developers they are usually surprised by my two main personal reasons for implementing sound developer practices : Be lazy, be replaceable.

Then I go on to explain how those two reasons translate to being a professional developer. As you read this and the following posts I hope you'll see how most if not all good practices eventually lead to those two goals.

When is being lazy a good thing?
It is a good thing when you do things that make your work easier. It is called "working smart". 

Establishing and following good practices removes the grunt work and the guess work of your daily job and allows you to focus on what is really unique. You think about things once, not every time you are confronted with the same issue. In the end reducing the number of decisions increases your productivity.

I want to get out of this job!
I know this is not everyone's goal; some people are comfortable doing day in and day out the same thing and being considered "the experts". For me, the ability to finish a job ensuring that someone can take from where I left it allows me to constantly go to new things without being dragged back by my "expertise" in one area.

I hope to see you around regularly
This will start with a weekly blog, until I either run out of things to say and slow down or your feedback gives me more ideas to put on this pages.