Motivating programmers

I got this from Jeff Atwood blog. I thought it was hilarious. Enjoy.

Fail fast - so true!

Yesterday, one of my developers end up messing up the firewall setting of my test environment. He was so worry, but I think it was the best thing that ever happened to us. We are in a start-up shop. Which means, that capital funds are scarce and that we need to do more with less. I told him that it was OK. We don't know much Unix, but that we could get it working. In the book What Would Google Do? Jeff Jarvis says,

Corrections enhance credibility... Being willing to be wrong is a key to innovation.

He is right! My team got together from different parts of the world using nothing but our laptops, skype, Unix screen (awesome), and gray matter. You can learn so much more from mistakes. The only thing is that you need to fail fast or make mistakes well.

Kannel 1.4.1 SMPP connection problem (bug)

For a while, I had a problem with Kannel where eventually it would stop sending MO for some reason. The messages would not get lost, instead, they started queuing, but they will not sent. Later, I found out the problem. It's only with when the transceiver-mode is set. For example:

group = smsc
smsc = smpp
host = 123.123.123.123
port = 600
transceiver-mode = true
smsc-username = "STT"
smsc-password = foo
system-type = "VMA"
address-range = ""

Apparently, as per Donal Jackson (another Kannel Guru) this error also applies for those SMPP connection that uses the TRX/RX:

group = smsc
smsc = smpp
host = 123.123.123.123
group = smsc
smsc = smpp
host = 123.123.123.123
port = 600
receive-port=1234
smsc-username = "STT"
smsc-password = foo
system-type = "VMA"
address-range = ""

Once again, Sipte Tolj (aka: the messiah of Kannel) helped me with this problem. The way to fix it is to configure a transmitter and receiver and remove the transceiver. The example will be the following:

####TRAX#######
group = smsc
smsc = smpp
host = 123.123.123.123
port = 600
smsc-username = "STT"
smsc-password = foo
system-type = "VMA"
address-range = ""

####RECEIVER#######
group = smsc
smsc = smpp
host = 123.123.123.123
receive-port=2345
smsc-username = "STT"
smsc-password = foo
system-type = "VMA"
address-range = ""

Kannel HTTP Connection

I had to configured an HTTP connection for Kannel today. Below is the way you have to configured the config file:

group = smsc
smsc = http
smsc-id = http_connection
system-type = kannel
smsc-username = tester
smsc-password = foobar
port = 11030
send-url = "http://localhost:9090/outgoingmessage"

Once you configured this part, my biggest question was, how you will send the MO (incoming message) to kannel. It's implied that the MT will be using the "send-url".

Later I found out from my friend Stipe Tolj (best Telco consultant and one of the senior developers of Kannel) that it does not matter. You can do the following to send the MO:

http://localhost:11030/?username=tester&password=foobar&from=1234567890&to=4444&text=Hello

The only thing you need to use is the port for the configuration, username, and password. Then, you use the same syntax as the sendsms api. You also need to make sure you can access this port. You can always use the iptables syntaxt below:

iptables -I RH-Firewall-1-INPUT -p tcp -m tcp --dport 11030 -j ACCEPT

Software Architecture and Management

Business should understand the risks that are involved when you put speed in front of architecture. I worked on a project that was considered such a cash cow that they rush to get the application out without considering the architecture. When it was deployed, soon we noticed several problems:

• Complexity - it took a long time to fix problems due to the fact that we did not had a domain model and the business rules where scared throughout the code
• Poor performance - the application was slow
• Scalability - we had to invest a lot of money in hardware because the application was not scaling to the amount of users

Ultimately, the team had to explain to the business why we had to take a long time re-factoring the code. Not only we jeopardize architecture over speed, but we missed to explain the causes and effects of this decision. I stumbled on a book in Barnes and Noble named: 97 Things Every Software Architect Should Know. If the team would have applied some of the followings, the project would have been such a great success:

• Architecting is about balancing
• Application architecture determines application performance
• It's never too early to think about performance
• Shortcuts are paid back with interest later

All these items are very true indeed and I am taking them in consideration in my current and future projects. Eventually the company was hit hard with the US recession and Miami's Real-estate. The entire team was laid off.

Bad Development Managers

I believe that development managers should be developers themselves. I was in a team where a former PMO became the manager for our team. He has been by FAR the worse manager I've ever had. It nearly destroyed the team. He didn't know what we were doing, and yet he considered himself a developer.

One day I mentioned some trends that I've seem. We were doing a serious of small websites (micro-sites) that were pure admin, had to done quickly, and were constantly changing. I mentioned that we should look into Ruby on Rails. He quickly told me about "standardization". I talked to him about what Neal Ford calls Poliglot Programing. The manager just did not get it. He also noticed that the team started to reject him, so he started to put some distance between us and him. Meeting were done through e-mail, requirements where discussed with IM, and status were done over the phone. It got so bad that the team eventually talked to HR.

I talked to one of my mentors (a finance guru who loves technology and the best CIO I ever had) about this manager and about some of the incidents. He told me that once should see the "silver lining" of the situation. One can really learn about bad managers. He was right! Through this bad manager, I learned that managers should monitor the "pulse" of his/her team members. They are the ones that will help you achieve your goals. HBR published an article How Not to Lose the Top Job where they talked about this issue,

The leadership feedback that you (and your CEO) receive from your direct reports can be an excellent predictor of your ability to lead the company. Poor feedback from a direct report can sabotage an heir apparent, just as poor feedback from peers can

Eventually the manager was laid off, but by that time I had left the company. I'm happy to report that one of my friend, and frankly the best guy for the position (a developer), is in charge of this team.

Agile and Management - using one-on-ones model

I've been programming for over 10 years, and I think that Agile methodologies are KEY for any IT field, but when I moved to management there was something missing: I did not know how to manage my team.

I joined a start-up company focused on the Latin American market and SMS applications. I started as a senior developer and eventually senior management made me Director of Technology. I was under the influence that not much was going to change. I had only a handful of directs, and I worked with them for quiet some time. Therefore, I continued doing my stand-up meetings, showcases, Sprint Planning Meetings, retrospectives, etc. However, many incidents quickly made me realize that I didn't know my directs as well as I thought.

One incident happened right after I joined the company. One of my developers (who was also a senior) became very distant and also showed some attitude. Also, some of the developers started coming in late. Worse of all, I was terrible on providing feedback. I was stressed and always talking bad to them.

Lucky enough, I stumbled on the podcast "Manager Tools". They had a podcast named "Boss One-on-Ones - Professional Updates". It really changed the way I managed my team. The model works awesome and it's very simple. The model is based on weekly meeting with each direct for 30 minutes.

1. The first 10 minutes is for them,
2. Next 10 minutes for you
3. Last 10 minutes for development.

It took a while for my team to open-up, but later I realize that one of my developers wanted my position, the other developer said that he always needed help meeting deadlines and coming on time. Not only was I able to know my directs, but I was becoming a better manager. Because I knew my directs better I was able to help them with their careers, and I was able to efficiently delegate since I knew their strengths and weakness. Highly recommend it!