App Development: Overcoming Writers Block

Writers block - the curse of no longer being able to produce creative content. It's affected writers for years, but is also a very common problem for app developers. When it comes to app development, what can we do about it?

The causes for app writers block are mostly similar to traditional writers block, for example:

• Running out of inspiration
• Illness (physical or mental)
• Financial pressures
• Sense of failure (see the depressing side of app development)

Since these are already known problems traditional strategies for overcoming them can also be applied.

• Cut off the Internet! Is procrastination your problem - too many notifications or fun things to look at elsewhere? It's amazing how productive you can be if you turn off the internet for 30 minutes - a kick start is all you need. 
• Exercise. You may not be doing any app development because you feel lethargic - exercise can help this and make you feel more alert. 
• Brainstorm ideas. Get a bit of paper, and write down mind maps or random ideas you have. 
• Change your location. A change of scenery can do you good - get out the house and head to a coffee shop or park and see if that can help inspire you. 

Picture by  photosteve101

The above techniques all transfer well to app development. However, the best technique I have found is to plagiarise! Ok - maybe not really plagiarise, but look elsewhere for inspiration. It's easy to think that you need to always do something unique, but taking another idea and making it better or with a different twist is a great way to get your creative juices flowing. Check out the top apps in various categories on as many app stores as you can. If you do only Android - check the iTunes store as well and vice versa. 

How to: Install Gradle on Windows

Step 1: Download the latest version of Gradle from the official site.

Step 2: Extract the contents into a folder e.g. "C:\gradle-2.3".

Step 3: Open up the environment variables window. To do this:

1. Right click on your computer and click "Manage"
2. Click "Advanced System Settings"
3. Click "Environment Variables"

Step 4: Add new System Variable (or user variable if you only want it on your user account).

Step 5: Click New and enter Environment Variable as "GRADLE_HOME" and value as the bin directory of your Gradle installation path from step 2 e.g. "C:\gradle-2.3\bin". Press OK. 

Step 6: Find the "Path" variable and press Edit. Scroll to the end of the text and add the text "%GRADLE_HOME%". Remember to separate from previous entry with a semi-colon ";". 

Step 6: Press OK to exit the environment variable window and advanced system settings. 

Step 7: Open up a command prompt window. (press windows button and enter "cmd" as a shortcut). 

Step 8: Check Gradle version by entering text "gradle -v". If installation has been successful you should see something like the following: 

C:\Users\username>gradle -v

------------------------------------------------------------

Gradle 2.3

------------------------------------------------------------

Build time:   2015-02-16 05:09:33 UTC

Build number: none

Revision:     586be72bf6e3df1ee7676d1f2a3afd9157341274

Groovy:       2.3.9

Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013

JVM:          1.7.0_25 (Oracle Corporation 23.25-b01)

OS:           Windows 8 6.2 amd64

You should now be set up for using Gradle. 

Delivering constructive review feedback to technically superior employees

End of year reviews have either been recently completed or are in the process of being finalized. As a peer, scrum-master or manager you have probably been involved in delivering in some form feedback to the technical people in the team. In software development appraisals can quickly be dismissed as a box ticking exercise for management, but it doesn’t have to be this way. Camille Fourneir wrote a blog earlier today on this very subject where she actually emailed her team with a justification as to why the process is important. The process can be even harder if you are giving feedback on someone who has more experienced or specialist technical skills. Here’s some tips I have found help in constructing a useful, engaging appraisal process which helps you achieve the two main goals of a review process – highlighting achievements and identifying areas which can be worked on in the new year. This is useful for both people providing feedback on their peers, and for those managing others.

Image from freeimages

1. The review process is not one way!

Firstly the review process should be a two way process. If you are a manager, you are not just looking at a developers year and commenting on them; this is their chance to comment on your performance in relation to their role. For example, they may think you are good at dealing with impediments for the good of the team, but they find that you are sometimes a block between the development team and the end customer. This kind of feedback is invaluable to you and you should actively encourage it.

2. Include anonymous peer reviews in the process.

Secondly, contrary to point 1, the review process is not just a two way process – it should include peers. One person saying to another person they are good or bad at a specific thing can lead to confrontation or the person being appraised not believing the feedback; however if you get peer feedback from multiple team members with multiple people mentioning the same points, then it is harder to disagree with. A process which has worked well for me is for each team member to nominate 3-5 peers who can provide anonymous feedback on their performance. The appraiser collates the feedback to make it anonymous and provides it prior to the review starting to give the person time to review their feedback and take it in. Feedback from peers will generally resonate better than manager feedback, as you may work far more closely with your peers than you do a manager. This is also allows you to collate both technical and non-technical feedback from various roles within the company, removing the need for you to feel like you need to comment on someone's code if you yourself are not a developer for example.

3. Provide positive and negative feedback.

The third main point is that you need to provide both positive and negative (constructive…) feedback. It is important to celebrate the successes of the previous year. Even if someone has had an unbelievable year, you still need to give them something to work on the next year. The best employees will want constructive feedback so they can improve their performance – we are all professionals after all and the software development industry requires continuous self improvement.
The biggest failing in feedback processes I see is when peers only provide glowing feedback for their peers. Whilst this is great for the review meeting and egos can be massaged, it isn’t for the best of the person being appraised. Getting focussed feedback on areas to improve will be the best thing in the long run, especially if multiple people pick up on something. For junior members of the team giving feedback on someone with superior technical skills or for managers who do not have the same level of speciality in a technology this can be a challenge and intimidating. However, from experience, any honest feedback will be well received and will help gain respect amongst peers.

4. Regular reviews throughout the year.

The most common cause for uncomfortable reviews is when they are only done once a year. One to ones should take place throughout the year and should remove the opportunity for surprises when it comes to the review process. Is it really fair to land negative feedback after 12 months when you could have mentioned it in January and resolved the issue immediately?

5. The outcome of the review is not to encourage someone to aim for a managerial role – there should be a technical career path!

In software development there is a tendency to encourage our best engineers to progress to a point where their technical prowess is no longer used as they move to a management role – which is simply absurd. In reviews, the person being appraised may feel like they have to say they want to work towards management or a scrum-master role, purely as they want to show they have ambition even though it may not be the best thing for them. A good company will have a technical route for employees as well as a managerial route. Just because you are the best developer in the company, doesn’t mean you can’t improve and do more from a technical point of view. Make sure there is a career ladder people who don’t want to go into management can follow. Managers don’t need to get paid more than the best developers! Keeping your best developers developing if that is what they want to do will ultimately lead to you having a greater product.  Erik Dietrich describes this common problem in the following great blog post.

Related Posts:

• Managing programmers and the programming mother****** mentality
• Top 5 tips for when interviewing developers
• Can someone from a non-programming background successfully manage or lead a team of programmers?
• Situational Leadership in Agile

Kick-starting a development project with a solid testing approach - a 5 step process to ensure quality

Ask a developer about their feelings about testing and you can elicit a huge spectrum of opinions:

• "It's someone else's responsibility"
• "Unit testing is the way forward"
• "Manual testing gets the best results"
• "You can't make the software better through testing!"

Above are all things I've heard people say when talking about testing. However it is such a broad subject and we tend to focus on a very specific aspect of it (e.g. unit tests or manual tests) and we can sometimes miss the big picture. When kick-starting a new product or project, it's vital that you think about various aspects of testing up front - here's my 5 step approach to ensure you have quality software right from the beginning:
 

1. Test input early in software lifecycle. You need to think about testing as early in the project as you can. When looking at designs, for example, you should think about negative tests and edge cases to help guide your design decision process. If you have testers within your team then this is great and you should get them involved in the design; if you don't have test resource the developers need to take on this mantle (they should also do this if there are testers involved in the project). Testing then happens as the software is developed with close interactions between the testers and developers and quick feedback loops. This is a very agile approach which works really well. Leaving testing until the last minute just doesn't work. Getting them involved early also allows them to start writing test scripts which is important for step 3.
2. Automated test environment setups. A huge mistake people can make is leaving the test team to spend hours setting up test environments for every set of tests they do. This is such a waste - for every 1 hour spent testing you can easily burn 7 hours doing server and data setup. Investment in automated deployments for test purposes early on is a time well spent. There are also some really good by-products of emphasising this at the start of a project; you start to think about how the software would be deployed, how it would be upgraded potentially, how you load data into the system and also helps you consider your installation times. You will want it to be as efficient and quick as possible so any benefits your test team gain from this, your customers will gain when your product goes out the door.
3. Manual test scripts. In modern software development people sometimes baulk at the idea of not just manual tests, but writing test scripts for this. However, there is no substitute for getting a real person do testing. They find things a system can't, they can pick up usability issues etc. By writing test scripts at the design stage, the test team can test the design or mock ups without any software needing to be developed. Things that are missed in the design can be picked up at this stage. The test scripts should be well structured and repeatable as the manual test scripts can then be used as a basis for automation test scripts. A huge by-product of well written test scripts is you can then scale up your test team when you need to (e.g. before release) with new people who are unfamiliar with the product as the tests should be detailed enough for them to step through. You can scale up using test resource from other teams in your organization, from outsourcing potentially, or even by getting your development team to run through the tests.
4. A path to automation. If done correctly, the manual test scripts will provide you a set of repeatable steps that are always tested with every release of the software. The automated test environment setups give you a one click ability to setup the system on which to run this test. If you automate this manual test and marry it up to run on the automated deployment, then you have a quick and easy path to having good automation coverage. You don't need to automate everything - in fact I'd just automate the core 20-50% of your product. The time saved here in the long term will be enormous. Every time a developer commits, you can spin up a new test environment and then run your automated tests; if the tests fails the test team do not even need to do anything with this build and hence do not waste any time. Efficiency starts to go through the roof.
5. Regular bug purges. A bad habit to fall into is to leave bugs for later, as you are adding a great new feature. This ends up with a big backlog of bugs and a lot of technical debt. If this is a long term project - avoid this at all costs. There are various approaches to keeping your bug count low; rotate a developer onto purely bug fixing every iteration, assign 20% of your iteration capacity just to bugs, make every 3rd or 4th iteration purely a bug fixing iteration. Do whatever of these suits but make sure you do it. With a good continuous integration system and automated deploys and tests, the chances of bad code and major defects creeping in decreases which should help to keep this figure low.

Of course there are various other things that need done when thinking about testing a product and it will vary depending on project size, team sizes and skillsets. However, following the five steps above as part of your development process will ensure you have a quality driven approach to your product.
How do you approach testing? Are there any other things that should be done in the initial stages of product development which are big wins? If so please leave a comment below.

Related Posts

• Continuous integration is key
• The first key to agile success - get rid of offices!

Managing programmers and the programming mother******* mentality

I came across the following great site on Stumbleupon today - programming-motherfucker.com - and as a developer had a great laugh before realising that in my day job I'm really the guy the site is having a swipe at!

The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:

Screenshot of the alternative manifesto from http://programming-motherfucker.com/ 

Whilst the site may be a bit tongue in cheek (obviously taking inspiration from Pulp Fiction), a huge challenge of managing developers can be the fact they can see you as a roadblock in the way of them producing code. Ultimately you are responsible for the success or failure of a project and as a result you have probably applied a process to the team to help you ensure your team are progressing in the correct direction. So how, as a manager, can you break down this perception from members of your team who have this mentality?

Before I start, I'll confess when I started my first programming job I agree 100% with the sentiment of this site - I thought the people managing me had crazy processes which did nothing but slow me down. Over time and as I progressed through the ranks, I guess my mentality has changed - that or I've been broken by managers ;-)

Firstly put your cards on the table and explain why a certain process is in place. If you are transparent and can explain why you have a process - truthfully - then you will gain respect. If you use a tool like JIRA or Rally to manage workload, explaining that its really to help you manage people's workload and help plan releases and how their use of these tools allow you to do that will at least help them understand. The key here is to ensure that firstly the admin they are required to do is as little and efficient as possible, and secondly to get their input into the process and how they think it could change to make their work easier. At the end of the day a business and jobs survives because it makes money, if someone cannot accept that then you shouldn't employ them anyway.

The second thing which really really helps, is to be good technically in the first place. If you are not only a manager, but a good programmer (mother******) then they wont feel like you are bullshitting them. I talk about this in my post can someone from a non-technical background manage a team of programmers?

You have to accept that you can't force people to do something, if you want them to do it well. Unit tests are a great example; you can force people to do them but they'll end up writing rubbish tests. If the programmers are engaged in why the team wants unit tests, then they'll write good tests.

The last thing you should do, is look at the table above and work out where you currently sit - are you closer to the "They Claim to value" column or the "They Really Value" column. If you are to the right, you should look at what you can do to move to the left. Have you gone too far in trying to manage the team that you have actually moved away from the basic principles?

It's an interesting topic - how do you deal with programmers who have this attitude? If you are a programmer what do you think managers can do to be more effective?

Top 5 tips for when interviewing developers

Interviewing can be a stressful experience, not only for the interviewee! However, having a plan in place for how you want the interview to go and a set of good questions will take a lot of stress out of the experience.

1. Know what you are looking for before the interview.

You are hiring for a reason. You have a position to fill and probably a specific skills gap you are trying to fill. Write down the top 5 skills you need, what behaviours you expect from the person, what experience you expect etc. This should have been done at the CV sifting stage but it's still worth having clear in your head before the interview. 

2. Start the interview with technical questions on the top 5 skills you require.

They are in the interview as their CV has noted the key skills you are seeking - so start off (maybe after a welcome and explaining the process) with a few questions on these key skills. Make sure you know what answers you are expecting. A good candidate will answer these questions with ease, and more importantly will help them relax which helps with the rest of the interview. If the candidate doesn't know the answers, then you should try (within reason) to help get them to the answer you are looking for. If you can't - move on.

Note: at this stage, if a candidate has not answered well you may already know the outcome of the interview. It can be tempting to end the interview early, but you can leave yourself in a tricky situation legally as all candidates deserve the same opportunity in terms of questions. Law in different countries (especially around equality etc) can be a minefield so if in doubt seek advice from a member of the HR department. 

3. Get the candidate to solve a problem.

There is nothing better than seeing someone in action to help you make a judgement call, so challenge them to do something. Some people ask the candidate to sit a practical programming test which is great, but can put a lot of potential candidates off. I find asking them to design on a whiteboard how they would tackle a problem is a far better and quicker option which allows you real insight into their problem solving skills.

When asking them to design something, how about a simplified version of the product you are working on? How would they architect it? Do they dive into the problem at a very low level or do they think about the high level problem and drill down? How do they react to you challenging their design? Can they accept criticism and adapt their design, or can they defend their design and convince you they are right? Offer to work with them after a while and see how they collaborate and interact with you. This simple exercise (only needs to take 10-15 minutes) is in my opinion the best way to separate the good candidates from the bad. You may also learn something yourself from it! If you don't want to ask them to design your current product, why not try something everyone knows, like a board game such as checkers, chess or monopoly.

Asking candidates to design a board game can give you a great insight into how they work and approach problems.

4. Hire better than what you already have, and different to what you already have.

This one is simple, but it's amazing how many people (bad managers) fall into this trap. You need to hire better people than you have/you are if the company is going to grow and your projects are going to be successful. Bad managers are scared that they will be outshone by the people they are hiring; the opposite is true - your projects will be more successful and your own reputation will grow. Soon you will be heading up more recruitment as you have a proven track record. Additionally, you will get to know most new starts who will have instant respect for you due to the fact you interviewed them. James Caan goes into detail on this here.

Diversity is also key; just because someone works or thinks differently to your or your current staff doesn't mean they are doing it wrong. Different approaches and views are always good and can help to provide the best solutions, so long as the person can collaborate and defend their decisions; but you will know that from point 3 above!

5. Ask how they keep their skills up to date.

Last but not least, good developers keep their skill sets up to date. Ask them how they do this? Do they read textbooks or blogs or both? Do they attend conferences or take part in hackathons? Don't expect everyone to do all of these, just one will do. However, someone who doesn't do one of these is a big warning sign for me that they lack the drive to keep improving and learning. Would you want someone not up to date in the latest technology and trends to be designing your next product?

This again can be a great opportunity to learn about new blogs or books that you should check out. For senior hires, ask what they would recommend to a junior hire straight from University? Again, questions like this will give you an insight into how they may mentor junior members of the team.

That is my recipe for interviews and has worked for me pretty well, but there are always new techniques to learn so if you have any experiences you would like to share please leave a comment below.

Real time Google Analytics on the go

As I mention in most of my blog posts analytics is a key part of product development with Google Analytics being the key player in the market. When doing an A/B test knowing who your users are, where they are, when and how they interact with your app, website or blog will help you make informed decisions.

Checking these stats is important so when should you do it? I try to check my stats on the train to work in the morning with using Googles own app.

Take 5 minutes and try and learn from the data in front of you. I frequently can identify mobile devices for example which my apps don't run properly on, as it causes very low duration times and high drop off rates. Maximising what you have is really important!