Coding Ninja

Your cursor is still flashing at the same point and you have been staring at your screen blankly for over ten minutes. You make any excuse to get away from programming, “I’ll go make one more coffee” you tell yourself. When you start writing code you only delete it to start over again. If you are experiencing this level of procrastination then you may have programmers block.

Writer’s block or mental block is widely accepted in most creative fields. However programmers block does not seem to be as readily accepted. While they appear superficially similar they are very different things.

Generally most people accept that sometimes you can be stuck on a hard problem that you can’t seem to solve. A programmers block is something different. It is not that you are not able to solve the problem. The problem is that you find it very difficult to muster the will to want to program or to solve the solution.

It is difficult to say what the root causes are as not everyone is impacted in the same way. However I’m picking on three causes I have heard about that could trigger a block. The first is what some call “Analysis Paralysis”, the second is loss of confidence and the third is becoming lost in the details.

Analysis paralysis happens when having to consider too many competing solutions to a given problem. All of the solutions are poor with no real winner. A mental block sets in as a result of having to pick a solution from a set of bad ones.

Failures will usually knock your confidence, once your confidence is shaken it can be very hard to motivate yourself again. This can becomes more acute when multiple failures occur one after another. Perhaps a block is a natural defence mechanism from having to face yet another failure?

The more involved and engrossed you become on a particular problem, sometimes you end up losing yourself in the small details. You are unable to see the “bigger” picture. Those small details end up using up all your energy and it can feel like your project has run aground as it stops moving forward. The lack of progress against a looming deadline puts stress and pressure until you get into a mental block.

Stuck in a programmer block.

So if you find yourself in the midst of a programmers block what can you do to try and break out of it?

I would like to say that some magical “one size fits all” solution exists, but the reality is that different things work for different people. With this in mind there is no harm in at least giving the following methods a go.

Start refactoring some old unrelated code. You need a way to break away mentally from what you are trapped inside. Refactoring old code might help “warm” you up to programming again. The main thing is to get writing code again.

Talk to someone about the problem. Sometimes we can create problems that don’t actually exist. Discussions may throw up a different perspective that you have not considered. As an alternative get someone else to program this part of the system. This may feel like a cop out but against deadlines, it is better to lose the battle then the war.

Stop programming and go do anything that is not programming altogether. This may sound counter-intuitive, but forcing your mind against a task that you are struggling with could make things worse. A mental context switch might just be the break that your brain needs.
Conclusion

Next time you find yourself in a programmers block why not give some of the above ideas a go? Anything that might improve the situation should be at least tried. Having said this, one important aspect that should be noted is that programmers block can also be an early sign of burnout.

It would be really interesting to hear about different approaches to breaking out of a mental block. Have you had programmers block and if so how have you dealt with it?

Until next Monday, “stay calm and keep programming.”

In my experience the process of finding the right candidate can be stressful. It appears that within the IT industry, the cases of failure are higher than the successes. In the absence of any standards the interview process is inconsistent and conducted using what can only be described as “IT Folklore”.

Part of the problem starts with most recruitment agencies. Agencies work in an almost mechanical way. Instead of filtering candidates intelligently they seem to filter using a dumb keyword or “buzzword” match approach.

Despite the agents, the more damaging part of the process is the interviewing itself. Technical abilities should in theory be easy to measure objectively. However in reality this is not the case as the current style of “testing” often produces inconsistent results.

The testing style that many companies use does not seem to be coherent. For some reason the focus and emphasis of many tests appear to obsessed around brain teasers and puzzles.

Although one could argue that a good surgeon is someone who has excellent “hand eye coordination” it is only one metric. It would be absurd to measure the competence of a surgeon by their video game playing skills.

Finding the right candidate

When I was searching for a candidate I wanted to avoid the current style and so decided on a different approach. The first thing I did was decide what were the objectives I was trying to achieve from an interview. Personally I think an interview has two sides, the technical and the non-technical which are equally important.

The non-technical element for me was about getting a “feel” of the personality of an individual. While it is true a short period of time is not sufficient to get the full picture about someone, I think you can at least get a decent impression about them.

Regarding the technical side I boiled it down to three essential things I wanted to find out about the candidate:

• What have they done?
• What can they do?
• Why do they do it that way?

In terms of the first objective I think asking them about their past jobs and experiences was enough to ascertain what they had done. It is hard to lie about technology you have never used because you simply will not know enough to give a thorough answer.

I derived the last two objectives by writing an exam paper. The “examination” was conducted on an offline laptop. The candidate was left alone (except for popping in at fixed times to check on progress). As for the questions on the paper I created four sections:

• Section 1: Warm up questions: basic computer science questions.
• Section 2: Open ended question: “How would solve?” type question.
• Section 3: Programming question: Create function x.
• Section 4: A set of SQL questions: write a SQL query to do x.

Once this was done picking the right candidate (for us) was simply about weighing the test score along with our impression of the personality. We found the process was painless and we believe it delivered the right candidate.
Conclusion

Programming interviews can be problematic. If it appears that you are constantly not finding the right candidate, you may want to consider looking at how you conduct your interviews. For myself this approach had the successful elements in finding the right candidate.

Until next Monday, “Live long and prosper”

I was explaining the mechanics of how a computer works to a friend, when I realised that although I knew the basic concepts, I lacked the exact details. This reminded me once again about a fantastic courseware entitled “The Elements of Computing Systems” by Noam & Shimon. If you have not yet come across this courseware I highly recommend it. In twelve steps the student builds a real computer as the quote states “from NANDs to Tetris”.

I have noticed a trend that seems to be on the rise at the moment. It feels like a new “learn to program in x weeks” startup launches every other week! Although I’m not in a position to judge the successfulness of each of these companies. I can’t help feel that a new IT bubble is forming. As a professional programmer, bubble aside this feels like the “new” VB6 fiasco.

Around 20 years ago Microsoft launched “Visual Basic Studio” and it was designed to enable “Rapid Application Development” (RAD). And in many ways it could be said that it succeeded at doing just that. It’s simple to use “drag and drop” style of programming enabled applications to be made with disgusting ease. It had in effect “lowered the barrier” to development and made it accessible to a much wider audience.

Much to the chagrin of professional developers the IT industry was flooded with what can only be described as “cowboy programmers” (in the UK a cowboy is a negative term). These cowboy developers (many without programming backgrounds) created extremely poor software. In some cases modern developers are still cleaning up that mess from a decade ago. I must emphasise that there were also competent engineers that did use VB6 to great effect (but they were in the minority).

Sadly it appears history is once again repeating itself. The selling point before was “productivity” This time round it is about “everyone should be able to code”. I fear the outcome will be the same. While the idea of teaching programming to everyone is noble, it is perhaps trying the solve the wrong set of problems.

Aristotle, A polymath hero

As part of the US military doctrine the term “Full Spectrum Dominance” or “Full Spectrum Superiority” to give its official term are defined below:

The cumulative effect of dominance in the air, land, maritime, and space domains and information environment that permits the conduct of joint operations without effective opposition or prohibitive interference.

The general concept is to “cover all bases”. I would like to extend this concept to the engineering world. In the engineering version I like to call it “Full Spectrum Engineer”. There are many discrete disciplines within engineering (electronic, mechanical, computing). In my mind a full spectrum engineer is one who has a good grasp of all of them.

Although in modern times academia and industry has followed a path of specialisation, this has not always been the case. The giants of history and the classical scholars followed a very different path. In 384 BC Aristotle who was a student of Plato was a scholar who covered many domains from poetry to physics. Aristotle and many great figures like him were all polymaths, that is they were all involved in many diverse fields.

If you think about programming as a domain it is a highly specialised field. Getting more people into programing means pushing more people towards perhaps a more specialised domain. I genuinely believe that what the world needs today are more polymaths in a sea of monomaths.

I’m not going to extol the numerous advantages of being a polymath, as I feel that there are certainly enough space for both to coexist. Having said that the balance currently seems biased towards monomaths, this is most probably as a result of modern academia.

Conclusion

The ultimate goal of engineers are to solve problems. In order to solve problems there are various tools that can be used to bring about a solution. Programming is one particular tool, however solutions need not be solved from this singular perspective. In some cases it is impossible that a single tool is sufficient to solve a particular problem. Recently a lot of focus seems to be drawn towards programming. While this is commendable I feel this is a narrow focus, I believe the focus instead should be made as wide as possible. I think Abraham Maslow described the situation of a monomath engineer the best:

“if all you have is a hammer, everything looks like a nail”

Until next Monday. keep safe and keep learning.

At the beginning of last week, an article appeared on Proggit (that has since disappeared?). entitled “The Tech Industry’s Darkest Secret: It’s All About Age”, written by Vivek Wadhwa.
Incidentally this is a nice follow on from a post I had written just a few weeks prior “Where Do You See Yourself in 10 Years Time?”.

The central point of Vivek’s article was well summarised in his introduction:

“The harsh reality is that if you are middle-aged, write computer code for a living, and earn a six-figure salary, you’re headed for the unemployment lines. Your market value declines as you age and it becomes harder and harder to get a job.” Vivek Wadhwa

The argument is also reinforced by Bureau of Labour statistics and Brown and Linden’s findings:

“Although salaries increased dramatically for engineers in their 30’s, these increases slowed after the age of 40. After 50, the mean salary fell by 17% for those with bachelors degrees and by 14% for those with masters degrees and PhDs.“

I am fully aware statistics should always be taken with a huge pinch of salt, and a link to the original analysis would have helped those more curious readers. However, except from minor differences I don’t think the data was a million miles off. Its hard to shrug off the data where the drop does indeed appear to be substantial.

And in addition to the statistics, this thought experiment does highlights the case further:

Why would any company pay a computer programmer with out-of-date skills a salary of say $150,000, when it can hire a fresh graduate — who has no skills — for around $60,000?

Vivek’s parting advice only helps solidify his prior conclusions, my translation of these points are as follows:

• “Move up the ladder” basically do something else other than development.
• Start your own business,and probably fail badly.
• Try and still hip with the kids, become a hipster and buy a Mac.
• If you want to keep coding, save your money now because you won’t be worth anything soon.

Legacy Systems, live on

Is it really that bad?

After reading, I let out a deep sigh; I couldn’t disagree outright – much of what he said sounded reasonable. Once the emotions subsided my logical side kicked in (maybe helped by another caffeine boost from my fifth coffee of the day!)

Is it really that bad? If we start with the statistics we can see that salary appears to decline with age.

The first problem, we can not infer a single metric as being the cause (in this case, age). I suspect the picture is a lot more complicated than what is presented.

Secondly, although salaries do drop which suggests “less demand”, that could also mean “less interest” from Developers.

Upon closer inspection of the thought experiment, the conclusion only holds for some circumstances. If we applied the same question to a different set of circumstances the question no longer holds true:

• An established company that needs someone with a proven track record to deliver a business critical projects.
• Legacy systems (eg COBOL) with skills and experience not widely available.

There are probably many other situations that do that also do not hold true for the thought experiment.

Conclusion

In these volatile economic times, job security is a challenge for everyone. These economic pressures also affect Developers and we are certainly not immune from them. Young Developers or “Apprentices” in other fields certainly have appeal from an economic perspective. However it must be remembered that in business cheap labour are not always the only consideration.

Learning new technology and constant learning should be a natural thing and not coerced, in that sense staying “up to date” shouldn’t be an issue.

The technology sector may be different in terms of “newness” because of the pace it moves at, however one thing has to be kept in mind: Today’s technology is tomorrow’s legacy system, and legacy systems have to be maintained long after the technology has died.

Until next time, happy coding!

Another week and during my internet travels I stumbled upon a blog post by Aditya Bhargava titled “Building a concurrent web scraper with haskell”. I’m not a Haskell programmer and my experience of it is extremely limited. Reading the post most of it read like a cryptic magic spell!

Anyway it was still an interesting read and has inspired me to try my hand at writing something similar. So I reached out and and the quickest thing to hand was Python. In Linux just fire up a terminal and drop into your favorite text editor and away you go.

The Process

It is usually a good idea to think and plan out the basics of the solution design. Our target is a web page and our end result should be all images downloaded from it to disk. The target web page contains links to the images we want to scrape. Once we have a list of images instead of downloading them one at a time, the goal will be to download them “concurrently”.

A Concurrent Web Scraper Process

.

The entire process can be broken down into the following distinct four steps:

• Get contents of page
• Parse and create a list of image links
• For each link start a new thread
• Download a single image

Now that we have a description of each step (or “function”) we can think about each function’s name and its input and output:

• “from page” url -> html text
• “all links” html text -> list of links
• “in parallel” function, list of links -> start thread
• “download image” link -> file saved to disk

You may have noticed that the output of one function is the input of another. This has been designed so that each function can be fed into the next one. Thus we can (at least in pseudo code) describe the entire program call:

in parallel ( download image, all links ( on page ( url ) ) )

Voila we are all done! Erm OK perhaps not quite, we just need to create the code for each function:

Lets create the code in the order that the functions are called. First start off with the parallel call, this function will simply take a “function” to invoke and a list of links. We can iterate through the list, and call the function each time and pass the link to the function as a parameter.

.

from threading import Thread

def in_parallel(fn, l):
       for i in l:
           Thread(target=fn, args=(i,)).start()

.

To get the html contents for a given url we can use Python’s urllib module:

import urllib

def from_page(u):
       return urllib.urlopen(u).read()

.

Let’s now create the function that downloads each image, we need to provide a filename. We could parse out the link that is passed in but being a lazy programmer I’ve decided to just create a GUID instead :)

.

from uuid import uuid4

def download_image(i):
       print "saving -> "+i
       f=open(str(uuid4())+".jpg",'wb')
       f.write(from_page(i))
       f.close()

.

Now all that is left is really the meat of the program, the task of parsing out the image links. To do this I have decided to use regex (shudder; I know I know, you can’t parse HTML with Regex). Being naughty sometimes is OK, right?

.

import re

def all_links(p):
       links = re.findall(r'href="([^"]+)"',p)
       return [links[i] for i in xrange(0,len(links)) if "http" and "jpg" in links[i]]

.

Finally now that all the functions have been created, we can call it and enjoy the images being downloaded concurrently, and what better web page than reddit’s /r/pics ?

.

in_parallel(download_image, all_links(from_page("http://www.reddit.com/r/pics")))

.

Conclusion

Programming in Python is fun because the code almost flows in the way you imagine it! Naturally this simple example is most certainly not production ready. However the basics are the same. Extending this example would include limiting the number of concurrent threads, error handling and perhaps recursively calling links on the website. Something for the reader to try out :)

The full 23 lines of source code are included below. Until next time have fun Pythoning!

.

from threading import Thread
from uuid import uuid4
import urllib
import re

def in_parallel(fn, l):
       for i in l:
           Thread(target=fn, args=(i,)).start()

def download_image(i):
       print "saving -> "+i
       f=open(str(uuid4())+".jpg",'wb')
       f.write(from_page(i))
       f.close()

def all_links(p):
       links = re.findall(r'href="([^"]+)"',p)
       return [links[i] for i in xrange(0,len(links)) if "http" and "jpg" in links[i]]

def from_page(u):
       return urllib.urlopen(u).read()

in_parallel(download_image, all_links(from_page("http://www.reddit.com/r/pics")))

There are many things that sound great in principle, and sometimes a few of those things can even work out in practice. These rare gems should be shared with others right? People like to spread the good word. In time though the idea gets jumbled with other things. In its new corrupted form things stop working “in practice”. However the old stories live on, an affirmation that it is still a great idea. A cult is born and in the presence of this cult even the thought of questioning it will unleash wrath from the gates of conformity.

Programming in one sense is the art of controlling complexity, the human brain are limited. It is very easy to take a simple task and add more complexity to it. If we are not careful we can get killed by the blast of complexity explosion. Once the complexity exceeds our capacity to comprehend it, that is when system instability are inevitable.

Debugging a problem is an attempt to understanding state behavior  Fixing a bug are catering for a system state or edge case that was not envisioned before.  It is thus not surprising the less you know about a system, the less you can predict its various states and behaviors.

Unit testing like riding with the training wheels on

.

In an effort to stop the rise of system instability, unit testing has been seen as a way to fight it. An elegant solution in principle: write code that verifies the behavior of a “unit” of code. Once a set of “unit tests” are written the process of code verification is thus automated. Code changes can be made with total confidence. Its like riding a bike with the training wheels on, you are never going to fall over.

There are a long list of arguments against unit testing, with those arguments there are counter arguments. However none of those arguments deal with the deep rooted failure of the principle itself.

What is that failure? The failure is the base assumption that the unit test can encompass ahead of time the full set of system states and edge cases. This is contradictory because the reason bugs occur are because we are not able to envision ahead of time all cases. How can we then begin to write tests for things we don’t even know exist?

Does this mean unit tests are useless? No unit tests can be used in very special cases I believe. An example of a special case would be an algorithm, in this case it makes sense because you can know what to expect and thus test against it. 

OK if unit tests can not fight the rise of system instability what then are the alternative solutions?

In my humble view I would suggest that we go back to the root, the failure to predict state and behavior  This will never be solved (bugs will thus always occur) however the more we can understand a system the rarer those cases become.

Instead of endless unit tests, start by reducing system complexity, refactor mercilessly even rebuild from the ground up when needed. This is not a perfect solution (there are no silver bullets) think more of “water resistant” than “water-proof”.

Conclusion

Unit tests are pushed in an almost cultist way. Among the cult those that do not use unit tests are seen as knuckle dragging neanderthals or unenlightened. If you want increased stability you will need to first control complexity, to do that you need to reduce it. Unit test are thus band aids trying to work with complexity instead of reducing it.

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity. (David Gelernter)

You may have come across this form of questioning most likely in an interview. Its a classic question but usually asked in terms of 5 year projection, however the concept are the same. The problem with well worn questions are that the answers mostly follow in a predictable manner. If you have never given this question any serious thought, then I suspect you would be in the majority.

So why is this question so popular among interviews anyway? The motivation for this question allows interviewers to ascertain some key information. By looking at the career aspiration of the candidate clear goals can be identified. These goals allow the company to see how well the candidate aligns with the company, further it shows how well the candidate fits the job itself.

For this reason its clear why these lines of questioning are popular. But the popularity also means that there are many “ready made” pre baked answers floating out there both online and offline. A cursory Google brings back numerous answers. Below is one template that has probably been memorized by many an anxious candidate:

In 5 years time, I see myself progressing in (the field) and in (the company), earning new skills to the benefit of (the company). I find this (job position) extremely interesting and motivating. I can see many challenges lying ahead of me, which I am eager to experience. And therefore, I am willing to invest my 5 years time learning all aspects of the job towards professional advancement.
To sum up – I want to be an expert in my (field). (source: Job Interview Site)

But let us change the context, away from the theater of interviewing. What does the real long term objectives of a programmer look like? Of course this is a vastly open ended question, generalization are thus not a good fit. Each programmer has his or her own dreams and desires, their path may lead to many different places.

Where do you want to be in the next 10 years?

Life version 1.0

During my childhood, grown ups would always ask “What do you want to be when you grow up?” ask any kid today and you may get some interesting responses. As a child I knew exactly what I wanted to be, I wanted to be an “Inventor”. I had a passion for building things, opening things up to find out how they worked. Of course no one told me that an “Inventor” as a job didn’t exist.

Fast forward past the bubble wrapped world of academia and to the serious world of professional work life. In hindsight I’d probably love to make a lot of changes but it is now a distant memory. When you are single, life can be very carefree indeed. Looking back now this is time that should be used to its fullest. When you are only responsible for yourself you can take a dive into the well of knowledge, don’t worry you will never reach the bottom. Coding at work and going back home to hack through the night hours was exciting and powered by the “buzz”.

Some people do live the bachelor life, but for rest of us the bachelorhood is soon replaced in time by family. With family comes increased responsibility, life is not as carefree as it once was. Family unlike code can not be placed on hold, family always comes first in the priority queue. The horizons of life are now vastly more expanded, you will have to juggle many things at the same time. Its a constant struggle to get this delicate balance right. I can’t speak for other programmers, but personally I hadn’t given much thought about 10 year projections. The only objective for me was being happy and to continue coding for as long as I could. But I know while admirable it is also very naive, in hindsight I know now the real value of trying to look 10 years ahead. I’m only starting to think about the next ten years, I just wish I was doing this back then.

Conclusion

If you have not yet spend some time to think about the next 10 years, then this may be a good time to do so. As for the seniors out there that have walked the path, why not pass some of that wisdom down? perhaps we could use those debug tips to optimise our life version  1.3.

That dreaded email the one you was hoping would never turn up in your inbox has now suddenly popped up. You re-read the communication just to be sure of the exact details. Although you would love to just ignore it, this is one you can not. You have written your reply for the last time, but you hesitate to hit the send button. “Let me reword that again” you think to yourself, the dilemma is do you tell the truth?

Software bugs are sadly always part of real world systems, as a twist on the original saying:

“Real systems aren’t perfect, perfect systems aren’t real”

Of course there are indeed differences in the severity of bugs from the minor, the annoying and finally the catastrophic. From the perspective of the end user the minor bugs may usually be ignored. Annoying bugs will often bring a quiet groan as some work around are used. The major bugs are completely different, these are the showstoppers.

.

Trust me I’m a Programmer

.

A showstopper does not happen often (at least it shouldn’t)  because when one does occur everyone notices, the impact can be far reaching from financial loss or even death. On 6th May 2010, a bug in the stock system caused the “Flash Crash” costing the United States $1 Trillion in financial loss. In 1985 around six people died as a result of receiving a radiation overdose (100 times the normal dose) from a Therac-25 machine, once again this was as a direct result of a software bug.

Given the gravity of the matter shouldering the sole responsibility understandably are a serious burden. Given such a heavy burden it is not surprising that most people will wish to avoid it as much as possible. The easy path are to either pass the burden to someone else or perhaps be very “economical” about the truth.

Not taking on the burden is a hack, a short term fix. It may work for a very short while, but in time as with all hacks it will undoubtedly fall apart. When it finally does fall apart the ramifications will usually be far worse than whatever the short term fix avoided.

As a professional from a doctor to a programmer, others who are dependent place a trust in those individuals. Most people understand that things sometimes goes wrong, humans are not perfect. Most mistakes are forgiveable even if they cause anger or suffering. However deliberate deceit breaks that bond of trust and once broken it cannot be undone.

Take a deep breath

Owning up to your mistake takes courage, admitting you failed and failed badly never comes easy. If you have to walk this path, the first thing would be to acknowledge your failing and apologise for it without any hint of excuse. Make an effort to talk directly in person if failing that then over the phone. Email simply does not do this communication justice in many cases. Explaining the cause of the problem and then offering a solution will help you move forward from your mistake.

Conclusion

As programmers and system builders we are in a place of trust. Trust and reputation are something that usually takes a long time to build. But both these are very quickly destroyed. I hope you never find yourself in such a horrible situation. If you ever find yourself in such a predicament I hope your reputation and trustworthiness  gives you the courage to want to save it.

Another heated and high pressure meeting and this time it is to “discuss” how best to “bring back on track” the head line project, the deadline which has already long since past. Sounds all too familiar? I would like to say that late projects can happen in any line of work. While this is true, it appears software development seems all too prone to it.

How did we end up here? We need to backtrack to the start of the dream. It all usually starts full of energy. A new shiny idea and this time we promise ourselves that we will avoid the mistakes we made in the last one. This time we tell ourselves it will be done “properly” and no more shortcuts or hacks. Sometimes this dream for a brief while does seem to go right, the design makes sense, everyone is optimistic and the buzz is good. Then it begins the descent into the nightmare, as the first cracks start to appear.

That easy part of the system now consumes all your time. A slight oversight has meant the initial set of simple assumptions no longer holds. The wrong assumptions has cascaded the design into a dead end. Hacks are now needed to fix it. But there is still hope, with enough weekend coding and late nights we can bring it “back on track”(tm).

The milestone presentation demo are shown, and everyone is optimistic as the demo has gone well. The others are not aware of the hacks and late nights used to make it all work. Then the “small requests” come in. They usually start with “How hard would it be?”, or “This should be really easy!” and the classic “It would be amazing if we could..”. In conversation these small additions not only sound “easy” but doable. Of course you don’t say no, the downward spiral has already begun.

Now you and your team are back in the real world, looking over the new additions. Suddenly after a closer look it appears the “easy feature” is not quite as simple as it first sounded. But it is too late you have already agreed with management the new changes.

“Ping!” you have a new email in your inbox, great more fuel for this runaway train. Sales have spoken to end customers. Sales spoke about the “easy” additions and the customers wanted a few more “easier” requests of their own. Sales have agreed because it sounded even easier than their own easy requests.

Developers, Just Say No

Stop, just stop

During the early 80’s and 90’s a popular advertising campaign of “Just Say No”  was used to try and stop or stem drug use by children. Whatever your memory of that campaign the message is a powerful one. In much the same vein we might do well to take heed of this concept.

I am not suggesting that every change are turned down of course. Personally I would draw the line any-time coding development would be required. Things like GUI or front end changes which would be minor should be exempt.

All requests should be given due time to be fully considered before accepting it. Mentally the default to new features should be “just say no”. It is likely this response may not be seen positively, this should be handled with delicate diplomacy. At the start of the project if a process of “Request for Change” (RFC) is not in place it should be considered. Any new late features should also go through this process. With this process it is easier to say “no”. Because a metric can be applied, everyone is clear of the time cost of a late additional feature. The responsibility are then placed upon stakeholders to choose either to extend the deadline or make time by dropping a different feature.

Conclusion

There are a myriad of different reasons why software projects fail to complete on time. The difficulty of estimating development time is only compounded with developers steam rolled by project creep. Knowing ahead of time that additional features may be requested should be at the back of a developers mind. A new mantra of “just say no” would at least stop developers from saying yes by default. Running around with a gun is dangerous enough, perhaps if we put the safety on we might just stop from shooting ourselves in the leg.

Last Weeks Challenge  ASCII Clock winner is Goran Milovanovic! Congratulations Goran, the 3d animation was interesting and different. The winning solution can be seen live: http://jsfiddle.net/zHyfm/.

Challenge No 2 (Hangman)

Recreate the traditional “hangman” game. Pick a random word (can use a dictionary, or use a small hard coded list).  Then allow 12 mistakes only, each time drawing a part of the hangman.

Classical Hangman Game

Submissions:

Please use jsfiddle.net and send in your link to your solution in the comments below . Closing date will be Tuesday at 5.00 PM (26 March 2013 GMT). The winner will be announced on Wednesday 9.00 AM (27 March 2013 GMT). Please include your name or nick name.

Happy hacking!