Category Archives: Technology

A techie’s day out :)

Programmer’s Bad Habits II

Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.

1. Carry over the dead code/experiments/comments with you.

Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.

2. I can’t fix another programmer’s code, rather I will rewrite it.

Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.

3. The world can be written only with “if-else” and “for” loops and method reuse.

Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.

These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.

4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.

I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.

Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.

It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.

The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.

5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.

Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.

Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.

6. Creating a build means compiling the code.

For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.

These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.

Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.

The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.

These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.

The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.

“Learning is not child’s play; we cannot learn without pain.”
– Aristotle

Share this post :

Advertisements

Programmer’s Bad Habits

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer 🙂

Till then Happy Thinking!

Hope to see you next time…

 

Share this post :

Reuse should be side effect and not the goal

Last night,I had a talk with one of my friend who is also a developer at some other company,In his project,client is always looking for cutting the corners by which he could save on cost of development.

As a clever IT manager,For faster development,client’s IT manager is insisting on a design which has reusable components identified and well laid out,while my friend is collecting requirements and doing the requirement analysis. But to my surprise,my friend is also feel good about this notion.I think I am bit behaving like a pessimist here but I am somehow feeling uncomfortable because of this thought…since here they are treating the goal of system designing or architecting as reuse while ignoring the sole goal of architecture is to better serve business…to find the solution for business…

In my opinion, reuse should be side effect of your design and not the goal of your design.

Certainly reuse is a good thing to have inside your system but it should emerge rather than we impose reuse as goal on our design.It suppresses the creativity of fitting and integrating the different aspects of the system as well as it dangerously introduces the dreadful impact of looking the entire world into black and white rather enjoying the diversity and cleverly utilizing diversity as a strength of system.

The trap lies in perspective of architect or people who are designing the system since “emerged reuse” can co-op with inherent business changes that are going to come in lifetime of system while in case of “artificial or induced reuse” system can not withstand with the upcoming changes of business.This happens and I had observed it since "intended reuse" imposes "reuse" as a goal rather than just a strategy inside the system.
So the components are built with keeping today’s constraints in mind.While architect or even end users of the systems are not sure that whether today’s constraints will be there in future or will be removed.

Just on a curious note,Have you anytime observed reuse as a goal?

 

Share this post :

Balsamiq Mockups Review

Nowadays I am doing requirement gathering and analysis for a good project here in Gibraltar.So you can imagine lot of user interactions ,taking interviews of end-users , sometimes shadowing them to their specific work function and lot of questioning etc are going on…at least project started off good and we are heading in correct direction.

For successful execution of project,the team which is going to implement or code,should get understanding of the ideas and concepts and functionality and thus the need of good mock up tool arise. These tools plays a vital role of explaining the ideas and bringing the life to boring documentation. It is truly said that “1 picture is equivalent to 1000 words!”.

In my previous projects,I had mostly used visio and its sort of standard at my workplace for mockups.Though recently I had also tried out serena prototype composer for one project.These tools have their advantages and disadvantages.

Visio is the huge software.It is not meant just for prototyping or diagramming.However,it comes at a price and it requires a lot of time to starting off and be expert with it.You can find massive features are poured on as just any other Microsoft stable software.After using visio ,I came to a conclusion that visio is good tool ,but still not a very handy tool for creating mockups quickly.

I explored a bit more on internet and found Serena Prototype composer.Serena prototype composer scores over visio ,when you want a clickable prototype.But then serena prototype composer needs to be installed where you want to run your prototype and seems to be pretty rigid kind of a tool.I didn’t like it much though it has unique advantage of creating clickable prototype.

Then again in search of perfect mockup tool,I downloaded and tried many. One day(actually night),when on the verge of just concluding that there is not so much great tool other than visio,I found the gold “Balsamiq Mockups”!!!

As a practice,Without much hopes,I downloaded and installed it.As a authentic software engineer,I never use manuals or help to use software [In fact,I had reached to conclusion that if you need help or manual for running a software,there is a problem with usability of that software]. Firing up balsamiq tools,I was just kind of landed in my dreams!! Since,it is just made for making mockups!!! Very no not friendly,I will say inviting user interface.there are all UI elements at the tops with really big and wide tool strip which shows of drag and drop user elements some common like buttons,text,all types of containers(i.e. group box,tabs etc) and some uncommon like accordion,cover flow,video player,street maps etc.The most surprising is I found sticky[comments as they call it ] and charts and graphs as well.Wow! pretty genius work.Since,many business software always need this and very few people do have mockups for this stuff.

basamiq-mockups

You can create a new mockup and start building your mockup by dragging and dropping these elements.When you drag and drop the vertical and horizontal guard lines appear to assist you for placing the elements,taking care of alignments which is again cool feature.

You can set properties of individual element by selecting the element and then property bar appears out of nowhere.You can drag it anywhere so that it will not disturb you or obscure the view of element that you are working with.Also The properties are fantastic set,Just as what needed no extras .These things truly live “YAGNI(You aren’t gonna Need It!!) agile principal.

On top of this,the mock up you created can be saved or imported as XML file or can be exported as PNG files.

Balsamiq Mockups team has really come up with really genius product !!

However,there is a saying that greedy man and end-user can never be satisfied  🙂

I must also point out some things that they can improve into their next version.

After using it for two or more weeks ,I realized that grouping and un-grouping of containers and their child elements are somewhat confusing to me.Since,The controls that we drag goes back side of group box and another thing I wanted is the ability selection of many controls like visio gives. As of now,to move entire thing,we have to group them.There must be the selection ability for controls that are not grouped.

The community of Balsamiq Mockups is also good.And they had come up with several templates that you can find at http://www.mockupstogo.net .

All in all,It is insanely great tool built by genius people out their at Balsamiq.I think I can saved at least 40% of time required to create mockups with Basamiq compared to Visio.I will certainly recommend that try your hands on Balsamiq and you will be happy making your mockups ever after.

 

Share this post :

Web Development Series-HTTP Basics

Nowadays, you pick up any developer and ask on what they are working on and you will get resonating answer of web development. But hardly half or even less than that knows which version of protocol “web” is running on! [DON’T GOOGLE! (I had did that 🙂 ) if you do not know, its HTTP 1.1] this also indicates how far the original designers of the protocol had achieved their goal of abstraction and laying out good protocol.

HTTP means Hypertext Transfer Protocol. The name itself sums up the web into it. Web is all about Hypertext [linked text] and data transfer from to and fro in its basic sense. We had gone further with HTTP, adding tons of things.

For any web developer/programmer, three things hold most prominent importance apart from his/her dev platform/language and these are the basic pillars of web. These are namely,

1.       HTTP Protocol

2.       Web Server(IIS, Apache, JBoss etc)

3.       Web Clients(mostly Browsers like Internet Explorer, Firefox, Safari)

So understanding these basics is of prime importance. In this post, I am going to only focus on HTTP and limiting my scope to what fraction of knowledge that is essential (read assumed to have) for every web developer.

HTTP can be thought of as a communication system. Somebody calls up (Request) and somebody replies (Response) and yes the acknowledgments.

This basic nature of HTTP itself defines the existence of two types of programs that we had seen on the above list.

The program which calls up the fellow program at the other end is termed as web server and the programs which replies back is termed as web client.

These programs had mutually decided how to talk and via which language. This is our beloved and long standing man, HTTP.HTTP basically does not hold up the info with it about previous requests and its use. This is called “state”. I had talked to many developers who talks about HTTP being stateless protocol but they, surprisingly, unable to explain what it means.

This stateless nature of HTTP passes the worry of maintaining state to its both end programs that is web servers and browsers and here concept of state management takes its birth and becomes necessity of any server side platform. We will see the state management in detail in following posts.

Now, coming back to HTTP world, the talk between web server and browsers happen through commands. You must be well aware of GET and POST but there are also more to them.

Wikipedia has good explanation for all of these commands. You can refer to it here.

Now, we’ll see most interesting part of HTTP which is related to most of the developers i.e. error codes that HTTP provides.

You must be familiar with 403,404 numbers and those yuck ugly pages shown to your face by your browsers. (To those who are into browser development, why can’t you put those system-error pages to some nicely formatted pages which are meant for HUMANS, everybody is not geek ;)) .Anyway, have you ever thought about what it means and why those numbers are given in such fashion. Well, for that we need to delve deeper to history of HTTP. I am not adding yet another story to this post but if you are interested you can read the whole story about error codes especially of Room No. 404 at this site.

Now I want to conclude this post stating the meanings behind codes that are transferred to browsers.

1XX=Informational codes

2XX=Request Success Codes

3XX=Request redirection Codes

4XX=Client Error Codes

5XX =Web Server Error Codes

Hail! How I can I forget this? If we are talking about Web and HTTP then we always have to take one name. Yeah, Tim Burner Lee who is regarded as “The Father of Internet” or what we call as web. You can visit his homepage here.

Recommended Read:

1. World Wide Web consortium

http://www.w3.org

2. RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html

3. Wikipedia

http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol

4. Room 404

http://www.room404.com/page.php?pg=homepage

5. HTTP Pipe lining

http://www.mozilla.org/projects/netlib/http/pipelining-faq.html