Author Archives: Mete

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.

Leave a comment

Posted by on June 16, 2014 in Performance, Programming


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.

Leave a comment

Posted by on June 10, 2014 in HTML, Native, Programming


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.

Leave a comment

Posted by on June 3, 2014 in Programming


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.


Posted by on May 27, 2014 in Programming


Mintty Weirdness

I use Cygwin to emulate a Unix-like terminal on Windows. Even though Cygwin is pretty good in emulating Unix terminal, its UI leaves a lot to be desired for, so I decided to use Mintty on top of Cygwin. Mintty not only looks nicer than Cygwin but it also has some useful features like easy copy/paste, drop & drop of text files and so on.

I installed Mintty through the usual Cygwin package installation process and I saw that it put mintty.exe file under cygwin’s bin folder. When I tried to run Mintty by invoking mintty.exe from Cygwin, it worked fine. Pretty soon, I was changing the terminal properties and making Mintty look like I wanted. So far so good.

The problem started when I created a shortcut to launch Mintty from Windows Start page. I wanted this shortcut to launch Mintty on Cygwin by default. When I clicked on the shortcut, none of the normal Unix commands would work, I would get a “command not found” error from bash. After Googling for a while and some random experiments, I found out that I had to go to shortcut’s properties and change its target to add a dash at the end. So my shortcut’s target is “C:\cygwin64\bin\mintty.exe -“

Don’t know or care why I have to do this but I wish developers put more thought in the first time use experience of their applications/libraries/packages.

Leave a comment

Posted by on August 13, 2013 in UNIX, Windows

%d bloggers like this: