Promote your Windows 10 app with AppRaisin - here's why

Have a look at the above graph. It shows the number of downloads for a Windows 10 Mobile app. The app has had no promotion at this point. It was "soft-launched" ready for a big promotional push at the end of January.
There has been one place where this app was mentioned publicly though. On the 8th of January it was included in AppRaisin. Notice what happened on that day--a big spike in downloads.

AppRaisin is a Windows 10 app that helps people discover new Windows 10 apps and games. Anyone can submit an app when it is newly released or updated. This includes the people who have created the app.

Have you built or are building an app for Windows 10? Want more people to hear about it (and hopefully download it)? Then what have you go to lose by submitting it to AppRaisin?

5 tips on working with technical debt

After listening to a recent .Net Rocks show about Technical Debt I thought I'd share some tips I have on working with technical debt.

I worry if "Technical debt" is just a label we put on things so we don't have to think about them. e.g. "We know this will create technical debt and we can come back to it at some point in the future." This doesn't require that we do the best to mitigate the consequences of that debt now though.

At its simplest, technical debt is just a name for the consequences or side effects of the decisions that are made (intentionally or accidentally) when developing software. Dealing with technical debt therefore comes down to just dealing with the consequences of past decisions. Fortunately, there are lots of ways developing software that make it easier to deal with these consequences and lessen their impact.

1. Have automated tests for the system at a high level.
   Regardless of what you call them, you need tests that verify that the application/system works at a high level, not just at a method/class level. When it is possible to verify that the system does what it should it removes the risks associated with changing how it does it, that is changing the code to remove the debt but without breaking the overall functionality. This is key to avoiding regressions and negative side effects of addressing debt.
2. Remember the boy scout rule. (Leave the camp/code better than you found it.) If while working on something you find some existing code that needs improving, and you can do something to improve it without it being a major distraction from the task that was your original focus, you should make such improvements. Of course this depends on a working culture that allows code gardening.
3. Allow code gardening.
   Just as with a real garden where you might tidy up some leaves, pull up a weed or prune a rogue branch from a hedge as part of the general maintenance of the garden, there are general maintenance tasks that can also be done to code. This is very similar to the boy scout rule but with an important requirement that it must be allowed for code unrelated to what you're supposed to be working on. Suppose you were working on Feature Y and it involved modifying Class X. With the boy scout rule, you may make other modifications to Class X that improve it. With code gardening it's also potentially acceptable to make changes in the completely unrelated Class Z. Say you just happened to glance across Class Z by chance and noticed an improvement you could easily make. If code gardening is allowed then you can improve it now. If code gardening is not allowed then the best that might happen is a bug gets raised to improve Class Z at some point in the future. The reality though is that it's a low priority bug and so never makes it on to the schedule. The opportunity to make an incremental improvement to the software is missed and so the slow degradation in overall quality continues. It's important to note that for this to be possible it requires that small frequent check-ins be allowed (not a one check-in per feature policy) and a branching strategy used that allows such small improvements to be easily made in isolation.
4. Enforce code reviews on non-trivial changes.
   You can alleviate the risk of a low bus factor on an area of code or something that no-one working on a project wants to risk touching by using code reviews. Code reviews have a lot of benefits but the important point here is that the person who signs off on a review agrees that they will be able to support it in future, should the original author not be available. This is not about assigning responsibility or blame. This is about ensuring that the original code was clear enough that another developer can understand what has been created. If no one is willing to sign off on a review because they wouldn't be able to support maintaining it - improve the code until someone agrees that they could.
5. Use "why-and" comments in code to explain intentional debt.
   Comments in code are often a bad thing. All things being equal, code should be self-explanatory. You shouldn't need code to explain what a piece of code is doing or how it is doing it. Where there is a general need for comments though is if why a piece of code was written the way it was isn't clear. From a business perspective sometimes deadlines are critical. You may have to put in a dirty hack to get something working to meet the deadline. This is an example of where comments are useful. Just adding a comment that acknowledges a hack (or other form of technical debt) has been made may be useful to help avoid people thinking badly of you in the future isn't enough to actually help other developers or the project. In such a scenario you should add the comment that acknowledges WHY the intentional debt is there AND what should be done to address it. Addressing the debt may mean more time is needed or waiting on a dependency. The important thing is to provide information that will help when someone comes back to work on the area of the debt. The aim is to avoid someone looking at the code and asking "why is it like that?" and also to provide context and information that will help when someone does have to modify it.

Just a few points but they've helped me in numerous projects in the past. Let me know what you think or if you have any other tips to make working with technical debt easier.

What if security in software isn't really an issue?

This is a thought exercise as much as anything. I do think that software security is massively important and more should be done about it.



What if security in software isn't really an issue?

Yes, a few big names have been in the news recently but they must be the exception or it wouldn't be newsworthy. It's not like everyone is getting hacked all the time. Is it?

I don't worry too much about the security of my car. It doesn't have a fancy alarm and satellite tracking. There are many other cars that are easier to steal or are worth more to someone who wanted to steal a car. Isn't it the same with software?

Even if I, as a business owner, suffered a security breach there aren't any real consequences.

• There may be some negative press for a short time--but all press is good press, isn't it?
• There may be a small (relatively) financial consequence in terms of fines or legal bills.
• No one of any note who has been hacked previously has suffered any major, long term, negative consequences.

It's said that education is the answer to solving software security issues but where's the motivation?

• If there's no real consequence to security breaches, then why spend time and money educating people to prevent it.
• If security isn't an issue, then we can get more developers into the industry faster as that's one less thing new developers have to be taught.
• It's not just a developer education problem. Even if developers knew how to make more secure software they won't always be given the time and resources to do that if their superiors don't think it's important so you need to persuade the whole business on the importance of software security.

Trying to sell a solution to a technical problem (software security) that someone might not have, yet, to a non-technical stakeholder (someone higher up in the business than a developer) can be tricky. In trying to persuade them to fix a problem they don't have now you're selling risk/insurance.

Let us spend more time now to prevent an issue that we might have at some point in the future.

This may or may not work based on political, financial or other business constraints.

Then there are issues of accountability, liability and due diligence.
If there is a security breach who's responsible? The developer? Or the more senior person(s) in the company who didn't ensure developers had the time, knowledge and resources to do what's best for the company?
There's also no way to be certain you're secure. So how much effort should be put into having more security? When do you stop taking more time and expense to increase security, for an uncertain return?

Even the systems we have in place to try and ensure some level of security aren't brilliant. A few years ago (yes noting that things may have changed in the intervening time) I was working on a website that had to go through a PCI compliance check. I was shocked at how little the check actually covered. Yes, it meant the site was not doing some bad things but it doesn't mean it was doing only good things. The checks potentially left a lot of what I saw as possible security vulnerabilities--which I ensured were addressed.

Let's just forget about all this though. Software security doesn't really matter as there are no real consequences to the business and the only people who seem to talk about it are developers pointing out what they think are the things the other developers didn't do or did wrong.


But wait, could capitalism solve this problem for us?
Education (of developers) is largely claimed to be the solution here but is capitalism, not education, the way to get change? - If more companies get hacked then insurance claims and therefore premiums will go up--eventually to a level which makes a difference to the company. At which point there will be incentives for being more secure - and even proving it. If a company could do things to prove it was serious about preventing software security issues it might then be able to get a discount on the related insurance.
What if a business could get cheaper insurance for software related security issues by signing up to a service from the security company which would continuously be checking for breaches?

• The insurers would benefit if they didn't find anything as they'd be less likely to face related claims.
• The insurers would benefit if they did find something as they could put up the premium and hopefully the company could implement a fix before it is exploited and so not have to make a claim.
• The company would benefit if no vulnerabilities are found as they'd pay lower premiums. Plus their user data and business continuity would be protected.
• The company would benefit if something was found as they'd have the opportunity to fix it before it being exploited.

Those doing the testing would be incentivized to find exploits and disincentivized from missing something that is later exploited by another party.

Could this be done now?
Unfortunately, I think not. It depends on the costs of having security experts work for the insurers and paid for (either directly or indirectly) by the companies taking out insurance.
Sadly, I think we'll need more exploits, pushing up insurance premiums further, before this becomes financially viable.

Things look like they will get worse before they get better. :(

How do you test your Windows Apps?

When you're testing your apps, how do you do it?
Do you rely on yourself and your memory of things you should be testing or testing for?
Or have you created your own checklist?
If you have created one, how do you know it's complete?
Or if you haven't, where would you begin creating one?

Whatever you situation, the App Quality Alliance are here to help you. They recently (the end of November) released two documents specifically designed to help anyone testing Windows apps.

Baseline Testing Criteria for Windows Applications

Accessibility Testing Criteria for Windows Applications

Whatever your experience with app development, testing, and/or windows there should be something in here for everyone, to help you be confident you're releasing high quality applications.



Gratuitous self-promotion: I served as the technical reviewer for these documents.

Raisin' up app news with AppRaisin

Are you a Windows [Phone] app developer who wants another way to tell potential users of an app about it's launch or major update?
Or
Are you interested in hearing about new and updated Windows 10 apps?
Or maybe you're both.

If any of the above apply to you then you should check out AppRaisin by AdDuplex.

It's like a social news site focusing on Windows app news.

Users decide what news rise to the top by "raising" the apps they like and ignoring the noise. This way enthusiasts get to make sure that top of the crop apps get the attention they deserve and less active users get a curated list of just the best app news.

If you want to discover some of the best new apps then check it, and them, out now.

Download the universal Windows 10 app from the store now.