Soft stuff @ bjarte.com

Apple and Usablility

I am very impressed with the user interfaces Apple has on it’s products like iPod and the iPhone. Apple really do set the standard. Apple does have some really crappy software as well. The one that constantly annoys me is iTunes. But that’s not a problem Apple. I can forgive you for one mistake. However, what I got this morning when I tried to update my iTunes didn’t please me at all. As we all know when we get an software update we just press next, next and then we’re OK. Apple has realized this as well and is deliberately trying to push some software to you that you DO NOT WANT. This is not acceptable.

The problem is easy to fix. They could just have left the check-boxes unchecked.

Obviously I’m not new to this behaviour. A lot of non-user friendly companies does exactly the same thing. But Apple? Come on. You are supposed to be the usability guys.

The way to create great software is to think about the user experience from the users perspective. Nobody wants an extra browser or a mobile-something application installed when they are just updating their software.

Hopefully you, my readers, don’t do this kind of crap to your customers. Or do you ?

Later.

Code ownership and source control in action

We (the team) just had a chat about some ideas we should follow when it comes to source control and code ownership. Here is a short summary.

Code ownership

”Shared code ownership: ” To ensure that more than one person is familiar with a certain part of the code base we have shared code ownership. This will make the team more flexible, and making change easier. It is always allowed to refactor code to make it better. It is actually required to prevent the code base from deteriorating over time. That said, there might be people who knows more about the code base than you do. Also, somebody else might be working with the code right now. ”Consult before making radical change.” Communication is always important.

Check in

”Check in early, check in often: ” The code is what is in source control, not what is on your computer. By keeping the code in isolation on your computer you are setting yourself (and the team) up for big trouble. By updating(first) and checking in (second) often, you prevent merging and communication problems. Partition your current work into sub problems, and check in when each feature is created or updated. Work on one problem at a time. If you find yourself working on 10 features, where each one is impossible to check in, you are doing it wrong. It’s a code management anti-pattern. The philosophy behind this is simple. Problems are easier to fix right after they occur. In a day, or a week, solving the problem becomes exponentially harder. Considering this philosophy, keeping the code on your machine to avoid problems MAKES NO SENSE !

”If the code isn’t checked into source control, it doesn’t exist”

Write tests

Write tests for the expected behaviour and your usage of the code. This will ensure that new features and refactoring is compatible with existing usage.

Standard

“Standard” is what we do right now (or should do). The standard can be changed as we find better ways to solve our problems. However, we should all follow the current standard.

Feedback is king

The other day when I was up in the mountains in my cabin, I suddenly started thinking about development processes and rapid feedback loops.  I sat down to write about it, and here is the result:

There is a saying “culture eats strategy for breakfast”.  It’s true. I have seen it in action.

Introducing a new process often requires changing the culture in the company. This is hard or impossible. Radical change creates too much friction. Working with the existing process and modifying it slowly is the most feasible route.  Identify your goals and see how you can slowly modify your existing process to achieve the goals.

Let assume that building software faster and with better quality is a good idea in your context. It usually is.  Let’s say this is our goal, assuming that it in the end will lead to more profitability.

I firmly believe that to create maintainable software there is one term that is more powerful than all others. That term is rapid feedback loops (RFL). Rapid feedback loops is the common denominator of all agile processes. The only process I know of where RFL is not a central concept, is the waterfall model.  It is not the details of the agile processes that make them succeed. It is the fact that they all embrace rapid feedback.

Test driven development tells us every minute if our code works. Continuous integration tells if our code is working in the bigger picture. Integration tests checks whether we are fulfilling the product requirements. Periodical demonstrations and conversations with our customers tell us if we are building the right product. It’s all about getting feedback. If you are writing bad code, or creating the wrong features, feedback nudges you back on the right track. Design reviews can prevent architectural erosion. You need feedback as soon as possible so that you don’t waste time working on the wrong thing. Working on the wrong thing is expensive.

Feedback is a good thing if the feedback you are getting is correct. If it’s not you have a problem. We can usually trust well written unit tests. Integration tests are harder, because they are only correct if they are actually testing a feature we need in the end product.  We need to constantly check with our customer that we are on the right track. The customer might be wrong, so we re-check on a continuous basis.

If you want to improve your current process you should start looking at your feedback loops. Slowly introduce feedback on all levels. You don’t need to pick Scrum, XP, RUP, Lean, Kanban, Crystal Clear or ScrumBut. However, you should know roughly what they are about. This way you can pick from a toolbox of practices and make them fit into your existing culture.

I don’t believe in picking an out of the box process if it will crash with your current company culture. However I really do believe in feedback loops and you should introduce them slowly into your current process. There is obliviously more to creating a smooth software machine, but feedback is a key concept.

Peace.

Software related podcasts

Here is my ITunes export of podcasts I listen to. Most are software or “software business” related. I hope it’s helpful. Have I missed some crucial ones ? Tell me on twitter or in the comments :)

BTW, I just removed the StackOverflow podcast from the list. It was taking “brain dead” to another level :)

• .NET Rocks!
• Agile Toolkit Podcast
• Elegant Code » CodeCast
• Entrepreneurial Thought Leaders
• Hanselminutes
• Herding Code
• IEEE Software’s “On Architecture” with Grady Booch
• IEEE Talks Software Process
• Lean Agile Straight Talk podcast
• Mixergy - Online Business Tips from Successful Entrepreneurs » Interview
• Pluralcast
• Polymorphic Podcast
• Software Engineering Radio - the podcast for professional software developers
• TEDTalks (audio)
• The Startup Success Podcast
• This Week In Google
• This Week in Startups - Audio Only
• this WEEK in TECH - MP3 Edition
• Venture Voice

Crush it !

I just finished the book Crush It! by Gary Vaynerchuck. It’s about how you can make a living using social media and doing what you love to do. In the book he summarizes my own philosphy in a couple sentences

1. Love your family
2. Live your passion

Can’t argue with that…

I give it a 4 out of 6. If I had finished it a year ago I might have given it a 5 or 6. It all depends on what kind of books, blogs and shows you have devoured before you read it. To me it wasn’t a lot of mind blowing stuff in there. Still, it’s worth reading due to the passion Gary brings to the subject. Get the audio book, and you will see what I mean :)

Freaky coincidence

Just sat down to draw some vectorized mountaintops in Illustrator to practice my design skills. I turned on Spotify and the first song started. It was Jeremy by Pearl Jam. It starts

“At home drawing pictures of mountaintops…”

Freaky :p

An abstraction on top of NHibernate

Prepare for a random thought > 140 chars:

I just read Ayendes post where he debates why we should not put an abstraction on top of NHibernate.

The reason to do such a thing would be to avoid coupling your code to the persistence layer. This in itself is not a bad idea until you take a deeper look at what is required to make a useful abstraction.

A simple persistence interface on top of NHibernate would make it easy to change the persistence layer but

1. What happens when you need other features from NHibernate. Will you add it to the abstraction layer ? Not a very solid abstraction really.
2. NHibernate is already an abstraction on top a relational database. Do you want to add another one ?

The term “Leaky abstraction” comes to mind.

Taking your game to the next level

Experience is the best way to learn, especially if you fail. However, you should not be reinventing the wheel and making mistakes people have made before you.  Use the knowledge on the web for what it is worth, and stand on the shoulders of giants as you take the next step to become a better developer.

I have been learning new things about the business of software, project management and software architecture.  I have read a lot of books, listened to hours and hours of pod casts, watched screen casts and been to conferences. Finding the best content among all available sources is hard. In this post I will share some highlights hoping that I can help you in your search for the best content.

The business of software

I was listening to the StackOverflow podcast when they were interviewing Jason Calacanis. I had never heard about this guy but he was apparently an internet celebrity and serial entrepreneur in the web space. He had just started a show “This week in startups” and I checked it out.

In the show he is interviewing guests on how you start up and run a successful internet business. He has a very interesting personality which makes this show a must watch. I am listening to many shows, like “This week in tech”, “This week in Google”, “Herding Code”, “Elegant code cast”, “Software engineering radio”, “HanselMinutes”, “StackOverflow” and many others, but this show is always the highlight of the week.

After I started watching this program I am really getting a taste for the business side of things. Turns out it is as complicated and fun as creating software.  You need to be passionate, hard working and even a little bit smart to be a good entrepreneur.

Lately I have been reading all sorts of books on the subject. One of the most intriguing books I have read lately is “The purple cow” by Seth Godin. He talks about how you need to create remarkable products that people want to talk about. The traditional model of marketing is not working anymore because people is getting overloaded with information and It’s hard or even impossible to make your product stand out. Read the book or get it at audible.com.  It is worth it. Audible, by the way, is great.

Right now I am reading a book called “Predictably irrational”. People act very irrationally when it comes to money. The funny thing about it is that you can actually predict their irrational behavior.  In this book the author gives a unique insight to the human psyche. It’s fun to read. I recommend this one as well.

Software design and architecture
Software design and architecture has been one of my interests for a long time and this year is no different. The Norwegian Developer Conference was packed with great speakers presenting on parallel tracks. Despite having a choice between great speakers I always found myself listening to Udi Dahans presentations. Udi talks about SOA not only from a technical perspective but in the intersection between business and software. He has a great way of keeping things simple but not simplistic.

I have been following Greg Youngs blog on Code Better for quite some while, and was thrilled when I got the opportunity to attend his class on the CQRS architecture in Bergen.  The CQRS architecture works great together with domain driven design to create and manage complex domain models. It’s worth reading up on.

The best software design book I have read this year is “Patterns of Enterprise Application Architecture”.  The material is presented in a clear and concise manner and the book is a great read. No wonder it has cult status in the developer community.

Another great book is the free book “Getting real” by 37 Signals. It talks about every aspect of developing web software. The big takeaway from reading this one is “Keep it simple”. It’s separated into several small essays. Reading an essay takes 5 minutes and every one contains gems of knowledge.

The process of developing software
Thru my work I have seen many interesting takes on how you should develop software, some good, some bad.  There is no “one true way” of developing software. I believe that your choice of process greatly depends on the culture in your company and the physical location of the people involved. Distributed teams have many limitations and should be avoided if possible.

Agile and Lean software development is interesting. I have been reading the Poppendieck books on Lean and some of the more business oriented books of Womack and Jones. However the highlight of the year is “The Goal”. It is written as a novella which makes the subject even more interesting.  This book introduces “the theory of constraints” which is a very interesting concept, and a “must know” for every developer (and business person).

Seeing the big picture
Learning about business, process and software gives synergies. Each of the areas affects the others and you start seeing the bigger picture. This will make you a better developer, or as in my case a great one ;)

The roles of software development

Building software requires people with a certain skill set. To build a successful product you need a person with a clear vision of where the product is going. This person is the most important member of the team. Without him (or her) you will not be successful. This person, the champion, can guide the development towards the goal. The champion knows what features to include and what features not to include in the product. His clear vision will stop feature creep and lengthy unproductive discussions. The champion listens to others but has the final word. Democracy is not the way to go if you want to build remarkable software.

Developing a quality product is difficult, and a champion is only one piece of the puzzle. To build a great software product, you need great software. You won’t fool anybody by putting lipstick on a pig. This is a key aspect missed by a lot of companies.

To build great  software you need a person who knows how to build software. It sounds obvious doesn’t it ? This person, let’s call him a developer lead, should be responsible for the development team.  He is responsible for ensuring that sound software engineering practices are followed throughout the project and that the software quality is up to par. This is not a simple job.

Ideally the champion and the developer lead is the same person. The reason is simple: Communication. Communicating the vision  is hard, and fewer people means simpler communication. If you want to develop software effectively you need to make trade-offs between the features you would like to have and the time it takes to implement them. Often you can make small adjustments to your requirements and gain a lot in terms of development time and better technical solutions. This translates to faster time to marked and eventually more revenue. Identifying these trade-offs are difficult, but if the champion knows the technical aspects of software development this problem disappears.

Having one person doing the work of a champion and a developer lead can be a recipe for failure if this one person fails at any of the two roles. A common mistake is to put a domain expert to the task of leading the development team, and thinking that if you put enough developers on the team the software will build itself.

I have seen many products become mediocre due to the lack of a champion or a dev. lead. The roles need not be explicit, but they need to be present in the team in some form.

What kind of people do you think is required to develop remarkable software ?

HTML 5 looks nice

I just had a look at HTML 5 the other day. The Chrome browser has support for a lot of the features and you can check them out here if you have Chrome installed. To me it looks like Silverlight and Flash can get in trouble in the future. The first question that hit me was how long time it will take before the majority of the browsers support it. According to Microsoft it might take 5-10 years, but I’m not so sure about that considering the speed at which the web is developing.

Check it out at http://www.chromeexperiments.com/