The myth of developer independent systems

Today a colleague of mine was asserting that the core reason of sloppy development is not having detailed quality procedures, i.e. bureaucratic systems independent of who is following them. I told him that we have more than enough development procedures, that any complex system is always dependent on the quality of people who implement them. If a project is sufficiently complicated and there is time pressure and market competition, you need high quality people who can evaluate risks realistically, tailor standards and cut corners to save time and effort. But they are also acutely aware of technical debt and clean up the quick and dirty solutions when time permits it.

You never have enough resources to develop your ideal system and always have to settle on a viable product. If your chief engineers are not wise enough, they will underestimate complexity, confuse priorities and take unreasonable risks. The problem is that they won't know that those risks are high. For them it will look like a brilliant course of action, until disaster strikes. If they are bad enough, they won't even be able to learn the correct lessons from failure.

Bad products are not the result of bad procedures but bad engineers and managers. The shortest path to success is to find and nurture good people who can develop quality products, write realistic procedures and make the team better.

Letters to a novice programmer: Content priority

It has been a long time since our last letter. Today I would like to talk about prioritizing content. When writing code or documenting a complex (more than 1 man*month of effort) project, you should always start with high priority features/content first. For example, if you are writing a developer handbook for a piece software, start with the most frequent use case first. Do not write page after page about design details that are not important for that particular use case. You will NEVER have enough time to write about everything you think is necessary. By documenting/coding high priority items, you maximize document/software usefulness.

Sokak köpekleri

Başıboş sokak köpekleri tartışmaları genellikle hayvan sevmek / sevmemek boyutuna indirgeniyor, köpekler konusunda kaygı belirtenler hayvan sevmemekle suçlanıyor. Sokak köpeklerini besleyenlerin şu hususları akıllarında bulundurmalarında yarar var:

• Köpekler alan koruma ve genişletme içgüdüsü olan hayvanlar, sürü/çete halinde dolaşıyorlar ve iriler. Onların alanından geçerseniz sizi en azından havlayarak tehdit ederler. Bir tanesiyle baş edebilirsiniz belki ama beş on tanesi birden gelirse, kadın çocuk veya yaşlıysanız size kolaylıklar dilerim. Kedilerde bu sorun yok çünkü hem küçükler, hem çeteleşmiyorlar hem de köpekler gibi alan korumaları yok.
• Evinde köpek besleyenlerin köpeklerini sokakta gezdirmesi stresli bir faaliyet, çünkü başıboş köpekler yabancı köpeklere alerjiktir.
• Yurt dışında, özellikle Almanya ve Amerika'da uzun zaman geçirdim, sokakta bir tane başıboş köpek görmedim. Onların bizden daha az hayvan sever olduğunu iddia etmek zor.
• Köpeklerin yola fırlamasından dolayı trafikte kaza riski oluşuyor, daha bu sabah servisimiz bir köpeğe çarptı, az kalsın başka bir arabaya da çarpıyorduk.
• Köpek tarafından ısırılırsanız 30 gün boyunca uzman bir sağlık merkezine giderek kuduz aşısı olmanız gerekir. Köpek ısırmaları köpeklerin sayısındaki muazzam artışla epey artmış durumda.
• Köpekten korkan, köpek oynamak niyetiyle dahi olsan kendisine koşup havladığında paniğe kapılan çok insan var, özellikle kadınlar ve çocuklar. Bu insanlara "korkma canım" demek, köpek davranış uzmanı olmasını beklemek haksızlık. Köpek nedeniyle panikleyip düşen, kolunu bacağını kıran iki kişiyi şahsen tanıyorum, aradan bir yıl geçtiği halde hala ağrı çekiyorlar. Köpek korkuları daha da artmış durumda.
• Bir tanıdığım geceleri sürekli havlayan köpekler nedeniyle uyuyamaz hale geldi ve taşınmayı düşünüyor.
• Yedi yaşındaki oğlumun beş dakika mesafedeki okuluna yürüyerek gitmesine izin veremiyorum çünkü sokakta köpek olabiliyor. Çocuğumun kendi başının çaresine bakabilen bir insan haline gelmesini mecburen kısıtlamak zorunda kalıyorum.
• Gözümüz gibi sakındığımız, travma yaşar diye sesimizi yükseltmekten çekindiğimiz çocuklarımıza köpeklerin saldırdığını bir düşünün, ebeveyn olarak ne hissedersiniz? Saldırı olasılığı düşük diyebilirsiniz ancak son derece olumsuz sonuçların yaşanması için bir kez olması yeter. Bir ebeveyn bunu göze alamaz.
• Sabahları bisiklete binmek, koşmak gibi aktiviteleri unutun, şehirlerimiz tamamen köpek işgali altında.

Şehirlerde giderek artmakta olan köpek nüfusu ciddi bir sağlık ve güvenlik tehdidi oluşturuyor. Sokak köpeklerini besleyenlerin niyetlerinin halis olduğundan şüphem yok ama neye katkıda bulunduklarını da bilmeleri gerek.

When (Several) Dogs Attack

Get SVN revision and write to header file

I am creating a C++ dll file from a MATLAB Simulink model. The simulink model repository is hosted on subversion. I needed a way to embed simulink model subversion revision to dll so that the dll could return that revision via an interface method to interested clients. I wrote the following batch file to fetch revision from SVN and write to a header file:

Why I prefer exceptions to error codes

Why I prefer exceptions to error codes:

Error codes are far safer for well-reviewed, critical code ...for most code, failing early [with exceptions] is better simply because it always makes debugging easier – even if it doesn't make the impact of the error smaller... With an exception, you get a call stack, and an error string from the bottom layer.

FIFO queue use case

I have a simulation whose number of time steps varies according to inputs. To find the last state of the simulation via interpolation, I need to save the last N time steps. I can use a FIFO queue to save the results of last N time steps (e.g. to use in interpolation). Pseudocode:

step() {

    result = calcStateAtCurrentTime();

    queue.push(result);

    if(queue.size() > N) {

        queue.pop();

    }    

}

Bonus: To print unsigned int 64, use printf("%"PRId64", myUInt64)

Why you should take warning C4013 seriously

A piece of legacy C code that was working fine on Windows 7 64 bit was crashing on Windows 10 64 bit. After a couple of days of detective work I found out that it was related to warning C4013: 'malloc' undefined; assuming extern returning int. Simplified version of the code is as follows:
When I build the code with Visual Studio with the x64 platform selected, I get two warnings:

When I run it on a Windows 10 64 bit PC with x64 setting, I get access violation:

When I look at the variable m->a, I see "unable to read memory":

To solve the problem, I have to include stdlib.h:

Explanation: You get away with it on a 32 bit build because the size of int is the same as the size of a pointer. On the other hand if you build your program as 64 bit program, the warnings become really relevant, because now pointers are 64 bits wide, but as the compiler assumes that malloc etc. return ints (i.e. 32 bit instead of 64 bit for pointer) everything get messed up.

Why does the compiler issue a warning instead of an error, even tough it cannot find definition of malloc: The symbol foo, without a declaration, is totally unknown to the compiler. Because it just compiles your code, but it's not responsible for the linkage of your symbols (I say symbols because this can include variables and functions)... The linker sees the symbol foo(4 bytes) and will start to look for any corresponding definitions of foo(4 bytes). And if it finds that (say, in another module of yours, or in the libc of your system, or as syscall wrapper), then the linker is content and it will create the executable.

When I commented out the stdio.h include, I got C4013 warnings for both printf() and getchar() as expected, but I also got a linker error for printf: "LNK 2019 unresolved external symbol". When I looked inside stdio.h for their definitions, I saw that the definition of printf was more complex and contained __CRTDECL, defined in vcruntime.h which I think is part of visual studio specific libraries, not "core" C/C++. vcruntime.h resides under Program Files (x86)/Microsoft Visual Studio 14.0/VC/... folders, while stdio.h resides under Program Files (x86)/Windows Kits/10... folders. I guess the linker always looks into the standard libraries, even if you don't include their headers.

Why is it crashing on Windows7 64 bit but working fine on Windows 10 64 bit? I don't know :(

Bonus 1: You can configure Visual Studio to treat 4013 warning as error so that the build stops.

Bonus 2: All the different reasons that can lead to a LNK2019 unresolved external symbol error. Recently I got it because I tried to use a cpp function from a c file.

Music: Internal Conflict (Black Mesa: Xen Soundtrack) - Joel Nielsen