Monday, 21 December 2009

Optimism is Power


I've been working in Darwin in the north of Australia for three weeks now. It's where I grew up but that only means that I knew it as a kid. Who I am as an adult formed by living in Canberra and Sydney and travelling the world.

Yes, I'm an eternal optimist. It annoys the hell out of cynics, pessimists and misanthropes but I'm OK with that. Me being OK with that also annoys them but luckily for me, I am too positive to be swayed by their black-hatting.

Why do you care about my glass-half-full view of the world? I'll tell you why...

Positivity is Power.

I don't want to sound like Tony Robbins because he is a bit of a knob actually but I do want to get through to negative thinkers. In Darwin, I seem to meet one positive person each week out of the 20+ new people I meet. That's 5% and based purely on my small sample size and sloppy counting methods.

Sydney wasn't like this, was it? I ran in to a lot more positive can-do people. After voicing this observation to a Sydney friend, he suggested that this could be because of the kind of people I was meeting in Sydney anyway. People in the circles I ran in were making the most out of life. They changed their lives if they needed changing and looked for opportunities constantly. It was and still is an energetic crowd with drive. Everyone wanted to change the world. We often joked that we would stop getting out of bed if we no longer believed that. These thoughts push you to progress and succeed. These people push you to progress and succeed.

It has been tweeted a lot lately that you become what the people closest to you believe that you are. You are made in to what they expect from you. That is so true that it terrifies me. What if I don't find that crowd of over-achievers here in Darwin? Will I ever do anything more with my life?

Then I break in to hysterical laughter and realise where I really got my can-do attitude and ability to see the silver lining on every cloud. It was through trying, failing, trying again and doing brilliantly. It was from what I was taught from a young age by my parents who said "you can do anything you set your mind to".

How does this apply to work? Good question and I'm glad you asked. It applies like this...

Belief

Belief releases you from the negative thoughts that say you shouldn't bother because it's not achieveable anyway. It gives you options. The option to do anything you choose to achieve.

Purpose

Purpose is making a choice from the options and deciding that's what you will aim for. Often people have dozens of great ideas but they do nothing with them. One average idea achieved, is better than 10 brilliant ideas that are filed in the might-have-been pile.

Drive

Once you have a purpose, you can realise it. In my career at this time in my life, it means working in Darwin and improving the software development environments I participate in. That will be onsite with my clients; in the user groups I start and join; and in my own personal projects. The fact that I have done it before in the other cities I've lived in, means that I can do it here. It's not about who rocks up to join in. It's about what I want to build and if I build it, they will come.


So, my point? Get out there and do something. Anything. You really can do anything. Build better software. Make sure the work you do is something you are proud of. Share your knowledge online and in the workplace. Talk to people about what excites you about this industry.

Change the world or don't even bother getting out of bed in the morning.

Thursday, 17 December 2009

Security through Obscurity


In IT Security, the term security through obscurity describes the act of designing a system or application to hide functionality in the hope that people won't stumble across access to the secret functionality. People argue that Defense in Depth tactics justify leaving functionality unsecured by enrcyption, access control or other means. The thing is that a lot of the time, they are only obscuring it and not restricting the path to it.

A recent example of this was when I entered an organisation which restricted access to their cmd prompt and the machine's C:\ drive on their Windows desktops, via settings in their SOE.

I wanted access to run a few administrative tools which were not available in the typical menu. There was no Start -> Run... option available. We weren't allowed to use it.

At first I was disappointed and then I wondered how they had restricted access to it. I thought for a while then created a text file on the desktop named cmd.bat, containing the single line cmd. Double clicking on that brought up the command prompt and access to anything I wanted. I didn't run any of the tools I wanted and quickly deleted the batch script on realising the ease at which this hole could be exploited.

Even access to the C:\ drive would not have been a challenge. A batch file with the command >explorer c:\ would be enough to start the Windows Explorer with it pointing to the restricted drive.

This is not security.

I am responsible enough to not wreak havoc and break the rules. Hopefully, others are too.

Monday, 9 November 2009

Eternity with stops on the way


Recently, my sister asked "Mana, how long should it take to get rid of all the bugs in new software?"

That's a broad question but certainly a fair one for a user to ask. I had to ask her to elaborate so that I could perhaps explain the reason why the new software she uses every day at work is not working as expected.

In short, the new major version of the software she has been using for years has been installed on her work computers. They still have access to the old one for reporting purposes but can not write any data to the old system. The new system provides a bunch of basic features from the old system but definitely not all of them.

When she's asked the software provider about the missing features, she has been informed that they are on their way but were not high enough priority to have gone in to the initial release of the new system. There are other features that do exist but do not work in the way they once did. The explanation for this is that there are bugs and the users are expected to test the software for the company and let them know what is wrong so they can fix it.

That was in July, this year. Now it is October 2009 and my sister and her colleagues are learning to use yet another new system because the earlier new one was so bad that the company who developed it went out of business. Unfortunately, Government dictates which applications meet certain criteria for use in this industry and the users have little choice about what is thrust upon them. The only real choice they have is to throw up their hands and say "we can't do that anymore but apparently it's coming".

There are so many things that concern me with this scenario, least of which is that this is not a rare occurrence. The other issues I see here that must be addressed can be represented by the following questions? Questions that I will answer here but that I would appreciate your input in to.


Who decides the priority of features in a product, to be redeveloped?

If you answer this question literally, the person who usually decides is the product owner or project manager. If you really think about what this means then you have to ask how they get their information in order to make that call. What data do they use to arrive at the conclusion that one feature is more important than another?

In the majority of the cases I have seen, people make the decision based on years of experience working in the vertical concerned or working administering the previous or current software that the new application or feature is replacing.

An alternative is to do user testing and see what they say is important. Measuring use of current applications and workflows can give information that is useful to deciding what functionality the users can not live without.

In the case I discussed above, it does not appear that all users were represented in the decision making process if one existed involving users at all. Instead, the group represented by my sister and her colleagues ended up with a new and improved version of the software that did not do those most important things that were involved in their daily routine. That functionality was gone and was promised in a future release.

I was asked about: how you decide something is left out? Is it simply because it was difficult to implement? It's great to see end-users trying to understand why but sad to see them surrender to the fact that nothing is in their control. They pay for it and they use it. Would you accept this from any other industry?!


Who is supposed to test your software and when should that happen?


Then I was asked: when the new software should be bug free or at least not falling over at the drop of a hat?

When the software company was asked what testing they did, they answered with the often heard line of letting the users test it when it was released. They apparently talked about reacting fast and fixing the problems, yet their releases were quarterly. This software was served over the Internet so it was a centralised update but they still released quarterly.

Of course, their release cycles can be due to a lot of factors that are very valid. What I can not accept is that it is the users responsibility to test the application after it is in production. How can this possibly be acceptable to anyone involved? I ask the question again, would you accept this from a car or pharmaceutical company?

There will always be bugs that go out in to production but when the software stops the people using it from doing their job and they are told to test it, report bugs and wait three months for a fix then you can't be surprised the company would go out of business.


What does the user consider a bug?


With access to a bunch of people who consume software at the end of the cycle, I had to ask what they considered a bug. Instead of finding the level of intolerance familiar to software engineers from product owners who demand no failure at all, I found that these users expected far less than that.

In fact, they thought the software not working at all was annoying but apparently understandable because computing is complicated. They understood new systems have issues to be ironed out. They could tolerate that for a while. What they couldn't fathom was why they had no view of their old data; functions that were called the same thing but did something different; and buttons that you clicked that did nothing at all.

The ultimate thing they called a bug was when the system did something completely wrong while promising to do something else. Especially when that thing was related to money or Government concessions. Things that you would think were legally binding. Processes that were tried and true and had worked in previous software.

What I drew from this line of inquiry is that users are much more understanding of our profession than I expect them to be. Much more understanding than I would ever be in the same situation. Users need to realise that they don't have to put up with the bad output from software companies and that if they don't like it, they can chose not to use it.

Maybe we need money back guarantees.


Should governments dictate key features of applications shared across multiple industries?

This is an interesting point and one that I have discussed almost continuously for over a decade, since I have spent the majority of time on the other side of the fence. My most relevant experience in this area was working for a Government agency that collected scientific test results from food imported in to Australia. Labs that did this testing across the country were required to implement applications that collated food sample test results and submit it electronically to the agency. At that point, the agency would approve or fail the importation of the food. Doing this electronically would speed up the process and stop food from sitting around for so long before being granted admission to the Australian food market. Brilliant idea, right?

In theory yes, but in practice this meant asking a lab that employed no IT people to have a system created for them to suck data out of their labs systems and deliver to a Government agency. In practice that sounded simple but it was a huge program of work that saw the bigger labs just come in on time with implementations. We did everything we could to aid for simplicity for the lowest common denominator and to support development in to using our interfaces and messaging systems.

From our point of view, it was a new application that spoke to the agencies back-end legacy application. It took 1.5 engineers, 1 business analyst, 1 project manager and 3 business people 3 months to get the receiving system designed and off the ground. We surrounded it with a swamp of automated unit tests and integrated with our demonstration systems. It was a breeze.

We then spent 5 months helping other developers integrate with us. We made the rules and decided everything up front and then thrust the specs upon them. The level of expertise from the developers involved was mostly sub-standard in the small labs. It was not the dream that we had promised it would be. Myself and the other half an engineer knew this was coming and when the integration hell arrived, we did what we could to help including writing code in 4+ other languages other than our own to help companies comply.

Now imagine the situation for my sister and the end-users who have that new system thrust upon them. Another layer of abstraction away from the user. Demands from Government implemented and carved in stone and then handed to software vendors who struggle to deliver on time and budget. Yes, it costs them money just to deal with the Government and to build to changing conditions and rules. It's difficult but it's their job. What is horrible is watching the person sitting at their machine with the end product asking themselves how this is anywhere near the same system.

Yes, Governments must legislate and ask for compliance but they should also do something to ensure the final product meets some kind of standard. If not then the market will ensure the outcome and it won't be in the favour of the software vendor.


Is this how software providers should treat customers?

There is a huge divide between the people who support and sell software and the people who build it. I've argued for years that production support teaches you invaluable skills. Software engineers should go out and face the scorn and hopefully applause that their software brings. Their is no better way to learn to write software that will be nice to support and maintain than to go out and feel the pain of it living.

If you have not worked on living and breathing software then you are not a good developer. You don't know the baby you created. You live in neglect every day.

Sales people, support staff and whoever else pours water on the fires can't make it better but the engineers can create good software. It is possible. People do it every single day.


How long does it take to get rid of all the bugs in software?


This is the same as asking how long a piece of string is. Like I said, software is a living thing. There will always be glitches/bugs/issues/defects/whatever and we will always be adding and fixing features and functionality. That's how it's life goes and that's how our life goes.

We have a responsibility not to send out software that we don't trust is good enough for sale or use. That can be helped through testing, design for usability, user acceptance testing and lots of good requirements gathering at the beginning and throughout the process. All of this should happen throughout the process.

People like my sister (or someone who represents her and cares) should be seeing and using working versions of the software as it is created and grows. That way the end product is not a surprise and a tragedy.

Don't just sit there. Tell me how you stop your company from being thrown out of the market each day. What can others do to make the software world a better place for our users?

Friday, 6 November 2009

Think outside the ruling majority


I have changed town, jobs, houses and all sorts of stuff in the last few weeks. It's one of those seachange-slow-your-life-the-hell-down type of things. Moving to a small Australian city has highlighted a few things I was ignoring or missing or simply ignorant of.

You'll see me get on my soap box and talk about diversity, equality and treating people the way you would like to be treated. I pride myself on being a member of many minorities but was blind to see that being in Australia's biggest city and home of all the cool stuff in IT in the southern hemisphere, that I was forgetting the other 2/3rds of the country existed.

Melbourne people can pipe up and argue their relevance but the cool stuff in this country happens in Sydney. That's where the finance sector lives. Publishing is based there. Entertainment, Tourism and everything but sport is bigger in NSW. The majority of the population lives there.

It is easy then to forget that what's left of Australia outside of the big east coast cities is not a backward dustbowl but a place people prefer to live at a different pace. This doesn't necessarily mean different priorities though. Australians are Australians, pretty much wherever they land. Ask anyone in London that.

So as I settle down and begin to work in this particular dustbowl, I'm eagar to be open-minded and see what the standard of my profession is here. I want to find people I can learn from and share with. People who want to learn and use their minds, in a way that I share.

Rather than assume everyone is hopeless and this is why they live here, it will be better to find and nurture talent and develop a sense of IT community here. That's what I'm going to do. I'm going to help start things moving... but still moving only at a dustbowl pace.

PS If you are in Darwin, contact me.

Thursday, 8 October 2009

Is "Tech Lead" the new "Architect"?


Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having an A in the acronym was the bomb - EA (Enterprise Architect); IA (Information Architect); and any other term with the "A" word at the end of it.

With this title came a lot of responsibility for whether the project succeeded or failed. Accepting that meant that you couldn't let others fail and take you with them. That's when in some circumstances, the iron fist came out and the right to veto a change became part of the job description. Of course, that made sense when it was your head on the chopping board.

It is commonly argued regularly that the decision making in a group should be centralised in order to make conflict resolution easier to solve. I agree with the idea that there must be away to settle disagreements between members of a team if they come to an impasse. There are many ways to do this but the fastest and most decisive is for one person to have the final word. The other way I have seen work regularly is to have the team decide through majority opinion or vote. When the group decides something for all then that is usually accepted by all.

The group decision method can go wrong if the most popular person and strongest speaker dominates. The one man final decision can also go wrong if... well, if they aren't good enough to make that call.

It is a rare project that I have worked on that is lead by one person with all the technical and high-level knowledge to make all decisions well. I have however often seen teams with a mix of people who can answer all the questions needed and pick the best option. Add to that team an external arbitrator (like a project manager) who can facilitate the decision making process and you have a much more successfully functioning team.

Software engineers are more creative lateral thinkers than they are credited with. Although the other disciplines of engineering are extremely logical, spend some time herding cats and you'll see that devs are more craftswomen (and craftsmen) than they are plodders through an already defined structured process.

With this creativity in mind, software engineers do not want to be mere typists for their architect or technical lead. They need to be allowed to create and use their skills to move the project forward. If you don't allow this, you lose all that is good about working with them. Unfortunately, this is too often the case with the tech leads I have seen since starting my career. Most of us find ways to work with these little dictators and sometimes we simply get fed up and move on to another team, another project or even another job.

Is today's title of "Tech Lead" the new, more acceptable synonym for what is now the dirty word "Architect"?

Yes, it is. Teams build software. Good tech leads and architects will guide their team, support them and remove technical blockers from their path. They won't use the word veto or force their ideas on to their intelligent peers. If they don't see their team as their peers then that's another problem altogether.

Come on tech leads, keep your title but use your powers for good and not evil.

Wednesday, 7 October 2009

Give me an alternative


I've been blogging about some "simple" stuff lately and there is a reason for that. It seems that things that those of us who have worked building big web apps for a long time, take for granted. There are certain ways to do things... etiquette even. As long as I see these things missing when I interact with the web world, they will appear here. If this is too condescending then "think you have but slumber'd here while these visions did appear".

On opening an email from my favourite pet food delivery place Star Pets in my gmail, I noticed before I hit the load all images button that the images all had place holders of a hyperlink with the text alt. This turned out to have the HTML: <img border="0" alt="alt"/>

Now, HTML elements have the alt attribute which is an alternative text attribute that is on the element in order to:
  • allow an image, link or other artifact to have a meaningful placeholder while it loads or if it fails to load;
  • allow search engine web crawlers to easily understand and index your site; and
  • assist accessibility browsers like JAWS.
As a developer, you are helping make your site easier to understand and use by people and machines. That has to be a good thing and it's not much effort. Developers, analysts and testers can all contribute to adding meaning to your pages with alt attributes so start doing it now.

It's etiquette.

Thursday, 1 October 2009

And another one bites the dust


Going through my lower priority email in the middle of the night, I decided to read the one titled "Changing times at Trading Post" from the Trading Post. Thinking that it would be something about a new Twitter account or iPhone application, I was surprised (but not so surprised) to see the actual news. Rather than re-tell it, here is a quote from the email:

"As a result of this change in customer preferences, Trading Post will become an exclusively online and mobile trading place from November with the last print publications on sale from 29 October 2009."

In Australia, the Trading Post is an institution. It's the regional collective classifieds for your area. You pick one up and spend a morning on a weekend reading it. You call people about stuff you don't really need but seem like a bargain and deal with the disappointment or glee that comes from finding whether it's still available.

I recently put my car up for sale on their website, on ebay and on carsales.com.au. Although I sold the car through carsales.com.au, I got the most inquiries from the Trading Post. Since I chose to display the advertisement in their print issue as well as on the website, people were contacting me for quite a while after the car was sold.

This is another example of a popular publication leaving the world of paper and moving to a purely virtual one. I feel like there should be some sorrow floating around in my sentimental mind somewhere but if I'm honest with myself then it makes no difference to me. I don't feel saddened by it. In fact, it feels right.

We trade online all the time now. Maybe just as they named their classifieds-only paper after an old fashioned "retail store serving a sparsely populated region", it's evolved in to the next type of place to sell and buy... on this Internet thing.

Friday, 11 September 2009

Resizing a new browser window


Developers have to stop believing that their web application is the centre of universe.

These days, I easily have ten tabs open in Firefox (or my browser of choice at that moment). Nothing infuriates me more than clicking a link on a website and having another window launch... except if the new window is resized automatically.

That behaviour resizes the whole window and all tabs in it. When the offending tabs is closed, a manual maximisation is required. That annoys the hell out of me.

Optus does this on their Pay a bill (click to be annoyed) link.

Stop it!

Friday, 28 August 2009

Wednesday, 8 July 2009

How to complain about SMS or MMS spam to your mobile phone

In Australia, it is a serious offense to spam a mobile phone via SMS or MMS without the user opting in. If this happens to you, make a complaint to the Australian Government through ACMA.

I shall now go and complain about Optus.

Tuesday, 7 July 2009

You want to manage me?



Having heard yet another IT graduate tell me that they do not want to waste their entire career being a developer, business analyst or tester and instead prefer to start in project management, I've had to hold in the scream and write this post instead.

A good friend of mine was recently tutoring at one of the Sydney universities and mentioned to me her disbelief at the fact that the majority of the students she had contact with had sights on project management as an entry level role after finishing study. In their project teams, there were hardly any indians but lots of chiefs.

In my career, I have managed to work with a vast array of project managers. The quality has varied, as it does in any professional role. The one thing I have noticed is that the good project managers are worth their weight in saffron. A good project manager doesn't use Microsoft Project to plot the predicted progress of a project. They manage time, money, risk and people in often Machiavellian environments with a finesse that is not learnt in a book or during a degree.

At ThoughtWorks, I am lucky to work with only the best project managers there are. One is known as the "Ego Wrangler" because she can get peak performance from a team of alphas who if left to their own devices would degrade in to a Tank Girl style society. Handling smart individuals with great enthusiasm for what they do in the conservative business world takes a lot of experience with people and situations. It takes experience in risk management and that doesn't mean avoiding risk. It means knowing when to hold 'em, knowing when to fold 'em, knowing when to walk away and knowing when to run. There is the skill of listening and hearing more than what is said in meetings, over coffee, on the lift and during staff tantrums.

If I was to sum it up, project management takes years of experience working on many projects. You have to fail and succeed and learn from yours and the mistakes of others. The ones I know have my trust, dedication and respect. Unfortunately, that is just not something you give to someone straight out of university no matter how brilliant they will one day be.

Tuesday, 21 April 2009

Using an iPhone differently


I'm working in Melbourne this week on part of my project that is located here. The rest of my team is in Sydney. Each morning, I call in to the stand-up and they put me on speaker phone. Usually the person calling in speaks first and then spends the rest of the time trying to listen to what is going on. This is a big stand up with 15-20 people each day. Some people mumble, some shout but mostly it's all noise.

Today, the Iteration Manager decided to get me to call his iPhone. He turned on the speaker and in turn each person passed the phone around when they took their turn to speak. Not only was it a communication device but also a token.

It was effective and creative. Kudos goes to Zaynab for a brilliant idea that now makes stand-up relevant and audible to those of us in Mexico :)

Wednesday, 1 April 2009

The Whole Nine Yards


A common question I get from people new (and not so new) to our industry is "do I have to do all that extra stuff after work?"

In the past, I have said that it's ok to learn on the job only, if that is what you prefer. I've only now realised that I have been lying to them. I was telling them what they wanted to hear and then went and did the opposite.

The real answer to that question should be a big resounding YES!

Science and technology are areas that are constantly changing. To work anywhere near the middle to the top of the game then you have to be writing code at home; reading books and blogs; and contributing to the community. Yes, not just one of those but all three. If you can do more than that then you should.

What do these three major areas involve and why should you do it?

Writing code at home

Every programmer/software engineer/developer or whatever you call yourself, should be taking time outside of working hours to write some code. Start your own project and build something from beginning to end. Get a new idea or rebuild something you'd like to understand. It does not have to be a huge web application sitting on a complex stack and hosted in a cloud. It can be a script, a tool to help you improve something in your job or life or just an algorithm. It is easier to find an idea and build something rather than just start writing code. Like work, you need a purpose.

Learn a different language. Learn a different technology. Learn more about what you already know. Become a better coder by spending more time doing it. It's like painting and public speaking and lifting weights, the more time to spend doing it the better you will get at it. Especially if you already have the base.


Reading books and blogs

The best people I've ever worked with constantly read everything they can about what they work in and what they want to work in. This goes from technical books and blogs to books about learning and working with people. We all have dozens of feed subscriptions in our readers and are constantly trying to keep the number of unread articles down to a manageable level.

If you aren't sure where to start then ask what your friends read. Follow people on twitter who work in an area you are interested in and who share links. Find an author you like and read everything they write. Find a publisher of books and read stuff they publish.

Start reading now. You are already falling behind.


Contributing to the community

This is a controversial one and something I regularly fought with my recent room mate about. I feel it is your responsibility to learn and share and share and learn.

Contributing to the community can happen by going to a user group that shares your interests where you can speak and listen to your peers. Blogging what you have worked out during the day or something you couldn't find on your last google but solved yourself is another way. Setting up a site where you can share what you have written and show how it is used is also a very good idea although that is a bigger commitment that can be avoided for now with a simlple blog.

Tweeting is also important as a way to propogate information about what you or others have written. Share what you read through Twitter, your reader, your blog or other social networking sites.

Once you start it will become a habit.


No matter what people tell you, get out there and do more. Learning only at work is not good enough. It is not about running to keep up. It's about learning for life and keeping your skills fresh and valuable.

Wednesday, 11 March 2009

2009 Veuve Clicquot Business Woman Award


The winner of the 2009 Veuve Clicquot Business Woman is "Mandy Foley-Quin Chief Executive Officer, Stedmans Hospitality - Mandy Foley-Quin is the CEO of Stedmans Hospitality, a leading hospitality and staffing agency which she helped found in 1986 and now owns. The business was built around a unique idea, a one-stop shop assuming all responsibility for staff, superannuation and payroll for hospitality personnel on behalf of its clients. It revolutionized the hospitality industry and is now the model for many other similar businesses. Stedmans employs over 1,500 casuals annually, and Mandy is passionate about training young people. Her leadership has taken Stedmans offshore; Mandy and her team have worked with the Olympic Games in Sydney, Athens, Torino and Beijing. The business continues to evolve in new directions with a division set up to service the payroll needs of the film and television industry and the recent establishment of a theatrical management agency."

It's sad that the only place I could find this was in the Wentworth Courier. She's not a geek but I like anything that celebrates awesome women.

I'm just posting a link, don't shoot me for it

A Culture of (Potential) Assholes: Sexual Harassment in IT

Sunday, 15 February 2009

✄ Cute ♧ Symbols ☻ On ☂ Your ❤ Mac ✿

Someone asked me yesterday how to get cute little symbols in their tweets. This applies everywhere and not just on twitter.

There are many sites that will give you a bunch so you can copy them. That's an easy and quick way to find them.

If you have a Mac, this is the best way to find them...

1. Go to your System Preferences and select International


2. Under the Input Menu tab, turn the Character Palette on


3. An Australian flag (for us Aussies) will appear on the right-hand side of the menu bar. Under that is the option to Show Character Palette containing all the possible symbols


4. You can insert from the Character Palette in to any text box or document. Now go and annoy everyone to death with pictures instead of words

Wednesday, 21 January 2009

You can't make everyone happy, so don't try too hard


My personality type according to Myers Briggs, sees life as a series of constant battles. In the past that was the case. With age and a pinch of wisdom, that is no longer the trend.

Since this is my professional blog, I'd like to discuss the idea in the context of the workplace and your place in your organisation.

First thing, no one respects a yes man. That is a rule. Remember it.

Having an opinion is always good. You don't always have to voice it all the time but having one is essential. Shutting up is a skill. Learn it.

So how do you balance the need to speak out and at the right time close the gate between the your brain and your mouth?

I'm an extrovert and this is something I've constantly struggled with. Even after ten years of practice, there is no easy answer. I do however have a good handle on being myself and not spending too much time pleasing everyone. There is the saying that "you can not please all of the people, all of the time" and this is true but that doesn't mean you should quit and sit passively by, pretending this is not happening.

Here is how I think you can do this...

Count to Ten

Take your time to form your own opinions. Listen to others who you respect. Think about what you respect and like about their ethos and adopt those things as your own with your flavour. Through discussion, reading and contemplation, form your opinion about things conceptually before being in that actual situation. If a whole complex situation is too much then work with parts of situations.

Don't jump up and voice an opinion on something to the room if you have not thought through what is about to come out of your mouth.


Admit you are wrong, if you are

Often people voice an opinion and stick to it purely out of pride. If you do get it wrong then learn to admit you are wrong. There is nothing wrong with changing your opinion and telling people, if what you think now is different and improved. People will respect you if you are humble enough to admit you a wrong. Don't be too humble though.


Shut Up Already


When you have said your piece and articulated what you think then stop.

Do not make the mistake of saying something over and over again with the assumption that they aren't agreeing because they simply don't understand. Sometimes, people just don't agree with you, for whatever reason. Say what you have to say and then stop saying it.

Give the person you are talking to, time to digest what you have expressed.


Don't try to please only your Managers

One thing I have seen of late is people who state an opinion just to show their bosses that they agree. Managers are not idiots. Ok, some are but if they aren't then they see right through you. If your opinion is an exact parrot of your superiors then all that you will gain is a Mr Burns and not the respect you may crave.

Pleasing only those above you also wins you no friends. I've worked in environments where the rule was to "kiss up and kick down". There is only so far you can go with that war cry. Remember to consider how what you say will filter the views of those around you. All people matter. Not just the ones who decide your pay rise.


If you follow those four rules, you will find that you will be fine. Interpret them how you will but find your voice. Your own voice. Learn when to use and when not to.

Sunday, 18 January 2009

Disabling Enter Causing Submit with jQuery


Recently I was asked to disable the submit event being triggered when the enter key is hit in a textbox input. This is for an ASP.NET MVC application. That means that including this in the site.master will allow identical behaviour across the entire web application.

When you hit enter, the focus will move to the next textbox.

There is also browser sensing code since Firefox needs a different event bound.


jQuery(document).ready(function($) {
   textboxes = $("input:text");

   if ($.browser.mozilla) {
      $(textboxes).keypress(checkForEnter);
   } else {
      $(textboxes).keydown(checkForEnter);
   }

   function checkForEnter(event) {
      if (event.keyCode == 13) {
         currentTextboxNumber = textboxes.index(this);

         if (textboxes[currentTextboxNumber + 1] != null) {
           nextTextbox = textboxes[currentTextboxNumber + 1];
           nextTextbox.select();
      }

         event.preventDefault();
         return false;
      }
   }
});

Friday, 16 January 2009

Rabbit Hole Day


On Lewis Carrol's birthday, change your blogging style for a day.

"January 27th is the birthday of Lewis Carrol, author of ALICE'S ADVENTURES IN WONDERLAND. Alice fell down a rabbit hole into a place where everything had changed and none of the rules could be counted on to apply anymore. I say, let's do the same: January 27th, 2005 should be the First Annual LiveJournal Rabbit Hole Day. When you post on that Thursday, instead of the normal daily life and work and news and politics, write about the strange new world you have found yourself in for the day, with its strange new life and work and news and politics. Are your pets talking back at you now? Has your child suddenly grown to full adulthood? Does everyone at work think you're someone else now? Did Bush step down from the White House to become a pro-circuit tap-dancer? Did Zoroastrian missionaries show up on your doorstep with literature in 3-D? Have you been placed under house arrest by bizarre insectoid women wielding clubs made of lunchmeat?"

Sunday, 11 January 2009

TDD Objective-C : Testing a Cocoa Framework Project

My intention is to write an iPhone application that does something simple, just so I can learn how they are designed, built, tested and deployed. The first step is to design the core functionality that the application will use. For that, I am creating a Cocoa Framework, which is a class library. This project will be test driven.

This describes how I created a Cocoa Framework project and the accompanying unit tests.

Operating System: Mac OSX 10.5.6
IDE: Xcode 3.1.2
Language: Objective-C


Creating a Cocoa Framework Project and Test Target

1. Start Xcode;
2. Go to File -> New Project... and create a new Cocoa Framework project named MyApp;
3. In this MyApp project under Targets, Add -> New Target... of the type Cocoa Unit Test Bundle called MyAppTests.

Making Your Target Dependent on the Main Executable

"When you configure your test target, you need to decide how you want that target to behave. The unit test bundles that come with Xcode can be integrated with your executable in one of two ways. One technique is to configure your test target as a separate entity that you build and run independent of your main executable. The other is to add dependencies to your target that automatically build your executable and run the tests each time you build." -- Xcode Help

I've chosen to run the tests every time I build the framework project, so I followed the steps on this Xcode Help page: To make your test target dependent on your framework project.

Here is a summary of how to make a Cocoa Unit Test Target dependent on your Cocoa Framework by establishing the dependency in your Xcode project:

1. Select your MyAppTests target;

2. Open an inspector for the target;

3. Select the General tab;

4. Add a dependency to the test target by clicking the + button and selecting the framework target MyApp from the list;

5. Select your Unit Test Bundle target;

6. Open an inspector for the target. To get an inspector on a project, just control-click on the test target and choose Get Info. The resulting window is referred to as an inspector. Typing Command-I does the same thing;

7. Set Build -> Linking ->Bundle Loader to $(BUILT_PRODUCTS_DIR)/MyApp.framework/MyApp;


Create a Test Class and a Failing Test

1. Control-click on the MyAppTests target and choose Add -> New File...;

2. Create a new Objective-C Test Case Class and name it MyAppFunctionalityTests. Two files will be created - MyAppFunctionalityTests.h (the declaration) and MyAppFunctionalityTests.m (the definition);

3. In MyAppFunctionalityTests.m, add a test method like this:


//
// MyAppFunctionalityTests .m
// MyApp
//
// Created by Damana Madden on 10/01/09.
// Copyright 2009 __MyCompanyName__. All rights reserved.
//

#import "
MyAppFunctionalityTests.h"


@implementation
MyAppFunctionalityTests

- (void) testThatThisIsTrueForThisCase
{
STAssertTrue(false, @"oops it didn't work.");
}
@end

4. To run the test, build the MyAppTests target. You will see this test fail.

Important: All tests must be prefixed with the word 'test' or they will not be picked up and run.

Thursday, 8 January 2009

You should blog on Ada Lovelace Day


Join a bunch of us in pledging to write a blog post on Ada Lovelace Day about a woman in technology who you admire. It's happening on the 24th of March, 2009. You can even follow the goings-on through Twitter by following @FindingAda.

Acknowledge Me

Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...