Thoughts on performance

Performance can make or break a piece of software, this is clear; nobody puts up with an unresponsive client UI or a slow back-end server in today’s age of software abundance and choice. Despite this, performance is often overlooked until late in the release cycle and doesn’t get the proper attention it deserves. This might not be a big deal in one release cycle, but after a few release cycles,  you can end up with a slow-moving giant that nobody knows how to fix instead of a lean fast machine that you used to have.  At this point, you either accept what you have or you take the hit and go through the painful process of profiling, analyzing, fixing, and in some cases redesigning. How does software end up like this in the first place? I can think of four reasons.

First, it’s not easy to sell performance. New features, especially visual ones where people can see and play, often are much easier to market and sell then subtle yet more important features like performance. Two more features on the release cycle looks better than 20% increase in throughput for example, so performance is not treated as a proper feature but rather seen as a thing to check at the end of the release cycle. As a result, performance does not get the time and resources it needs.

Second, it’s not easy to reason about performance. You need to define what metrics are being measured in the name of performance, define what qualifies as acceptable performance, define use cases where performance is important. This requires through understanding of the software and the use cases around it. It’s hard to get the scope of performance work right, it’s either too broad to implement or too narrow to produce anything useful.

Third, performance work is hard, sometimes harder than implementing the software. It usually needs additional tools/software outside of the software itself in order to write tests to simulate the agreed upon use cases and track some numbers around those cases. In most places, there is simply not enough time left over outside the feature development to build those tools. Even if you have all these tools, you need time to run the complicated performance scenarios and if numbers don’t look right, you need time to find out why; it can be anywhere in the code. You also need to do this all over again in every release cycle or get some time to implement automated performance tests that can track performance for you. This is a lot of work.

Fourth, performance is usually not tightly integrated with the overall feature development. When a new feature is being developed, there is a lot of focus on the new capabilities that the new feature brings from Engineering, QA, Product Management but not as much focus on two things: 1. How does this feature perform by itself? 2. How does this feature affect the overall performance? The result of ignoring #1 is that a new feature gets designed and developed without performance in mind, and by ignoring #2 the overall performance of existing system gets worse which is even worse.

Despite all this, professional software developers have the obligation to design and implement performant software, no matter what the realities of the workplace is and I think with some effort, performance can be saved and maintained over the release cycles with a few guidelines that I hope to share in a future post.

Hybrid apps, not as straightforward as you think

I recently had the chance to go out of my comfort zone (server side development) at Skype and work on some client side mobile features. One of the topics that came up a number of times is whether a certain feature should be implemented in pure native code or whether it can be written as a hybrid feature using a mix of native and HTML/JavaScript code.

Developers are very religious about this topic. (It’s interesting how developers feel more religious about topics that they can fully understand, compared to topics that are hard to understand, but this can be another blog post). While some want to implement features in native code fully, others prefer to abstract away as much as possible using HTML/JavaScript as a common language and use technologies like PhoneGap/Cordova to figure out the details on how to run that code on various platforms.

As someone who used to work at Adobe, this reminds me of the discussions around Flash on mobile. At some point, Flash provided a plausible implementation of “Write once, run everywhere” myth on mobile phones. Writing code once and letting a common runtime like Flash to figure out how to run it on various mobile platforms was indeed a nice idea in theory. In reality, every mobile platform is different and they simply could not be abstracted away in a common runtime like Flash. That’s what I learned and that’s why I now believe that “Write once, run everywhere” is a myth.

Even if you don’t believe me that “Write once, run everywhere” is a myth, and even if we assume that technologies like Flash and PhoneGap/Cordova provide excellent frameworks and performance across all mobile platforms, I still think that developers should still be worried about hybrid apps.

Mixing different languages is hard and it increases the complexity of a project by tenfold. When you have a pure native app, you know exactly what IDE to use, what language to learn, what tools to use. You know exactly how to debug and how to test your application. Every native mobile platform has its known and accepted tools for the job.

When you start mixing native and HTML/JavaScript, everything goes out of the window. All of a sudden, you need to worry about this trojan horse sitting within your native code. Testing becomes difficult, debugging becomes difficult, profiling becomes difficult, code coverage becomes difficult…With pure native code, you’re constrained by the boundaries of that environment and that’s a good thing to have, so you can focus on your application. With a hybrid app, you end up spending a lot of time going back and forth between two programming models. It’s not impossible to navigate through but you need to ask yourself: Is it really worth the effort?

Don’t get me wrong. If you need a certain feature and if the most feasible way of doing it is in HTML/JavaScript, then by all means, go ahead and do that. I’m not against the idea of hybrid apps per say. What terrifies me though is how lightly the hybrid vs. native decision is made sometimes. It is not supposed to be an easy decision. While mixing things up, you need to be aware of the complexity you’re introducing on developers and testers. If the complexity outweighs the feature you’re introducing, you need to think again. If you’re going to create a hybrid app, you really need to consider that decision carefully and make sure you’re getting enough back from your hybrid feature for all the complexity it’s introducing.

Specialization, an excuse for laziness and indifference?

In my previous post, I talked about specialized vs. generalist programmers and I concluded that there’s no clear answer when it comes to whether someone should be a generalist or a specialized programmer. While I advocated a balanced specialized vs. generalist approach, I think it all boils down to the personality of the developer. What is clear to me though is that specialization can be used as a good excuse for laziness and that’s not a good attribute to have in a high performing team.

As programmers, I’m sure we all heard quotes like “Oh, I’m a server side developer, I can’t do UI”, or “I’m an object-oriented Java guy, I can’t deal with JavaScript” or “I’m a UX guy, I don’t know how to work with databases” or worse “I’m not a tester, don’t ask me write tests”. These are unfortunate statements from people who claim to be programmers. They are basically saying “I’m lazy, I want to cruise along my comfort zone and don’t ask me to do something new where I might need to challenge myself”. Programmers like these bring down not only themselves but the whole team as well.

It’s very hard to be a rock star server side developer and also have great UX design skills, so I’m not advocating that everyone should be great in everything, that’s impossible. What I’m advocating though is that every developer should be comfortable with every part of the software development process. Sure, you can be an expert in database design but if the UX team needs help, you should have no problem in jumping in and helping with some UI work. At some point in development cycle if QA engineers fall behind, you should have no problem in writing and automating good tests for them.

Software development is a team activity. Users do not care who built the software or how the software was built or who was the frontend or backend developer. All they care is whether the software works as a whole and whether it solves a problem they care about. Given that, good programmers need to have the mindset to work on the software as a whole, end-to-end. They need to chip in and help out in any way they can. Usually, they will help with their specialized knowledge and skills in their specialized corner but more often than not, they will need to take a generalist approach and help in areas that they might not be comfortable with.

Another unfortunate side affect of specialization is that it breeds indifference. When a server side developer realizes that the UI of the product is a little off, he usually does not care because in his specialized mindset, it’s the UX designer’s job to get that right. Worse, even when he cares and he raises his concern about the awful UI, he usually gets the usual “This is UX’s job, don’t worry about it” kind of response. Either way, you end up with mediocre sub-parts of a product that make up a mediocre product and in the ends, users see a mediocre product as a whole and everybody loses.

Next time you hear a programmer say “Sorry I’m not X, so I can’t do Y”, tell them to stop being lazy and help the team out. Don’t let them use their specialized title as an excuse for laziness because their laziness will eventually affect the team and the last thing you want to be part of is a lazy bunch of developers that accomplish nothing. And never ever let someone tell you that “Quality/UX/performance is my job, don’t worry about it”. It’s team’s responsibility to get a good product out as a whole and every person is equally responsible of the every part of the product.

Generalist vs. Specialist Programmer

One question that I keep wondering lately is whether a programmer needs to specialize in a small subset of programming languages and a small subset of problem types and be really really good at it or whether it is better to try many different languages and problems and be a generalist? It’s a complex topic and the answer depends on a whole lot of factors that I’ll try to explore in this post.

Specialization camp argues that if you want to be really good at something, you have to specialize. Instead of trying to learn and do everything in a mediocre way, you pick a language (eg. Java) and a small subset of problems (eg. Server side development with JEE) and you become really really good at it. There’s no shortage of specialized problems and by being an expert in your area, you have better chance to differentiate and establish yourself as a domain expert.

Generalists, on the other hand, argue that there are a lot of different types of problems with diverse solutions and a good programmer needs to have a generalist view and tool-set and be able to work on any part of the problem. By not limiting yourself to a small niche area, you keep your mind and options open, keep challenging yourself with diverse problems and get better at problem solving which is the essence of programming.

I can definitely sympathize with the specialization camp. At Adobe where I spent 6.5 years, I was a specialist myself. I spent all my time and energy on server side Java projects and towards the end of my time there, it felt good to really know what I was talking about. In order to be able to say “I’m an expert at X”, you need to put time and energy into specializing into X and that usually happens at the expense of losing some diversity in skill sets and problems to work on. One drawback is that by specializing, you put all your eggs in the same basket. Technology changes very fast and what’s hot today is old news tomorrow. The cool new technology you specialized in might be irrelevant only few years later and it’s something to keep in mind.

On the flip side, I can see the generalist argument as well. Since I joined to Skype last year, I had the chance to get out of my comfort zone and worked on projects in C#/.NET, Node.js and Windows Phone. It was hard to switch from server side Java development to client-side Windows Phone C# development but in the end, I felt like the effort was well worth it. Now, the world is not just Java vs. non-Java to me and rather it’s a world of diverse problems that can have diverse solutions and I can be part of all those solutions as long as I put the time and effort into it. I can’t say “I’m an expert in Node.js” yet but that’s OK, I can solve a lot of interesting problems in a quick way with Node.js without being an expert.

Pros and cons of specialization vs. generalist are clear and I don’t think there’s a right answer. In the end, it all depends on your personality as a programmer. Some programmers like to deep dive in the same type of problems for a long time and get really good at solving those types of problems. Some like the diversity and the thrill of the unknown that comes with a generalist approach.

I personally like a balanced approach where I try to specialize in a few areas so I feel like I know some things really well but I also try to stay as general as possible. If I’m working on a server side project now, next time, I try to pick a client side project. This way, I try to stay challenged and not get comfortable in one area at the expense of everything else.

No matter what you want to do as a programmer, I think it’s good to be aware of the pros and cons of each approach and make an informed decision.

Thoughts on code style

I recently had a nice discussion with a fellow programmer about code style which triggered me to think on this topic and that in turn triggered this post where I hope to outline my thoughts on code style.

Code style is a set of rules used when writing source code. These rules do not usually make any difference to how the code runs but they make a huge difference in how the code looks like. In virtually all software teams I was part of, code style caused some arguments among programmers at one point or another. It is a controversial topic. I think there are two reasons for this.

First, programmers are very particular about how they do things, especially in writing programs. If you dare to ask a programmer to write his code in a certain style, you better have a really good reason for it.

Second, programmers tend to have strong opinions on topics that they understand inside out. If a topic is hard to understand, there has to be an initial upfront investment to understand the topic in order to have an opinion about it. The investment has to be even higher if you want to have a strong opinion because you’ll need to defend your strong opinion against fellow programmers and that requires that you really know what you’re talking about. Code style is both trivial to understand and requires minimal investment in understanding the code style rules. Therefore, programmers tend to have strong opinions about it.

The first camp in code style thinks that code style is extremely important in programming. Code style in programming is like punctuation in writing. No serious writer even considers writing without punctuation and as such, no serious programmer should consider writing code without a common style. According to this camp, the team has to agree on every little detail in code style and the whole team has to adhere to those rules. It’s a sin to not adhere to code style. You write code not for yourself but for other programmers to read and understand and you have a responsibility to make sure your code is understandable and adheres to some common style.

The second camp in code style thinks that code style is utterly useless and sometimes even harmful in programming. They think that it’s hard to find a common code style that all programmers agree and it’s even harder to make programmers adhere to it. At the end of the day, code style has no effect on how a program runs, so spending so much time and effort on something that does not make a difference in reality is useless. Instead, time could be better spent with test coverage or design improvements which do have significant impact on how a program runs. Code style not only causes friction in a team, it also takes valuable time away from useful activities like extending test coverage.

I think both camps have valid points and I can relate to both. However, I don’t think that either camp is totally right. The right attitude about code style lies somewhere in the middle. The first camp is right that we write code for others to read and I agree that we need to pay attention to how we write code. It’s just selfish to have a “my-way or highway” type attitude with code. There’s something more important about code style though. If a team agrees on a common set of rules regarding code style and actually sticks to those rules, it shows that the team is indeed a team that can act like a unit. It shows that people have no egos and the code generated is not considered as yours or mine but rather considered as team’s code both for the team members and to the outside world. This is an important goal to strive for a team and since code style helps in achieving that unity, it should not be dismissed so easily.

On the other hand, the second camp is right that code style should not come at the expense of test coverage or other activities involved in software development. I think this could happen if the team suddenly decides to implement code styles on existing/legacy code. Instead of fixing the code and making it better for existing customers, the team spends the time to make the code look pretty. That’s silly. Similarly, in dysfunctional teams, agreeing on a common code style is a daunting task and it could suck a lot of time and energy out of the team. All of this can be avoided by having a strong figure in the team leading the team to agree on a common code style upfront, however little the commonality might be, and then making sure everyone sticks to these rules throughout the project. Sure that’s some initial investment but once the initial agreement is done and habits start setting in, programmers don’t really have to think about code style, it just happens.

To sum up, I believe that code style is important and all its pros and cons should be considered before adapting or completely abandoning it.