Getting too close

One simple quote from the movie No Strings Attached got stuck in my head:

I’m warning you, if you take one step closer, I’m never letting you go.

And I wondered how this quote would find its way into the software world. And there are indeed some analogies you can make to this quote. It often happened to me to find out that I’m really fond of some application. Or that I use some sites regularly, just because they make fun, their a pleasure to use. That’s also true with, for instance, programming languages. Or even development methods or patterns.

If you find something to be that compelling, that you can’t stop using it, than you get into addiction. And you might not want to let it go anymore. It’s like me with Google Chrome. Or with Total Commander Ultima Prima. Or maybe like the first time I ever used Google. It instantly felt that this is something useful, and so cleverly implemented, that I will continue using it, that I will not let it go. Like maybe Mikogo.

WPF and MVVM: I’m thinking, yes there are some small improvements that could be added to the WPF framework to better allow the implementation of MVVM, but overall, I’m just a step away of sticking with it for a long time from now for developing desktop applications.

So there are situations in a developers life when you just want to stick to something. There are so many possibilities out there (languages, frameworks, tools, methodologies, …) that personally I often wish I could say: this is what I need, I’ll stick with it forever. But then some missing command or some missing functionality, or just bad performance make me say: Hmm, I’ll have to look for other options too. And then I continue investigating and testing other stuff, and sometimes I find something better, sometimes I don’t. This search for something better is frustrating and exhausting. I just wish, software in generally would be even more perfect.

But that makes me think: what does it take for something to be so great, that it’s actually not a step away from what you wish for, but a step further than what you might expect.

One step away from my expectations would make me say: Yeah, it’s ok. One step closer, and I’m never letting you go.

Meeting my expectations would make me say: YES, this is for me! I’ll keep using it.

One step further than my expectations would make me say: WOW!

Living on the Internet

Not surprisingly, from a movie like The Social Network one memorable quote on IMDB is:

We lived on farms, then we lived in cities, and now we’re going to live on the internet!

Actually, there’s much truth behind this quote. I mean I work in front of the computer 6+ hours per day. With peaks of around 12 hours per day. That’s between a quarter and a half of day. And that everyday (except maybe weekends, but sometimes, like right now, I spend time using the computer in weekends too)! Of course, this is because my job is IT oriented and it involves intensive computer-based activities. At times when I used to write code at my job, I worked with the computer a lot more. But the activities were not that much “socially” oriented. Now my activity is more oriented to communication. On an average day, I receive about 70 emails and send out about 35. I actively chat with my colleagues via different IM tools (mainly Office Communicator, Yahoo Messenger and Skype). In my Outlook Conversation History folder I have about 50 conversations daily (and that’s only what the Office Communicator is saving).

My point is that my daily activity is very much based on, relies on and is influenced by the Internet.  It’s probably the same for my fellow programmers and co-workers. So, yes, we’re going to live on the Internet – and actually living right now.

Choosing not to believe in the devil doesn’t protect you from him

I watched “The Rite” the other day. Unfortunately I was quite tired and fell asleep at about half time. But I remember this quote:

Be careful, choosing not to believe in the devil doesn’t protect you from him.

As in my previous posts, I want to try to identify some correlation between a movie quote and the software development world.

Is there a devil in software development? Is there something we must protect ourselves from when writing code? And if yes, how can we protect ourselves?

When I write code or when I’m reviewing code, I noticed some things that could stand for the “devil of coding”. Some are simpler, some are more complex, but all of them could be considered as pitfalls, which sooner or later will come back and haunt you. Let’s analyze some of them:

• not using coding guidelines: either you don’t have coding guidelines at all or you are not sticking to them, it’s both as bad. It distracts fellow developers when they’re doing code reviews. A bad impression about the code will make other developers not wanting to even touch the code. It’s scary as hell. You can compare it to a book full of small spelling mistakes. Would you want to read the whole book?
• not doing code reviews: You have to see and check code written by your team mates. You also have to check your code, too. And this regularly! You have to check your code after some days after you have written it. You will find you could have written it better and will think to yourself: “was I possessed when I wrote it?”. Even if you are not hired to do code reviews (yes, there are actual jobs for code reviewers), you still have to look over every check-in of your team members when it occurs or at least when you have to use something they have developed. Remember: you actually have access to the code written by your colleagues. Use it to learn something from it or tell your opinion to the others if you think the lurking devil may be inside the code you just saw.
• don’t over complicate things: I mean: just KISS the devil! It’s always a tendency to over complicate things. Probably by making an overcomplicated architecture, by using complex class relationships or by using super long methods with lots of parameters the developers try to impress someone with their advanced coding skills. But its quite the opposite, I would say. Those developers who are able to keep everything simple and understandable are the ones who build maintainable, stable and future oriented solutions. “Simplicity is the ultimate sophistication!”
• not refactoring quick&dirty implementations: It’s always the same: a developer is asked to try something out, or he just wants to show how quick he can implement it, and he goes right ahead and writes the code to do that. What he actually did by following this approach is to develop a prototype. But as everyone knows, prototypes are meant to be a proof-of-concept. Prototypes validate a concept, nothing more. Afterwards, the prototype should be thrown away and based on the facts learned, the actual implementation should be done. This means: rewrite the evil prototype code! Refactor it, document it, test it, connect it to other components in the project. Let it then be reviewed, not before. If you don’t have time to rewrite it, the least you can do is mark the whole code with a TODO statement, so that you remember to do it someday. Thinking “Oh, cool! It worked just straight ahead! I’ll check it in and I’m done.” is like thinking the devil doesn’t exist!
• not using Unit Testing: I heard a lot of reasoning that unit testing aren’t really useful, that there isn’t enough time to write tests, that eventually you still won’t have 100% code coverage, etc. But this is actually like saying the devil doesn’t exist, when in fact, everyone knows that no code is perfect and the probability that there are bugs in your code is actually so high that all reasoning against unit testing is worthless: you just have to do everything possible to limit the number of bugs found in your code.

The conclusion is: not being aware or ignoring these things won’t help you in your career. Sooner or later, the devil will catch you! You have to protect yourself by learning and reading about these topics. Acknowledge them as part of your life as a software developer. Be vigilant and pragmatic! It’s all up to you to become a better programmer. Don’t rely on exorcists to fight out the devil in your own code.

To distract you from what?

Because my last post was related to a quote from a movie (Remember Me), I thought it would be fun to use quotes from movies for my blog posts and correlate them to Software Development.

Recently I only saw The Tourist, which unfortunately doesn’t have really interesting quotes, but I said, “what the hell, just pick one quote from the Memorable quotes for The Tourist”. Actually all quotes are memorable, because they are (very) short and use simple words, which even my little daughter would understand. (But of course, even if they are memorable, I don’t recommend anyone to memorize them).

So let’s take this quote:

This is exactly why (s)he chose him. To distract us.

What if we would replace him with it and think that us stands for us, our software development team and (s)he stand for the project manager or a colleague. I think it’s pretty interesting to see what connotations derive from the transformed quote “This is exactly why he chose it. To distract us.” when we give “it” several meanings.

There is us on one side and (s)he on the other side. How often did you, as a member of a software development team, thought like this? The project manager (or the product manager or the client) is on one side and you, the poor fellow who has to implement something on the other side. All decisions made by others for you will make you think about why they made that decision. And mostly, you won’t get a satisfying answer to this question. But since this is a question, and you as a software developer always have to get an answer to your questions, you often invent an answer. Not every time the answer is the best one, but you are pragmatic and don’t need the perfect answer, you need an answer that will get you going. One of these answers is seldom (I hope) this one: “To distract us”. This would mean that the decision-making party would have intentionally made a decision to distract you, which I honestly don’t think anyone does. Only perhaps to hide some lacking knowledge of him or to let you think he knows  something better, when he in fact doesn’t.

But nonetheless, this would mean that you are living in a black box, where decisions are being made without your implication and everything seems to be done just to distract you.

To distract you from what?

I think that software developers are always distracted from being inventive, from being creative or being motivated when you make a decision without involving them properly. If they do not have a word to say related to a decision, if they don’t have the time to think about possible solutions to a problem or if they aren’t allowed to test and prove their own ideas, they will feel distracted and unmotivated. Let them be analytic and pragmatic. If you, as a project manager, team leader, leading developer or every other title you may have, take each developers decisional role away, they will feel unnecessary and after a time they will only do what they are told to. They won’t be creative any more and they will not search for solutions on their own. This is definitely not something you would like in your team! If you always choose the frameworks to be used, if you always choose your preferred coding style, if you always choose the design patterns to be used or if you always have to impose your class diagrams, your team will slowly, but surely, become unproductive.

My goal is to let each developer come with ideas. Let every developer search for solutions and let them present their findings. If we would always use what is being imposed to us (like for instance standard patterns and frameworks) there would be no more really ingenious ideas coming out. We would start getting to think only inside the box, rather than outside the box. If every programmer has the chance to come up with solutions and to present them, the team will make the final decision. Thus there won’t be a person to blame for an unfortunate solution, instead the whole team would stand responsible for every decision.

Let each programmer think and let the team be his jury. Don’t choose something that your team can choose. Don’t distract them from thinking. Don’t distract them from being open-minded! Let them Find the Box.

Do It Anyway

I recently heard an interesting quote from Ghandi:

Whatever you do will be insignificant, but it is very important that you do it.

Of course on a micro-scale, your actions might seem important and may have an influence on the near future. But on a macro-scale, your actions and everything you do as an individual, will not change a lot in the universe and will be just lost in time.

But then why should it be important to do something? Why should we even begin doing something, if we know for sure it will not be something that will change the world?

I will try to explain why by describing how this applies to software development. An average programmer doesn’t write that much code. Most of his time he is debugging, testing or reading. Writing new code might take about 10% of his time. Altering existing code might take even more than 10% of his time.

When a developer changes existing code, he has a goal: make the code do what it’s supposed to do. But this could be done in a quick & dirty way: just fix the code with a minimum amount of effort (because it will be just an insignificant change after all, isn’t it?).  Even if a quick fix does the job and the developer might even get appreciation from his not-so-clever-looking-into-code manager, this simply isn’t enough.

You, as a professional developer, should do the following additional tasks when fixing a bug or every time you look over existing code:

• refactor: change code in such a way that it is easier to maintain and more understandable. Rewrite the code in a better, cleaner way, keeping the functionality intact. Refactor to patterns. Break dependencies. Every time you identify some part of the code which might be refactored and you think “it’s not worth the trouble” or “I don’t have time for this”, you should Refactor It Anyway.
• rewrite: if you see some piece of code that may be written in a better, faster or shorter way, rewrite it. Even if it just saves you a line of code or spares you a local variable, you should Rewrite It Anyway.
• rename: properly rename methods, variables, properties, classes, interfaces. Rename everything that doesn’t reveal its purpose at the very first moment you read it. If you see a variable named counter and you think “oh, I understand now what it counts” after reading some lines of code, you should rename it. Even if a variable is needed in just a line of code, you should Rename It Anyway.
• comment: write comments whenever you write code that isn’t trivial. Always ask yourself: if someone else reads this code, will it be understandable? Comment methods, but also classes and interfaces. A method like GetSerialNumber() might not need a comment, but a SerialNumberDecryptor class might need one. Even if it takes you just a second to understand a piece of code, you should Comment It Anyway.
• cleanup:be vigilant! Don’t leave ugly looking code behind you. Remove unused code, remove unused namespaces or unused variables, remove test files. Properly indent code. Make sure you respect coding conventions. Don’t live with broken windows. Even if you notice some misplaced spaces in some code, Cleanup It Anyway.

Everyone of this actions are insignificant compared to the whole project. But it’s important that you Do Them Anyway!

Reasons for Blogging

I blogged before about encouragement of developers to blog (here and here). It turned out, I also needed some sort of direct encouragement. After all, every person’s actions are better executed if there is some sort of encouragement and motivation driving them.

So what type of encouragement did I receive?

First I have to describe the purpose I am blogging. This is a question I had small problems answering. It’s not because the purpose isn’t clear to me, but because it’s difficult to explain someone why “I’m wasting time” doing it. After some analysis, I can say I properly defined the purpose of my blogging:

1. become a better writer: like so many things in life, you can only do them better if you do them repetitively. It’s a matter of exercise. Some examples that come to my mind: speaking, cooking, dancing, sports, and even programming. The more you exercise, the better you will get. The same applies to writing. I must say, I’m pretty sure about this: writing can be improved. And it doesn’t really matter what you are writing – the very act of trying to serialize your thoughts in a concise and understandable manner is like doing push-ups on a regular basis: at first you can do about 2, but after some months of practice, you can do more push-ups by a factor of about 10-20. Of course, I could just write something in notepad or on a sheet of paper. But if you don’t receive feedback about your actions, if you’re the only person involved in some activity, you won’t know if you’re getting better at it. That’s why I’m writing to a public blog.
2. socialization: software development is all about interaction and communication! And I’m not thinking here about the classic image of a “hacker” who sits alone 24/7 in a dark room, trying to crack something. I mean professional software development, which has to deal with a product, a product owner, a team, and of course the users. In software development you have to communicate with the client, with your team members, with your users, with other members of your team and probably with other departments inside your company. Although it might seem odd, developers really communicate a lot, but I think their not aware of it. They do communicate in a lot of different ways: daily stand-up meetings, development meetings, pair-programming, code comments, check-in comments, documentation, code review, bug analysis. I’m most certainly 60% (of course I guessed here) of the developers don’t realize that when they write a comment inside their code, they actually communicate to someone else: the other developers who will investigate the code in the future (and be sure that someone will eventually look over the code!).
3. having a permanent online reference to my thoughts: some people keep an online diary, some twitter 50 messages/day, some are posting everything to facebook or other social networks and some are blogging. It’s an extra-professional activity, which defines you as a person. It’s important to let others see what your thinking, what your interest are, what your concerns are. It will eventually become a part of your resume! And this is something important! Almost every time I have an hiring interview coming, I first try to google the person’s identity online. I want to see if the person exists online: is he/she having a blog? Does he/she have a facebook account, and how many friends? Does he/she have posted comments in forums? Is he/she part of an online community? Does he/she asked questions on stackoverflow.com? I think every employer in the IT branch should do this type of checking before hiring someone. If someone would google me or directly access my blog, I hope they will get a clear picture about what my interests are.

The above 3 purposes make sense to me. They most probably don’t make sense to all readers, so I will try to sum up why I have set these purposes:

• writing: is definitely a soft-skill I need to improve and will help me permanently in my career.
• socializing: I want to get in touch with others who think like me. Or with others who don’t think like me but can properly share their different opinions.
• online reference: if someone gets my business card and searches me online, they should be able to get a better understanding of me.

Now lets come back to the encouragement I mentioned at the beginning of this post. You will definitely understand it if you see the statistics of my blog:

The spikes are after publishing the CodingPleasure post! I intentionally removed the Y-axis scale because it should not be relevant. This should be obvious from the above 3 goals: achieving a huge audience is not one of my goals!

From CodingHorror: There’s certainly value in audience metrics. But it’s easy to overanalyze, too. Instead of obsessing over who does and doesn’t link to you, concentrate on writing a blog entry you’d like to read. Instead of worrying about audience feedback, focus on delivering a presentation you’d like to attend.

So my actual encouragement isn’t the number of readers, but the fact that with that post I got my first blog subscriber and have received feedback from several persons!

CodingPleasure

I have developed software applications for about 14 years. I have written code in Pascal, PHP, C++, C#. I used VCL, MFC, ASP.NET, WinForms.

I always wanted to do a little bit more than just writing code. My goal was to manage projects and to be in charge of the whole aspects of a software’s life cycle. Fortunately, my current employer offered me the chance to advance from being just a developer to being team leader, then project manager and then site manager. This all happened in a relatively short time: about 4 years. Now I can proudly say I have reached my goal!

But my professional life changed a lot in this time. I have a lot of different tasks to do now. Talk to customers, talk to clients, talk to employees. Take part on meetings, do interviews, coordinate activities of different departments, go on business trips. Have an overview on all active projects of the site. Coordinate and manage difficult projects. Be informed on latest technologies and development methodologies.

Compared to my activities I had 4 years ago, what I do now can be seen as a complete turn-around (although I still have days when I spend 8-9 hours in front of my computer). Thinking about my new activities, I can say I really enjoy them all. I like doing all those new things. I like talking to people, I like managing projects, I like having administrative meetings or development meetings. I like meeting new people at hiring interviews. I like knowing and understanding the problems of running a business in the software branch.

But I also like writing code!

Writing code has been always something I enjoy. Although I’m most certainly not the best programmer, I find a lot of pleasure writing code. Having had some time to look at other people’s code, I think I also found out how to be a better programmer. Now I definitely understand topics like Scrum, TDD, Dependency Injection, Inversion of Control, Refactoring, Design Patterns, Unit Testing a lot better. I’m pretty sure that I became a better programmer by not programming. By reading about this topics, by implementing them in the projects I manage, by seeing the benefits of them, the urge to write code is even bigger now. Doing a code review always makes me want to just check the file out and start refactoring code! But I have to force myself not to write code, and instead suggest to other developers how they should write better code.

So how will my job look like in 10-20 years? Will the CodingPleasure go away? Will I still have the desire to write code?

To remind myself about the coding pleasure, I named my blog CodingPleasure. The name of the blog is also a word-play to Jeff Atwood’s CodingHorror. Many thanks, CodingHorror, for your truly inspiring blog!

First rule of programming: It’s always YOUR fault!

This blog post from CodingHorror proved to be true so many times!

It still helps when I forward the link to junior developers, who always think the framework, the IDE, the libraries, etc. have some bugs in them 🙂

Failed Apps

When I wrote my previous post (Cracking Password-Protected ZIP Files – The Smart Way) I realized that “I HAD TO download WinZip”. Something I wouldn’t have normally done.

This is because I stopped using WinZip a while ago. Because of several reasons, but mainly because it became a really commercial app. It was not difficult to replace it: the alternative 7-Zip is all you could ever need from an archive manager, I think! Its fast, small, understands a lot of compression formats, integrates into Windows explorer, etc. And it is free! Really free:

You can use 7-Zip on any computer, including a computer in a commercial 
    organization. You don't need to register or pay for 7-Zip.

But WinZip isn’t the only program I replaced during time:

• WinAmp –> replaced by AIMP
• Adobe Reader –> replaced by Foxit Reader
• BSPlayer –> replaced by KMPlayer

and probably much more. But all have something in common: they became commercial and now came bundled with a lot of features and other programs I really don’t need. WinZip has a 19 MB download package!!! 7-zip is just 1MB!

Another program which I replaced 2 month ago was Firefox. I replaced it with Google Chrome because Google Chrome is insanely fast on my notebook. It starts faster than any other program I have, even Notepad++ 🙂 Firefox might have been of course altered with all my installed add-ons (which I actually miss in Chrome), but nonetheless, Chrome seems faster in any aspect of web browsing.

So I have at least two reasons for replacing an app:

1. the application and its setup should only serve the application’s initial purpose and

2. speed in all its aspects (download time, installation time, start-up time, functionality speed).

Are there any other reasons why an application would FAIL and be replaced with another?

Cracking Password-Protected ZIP Files – The Smart Way

I’m struggling for some years now to crack a password protected ZIP files that I created 8 years ago. I have tried different brute force programs found on the net, but even though the CPUs are getting faster, it still would still have required probably a lot of years to crack it.

Today I found out that you can decrypt a password protected file if you happen to have an original file, or at least a part of it. These technique is called “Known plain-text attack”. So I realized that I had a file unencrypted and started investigating how I could crack my archive using this file.

Using free tools (like PkCrack) did not help. So I used Elcomsoft Advanced Archive Password Recovery. I managed to crack the archive in less than 1 minute!

But: I spent a lot of time figuring out how to prepare the input for Elcomsoft ARCHPR. I needed to compress the unencrypted file using the same compression level (and program I guess) which I used when I encrypted the files. After struggling with 7-zip and other archive managers, I had to download WinZip. These seemed to have done the trick!

Additionally, my files were inside folders in the archive. I prepared the archives to contain only the files, without the folders. It seems that WinZip can rearrange files in an archive, even if they are encrypted, 7-zip not.

And then the expected happened: using Elcomsoft ARCHPR I had decompressed and decrypted all files in the archive. They have been sitting there for 8 years and probably they would have remained there until the CPUs (or GPUs) would manage to brute-force my archive in a reasonable time.

Now I can enjoy my super-secret-highly-classified encrypted pictures again!