Saturday, August 13, 2016

What makes software development difficult

The Law of Leaky Abstractions: "...suddenly one day we need to figure out a problem where the abstraction leaked, and it takes 2 weeks."

I don't have time to read the spec of every function before using it, I make assumptions based on the name of the function. This means that I take risks by using something without completely understanding it. The benefit is speedy development. As long as the problems are limited to a couple of things that leak, it is manageable by testing and debugging. But sometimes many of them team up and you have a "bugfestation". Unfortunately, even one simple error can crash and burn the whole system in unpredictable ways.

Example1: I assume that the strlen function in C returns the whole length of the string and use strlen result in malloc. Later I am greeted with system crashes which happen only on some versions of Windows. After months of debugging looking for the bug in unrelated places, I realize that strlen does not return the terminating null character and in malloc you have to do strlen+1.

Example2: I write a script to synchronize my drive to my network backup. Then I realize that some folders were not copied. After analysis I see that xcopy fails with "insufficient memory" error when path+file name is longer than 255 characters, but I don't infer that at first from the error message. A better message would be "file name longer than 255 characters". It would be even better if xcopy didn't have this limitiation in the year 2016!

Example3: I assume NASA code is correct, but that is not always the case.

Example4: I assume MATLAB functions are correct, but that is not always the case. The more depressing fact is that the MATLAB folks will resist your claims, even after you mathematically demonstrate that there is an error.

These issues make self discipline and testing early/often so critical. It's also the reason why 95% of code takes 95% of the time and the remaining 5% take another 95% of the time, because in the last 5%, you realize that libraries you trusted had errors in them. Therefore it is common to be late by at least 2x the planned time.

Bonus: Case of the Unexplained

Friday, August 12, 2016

What do I add to science?

From time to time, during discussions with my fellow engineers, the question of what we add to science comes up. To contribute something new to existing science knowledge is very challenging. If you focus on newness you might feel bad, and it will not help you move forward. My approach is to make sure that I get better at something everyday. That thing might not be new for science, but it will be new for me.

A similar post: Obsession with authenticity

A software training instructor's interesting observation [Hanselminutes podcast 331]: Men do a small thing and feel amazing while women worry about the stuff that is still left.

An example of a small step for mankind but joy for me, my very first Lego Mindstorms EV3 line follower:

Sunday, May 22, 2016

Life as a Game

I like computer games. In the past, I played Starcraft to the point of exhaustion, playing it more than 10 hours at a time for days. The problem with games is that they don't add much to your life. Besides, games are not all fun. Every game I played had a lot of boring repetitive tasks, which resembles real life in that respect.

A good game starts simple and builds up over time whereas in real life I am usually confronted with a large mess. That is what makes games fun and real life a chore. A main reason of procrastination is that I don't know where to start, so I keep postponing it. When I spend some extra time to analyze the problem and divide it into smaller pieces, it becomes manageable, even fun. Writing down what I think helps a lot. And when I solve a problem in real life, I gain skills that I carry with me my whole life, besides having the satisfaction of doing something useful and being able to control my environment.

I still play games (currently Clash of Clans) but I only spend about half an hour a day. I have more fun doing real things (teaching my 4 year old, learning how to make Mousse, developing web apps). I encourage you to view life as a growth opportunity, as a game where every skill you gain unlocks new ones. The key is mentally breaking large chunks of work down into less threatening smaller ones. These small chunks can be dealt with as if they were levels of a larger game.


Saturday, May 21, 2016

Puana Göre Üniversite Sıralama

İstediğin taban puan aralığını girip üniversitelerin bölümlerini sıralayabileceğin bir web uygulaması oluşturdum, linki şu:

Kodu GitHub'a koydum, meraklısı oradan inceleyebilir.

Başkaları tarafından yapılmış daha profesyonel hali:

Sunday, May 08, 2016

Graphical User Interface Nightmares in Java

Compared to Windows Forms, doing GUI work in Java is painful because you have to deal with a lot more detail. Recently, I was trying to customize tab drawing in JTabbedPane to make the font of the selected tab bold and its background color green. I ended up creating a class (MyTabbedPaneUI) that extends BasicTabbedPaneUI and overrides paintTabBackground().
public class MyFrame extends javax.swing.JFrame {
    public MyFrame() {
        javax.swing.JTabbedPane jtp = new javax.swing.JTabbedPane();
        jtp.setUI(new MyTabbedPaneUI());
        jtp.add("My Tab 1", new javax.swing.JPanel());
        javax.swing.JLabel jl1 = new javax.swing.JLabel(jtp.getTitleAt(0));
        jtp.setTabComponentAt(0, jl1);
        jtp.add("My Tab 2", new javax.swing.JPanel());
        javax.swing.JLabel jl2 = new javax.swing.JLabel(jtp.getTitleAt(1));
        jtp.setTabComponentAt(1, jl2);
    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new MyFrame().setVisible(true);
public class MyTabbedPaneUI extends javax.swing.plaf.basic.BasicTabbedPaneUI {
     * NOTE: Do not perform lengthy operations (e.g. setting font to bold) 
     * inside this paint method because it causes high CPU load and has 
     * side effects like not being able to update java3D drawings.
    protected void paintTabBackground(Graphics g, int tabPlacement, 
                       int tabIndex, int x, int y, int w, int h, 
                       boolean isSelected) {
        for (int i = 0; i < tabPane.getTabCount(); i++) {
            Color bgColor = Color.YELLOW;
            javax.swing.JLabel jl = (javax.swing.JLabel) 
            if (jl != null) {
                if (i != tabIndex) {
                    bgColor = Color.GREEN;
                } else {
            Rectangle rect = rects[i];
            int pad = 2;
            g.fillRect(rect.x+pad, rect.y+pad, rect.width-2*pad,
Setting font to bold (by uncommenting the lines commented as "BAD") in BasicTabbedPaneUI.paintTabBackground causes more than 7x CPU usage:

I have witnessed cases where CPU usage shot up to 100% and my app could not update a java3D drawing on another window. You can imagine that it was not easy to find out why.

Other examples of why Java should be avoided for GUI work:
  • Changing color of a JTable cell is a lot of work.
  • For background color to have any effect, JLabel has to be opaque while JTextArea has to be not opaque (opposite of their defaults)!
  • Due to the unintuitive layout mechanism, what I see on design view is completely different from what I see when I run the application.
  • When I change the layout, sometimes all the components dissappear (their width and height becomes zero).
  • Setting the width/height to "Preferred" sometimes causes the component to shrink to zero size. From what I understand, the layout mechanism is there to ensure proper resizing, i.e. to have a similar look when screen resolutions, font size etc. change. As usual, when trying the solve the most general case, you make it more difficult to solve simple cases. 
My layout strategy:
  • Create a frame
  • Add a panel with null layout.
  • Add subpanels to group components
  • Set the layout of subpanels. The layouts I use most often:
    • null
      • Advantage: You can set the location and size of components.
      • Disadvantage: If your form is resizable, components won't resize.
    • GridLayout;
    • BoxLayout

Thursday, March 31, 2016

How to improve quality of legacy software

When developing software from scratch, I follow these steps: Use cases (aka concept of operation), requirements, design, code & unit tests, system test planning, system test.

Recently, I was asked how to improve the quality of a software written by other people a couple of years ago. I was informed that it was working, the only missing thing was compliance to software development procedures. I recommended to do the above sequence in reverse, i.e. first planning and executing full system tests. That way, we can answer the most important question, "is it working correctly". After we are satisfied with the tests, we can review and document the design and refactor code.

Even if we have to stop after testing, we will have added value to the existing product by being able to demonstrate in a repeatable manner that it is working. If we started the development sequence from the beginning and had to stop midway due to other priorities (which always happens), we would have wasted our time.

Wednesday, March 30, 2016

Model simplification strategies for testing

When developing complex models/algorithms, it is usually difficult to evaluate full model test results. The only option to verify complex model output is to compare it with some other implementation, for example Matlab toolboxes.

In addition to using 3rd parties for comparison, you should add functionality that lets you to simplify the model to a form whose results can be easily interpreted by a technical person. For example, if you are working on an algorithm that converts Geodetic coordinates to ECEF, you could have a function that temporarily sets the ellipsoid to a sphere (by making the eccentricity zero). It is easy to calculate expected results for a perfect sphere.

Similarly, if you develop a kinetic 6DoF flight simulation, you should have functions or flags that let you easily turn off complicating factors like aerodynamics (by multiplying coefficients with zero), wind, variable gravity, Coriolis, ellipsoidal Earth and terrain elevation. Your aim is to simplify your model to a ballistic flight in vacuum with constant gravity over a flat and non-rotating Earth. You can then use high school physics to calculate expected trajectories and compare them with your model outputs.

To clear doubts about your code, you should be able to quickly show that it obeys basic geometrical/physical laws.