Software development is somewhat specific field. All you need to create an application is a computer, text editor, a compiler and some spare time and you are ready to go. And if you are developing in script language, you don’t even need a compiler. Hence, anybody with some spare time on their hands and an internet connection can learn how to code. Due to this, people get a false perception that creating good, working software is an easy thing to do. And this lead to the situation we have now, where numerous companies employ just about anyone that can copy & paste Hello World example from Wikipedia.
When I was in high school, I preferred spending time programming than studying oh, let’s say geography. Even if I wasn’t programming or (let’s be frank) playing games, I still found numerous things I could do that were not studying. I even washed dishes after lunch. This of course resulted in not so stellar grades and lots of not so nice looks from my parents. Specially, since my sister was a total opposite. Always ready to study which of course resulted in good grades. However, the thing was, that when I got a B+, parents were pleased, whereas when my sister got a B+, they were nearly disappointed. A B+ for me was considered success (even though, I really needed a kick in my lazy behind) and for my sister, getting better grades, that was considered a failure. Unfair? Maybe. But that is what happens when you build up expectations.
Ever seen a movie that everybody highly recommended and was later disappointed? Or seen a movie that people said it was crap, but you still managed to enjoy it? Yeah, that’s what building up high expectations does. Same thing happens in every profession you can think of. And specially in software development. Ever seen a great developer not getting praised for a monstrous feature he implemented superbly and fast? Then on the other hand, you have seen a person that works way below standard getting the praise for job done? And I am not talking about good done. Yeah, that’s what I am talking about.
The thing is, there is no way to avoid this. People don’t do that on purpose. You see, once you set up high standards, sticking to those standards becomes a regular thing. This leads people to believe you are just doing your job. On the other hand, not doing work properly lowers expectations and any positive deviation will make people happy. You don’t want to be in that situation. Neither as manager nor a developer. If you work in any normal company, your boss still prefers developer that did great work from the one he just complimented. You see, what he did is called positive reinforcement. And he did it in hope of getting better results from developer that failed to do so in the past. This might work on good developers that got lost in the process. Good developers know that the praise was unjust and that they need to step up. Complimenting poor developers for poor job done just makes them believe they can get by with mediocre product.
And the same thing happens with customers and your products. Constantly delivering great product will spoil your customers which in turn will make them expecting great stuff from you at all times. Now, I am not saying you should deliver mediocre products as customers know good from bad and they really don’t like spending bucks on mediocre. What I am saying is that delivering great product must be your imperative at all times. There is nothing worse for your company’s reputation and wallet than releasing not so great version and hence, disappointing customers.
I started working at age of 19. At that point, my solution to a given task was to jump and code. Mostly because that was all I knew how to do. Partly, because I never had problems with writing loads of code fast. However, whenever I seemed to be near the solution of a given task, I noticed that my code is getting more and more complicated. Mostly to the point where I wasn’t able to actually solve the task in the way I thought I would. Or sometimes I was in the middle of the code, when someone decided to change the functionality to the point my code was useless. So I started over. And over. And over. Until I figured out the “correct” way.
Lately, I noticed, jumping straight into the code is still a common problem with young, enthusiastic developers. It is understandable. First impression counts the most, and show me a young developer that doesn’t want to impress his peers. Unfortunately, what young-lings don’t get is that writing poor code will do the exact opposite.
It took me a while and loads of hit and miss attempts to finally figure out, that the best thing you can do as developer when facing a new task is to take a deep breath and think hard about the solution prior to writing a single line of code. When you start coding without thinking, you risk missing an important part of the task or worse, you risk misunderstanding the task completely. In the best case, you will implement something that no one, not even you, will be able to maintain. You see, considering the assignment will make you think hard about all needed components. And when something is not clear to you, you can research it or just go and ask a person that knows more about the subject than you do. Then, you can write a functional spec, which will help you plan and execute the solution.
You know why people are so keen on MVC frameworks? Because it forces developers to separate UI, data model and business logic. Sure, I have seen people still mixing responsibilities in MVC, but I have never seen such gigantic f**kups as with ASP.NET Web Forms. I am willing to bet that if you assign random developers to Web Forms project, you will start seeing business logic, UI code and data logic all tied up in one event handler. I’ve done it for sure. I don’t have the data to prove it, but I think any developer who had something to do with Web Forms did it at least once. But why is that?
I am sure there are plenty of reasons to use CDNs while developing public internet application, but when you are developing intranet applications, it is better to stay off CDNs and use local resources. Specially for young developers, who have grown up with them, it is difficult to see why. Here are my four reasons as to why you should not use CDN in intranet applications:
- In high speed gigabit ethernet environment, there is a high chance a CDN resource will take longer to load than local resource or entire page for that matter.
- Even though the company uses high-speed ethernet, CDN can become slow or unresponsive due to internet provider issues. In that case, the application will most certainly break.
- While it is tempting to use latest and greatest resources CDN offers, it can happen that new version of CDN resource breaks your application.
- In extreme cases it can happen that CDN resource gets compromised and turned into super evil script. The affect that has on you and your users should be self-evident.
There is this application I wrote several years ago that is in use for planning and reporting absences and vacation (also discussed here and most likely in some other article as well). Lately, I noticed the very same application working slower and slower to the point of users complaining. I decided to investigate.
The most difficult thing in any company is to change it’s culture. You see, companies are used to operate in certain frames of mind and they do not accept change lightly. Also, people have the tendency of sticking in comfort zone. Working in standard and set ways is nice and comfy. Why on earth would I leave this place for something big and scary? Well, for starters to improve yourself. And improvement is always good. Stagnation, bad. Improvement, good. OK?
In my 15 year career, I have yet to encounter a software company in Slovenia, where code review would be a part of work process. It is surprising how many companies just don’t care what kind of code they produce. And this is exactly the reason why most software originating from Slovenia, well, sucks.
There are some things that are unreasonably difficult even in this day of age. Well, not exactly difficult. Let’s say programmer unfriendly. For instance, opening a new mail window in your default mail client from windows .NET application. Preferably with address filled in. Google for it and you will get the same answer I did. Just start a process with “mailto:firstname.lastname@example.org” command. Sounds simple enough. Right?
If you want to sell software to me, you only have to follow these three simple rules:
- Do not lie to me.
- Have full featured trial version.
- Respect me.
Sounds simple right? It is. Except, there will always be that smart sales person that will say something like: “Why don’t we let users download a free trial, but when they want to actually do things with our software, we will make that impossible for them and instead cunningly remind them that they need this and this license to do that. Yeah. That surely beats time limited trial by a huge margin.”
Guess what, you just violated all three rules. Let’s analyze how?