Why Most Mobile Development Projects Fail

From This is why most mobile development projects fail

There are many things that can potentially go wrong in a project. I’m sure you also have your own unique horror story, or stories. But you’re too busy writing code. There’s no time to take a step back to try to figure out why you’re feeling this way.

Is this the nature of being a developer? Do all developers feel this way? Are you going to be feeling like this forever, as long as you are writing code for a living?

Is this really all your fault? Are you the one to blame?

You can try to deflect the blame. You can say this is not your fault. The idea isn’t as good as you thought it was. The design is too complex. The requirements are too stringent. The edge cases are too encompassing. There’s not enough time and budget planned for this large app. Or this team just doesn’t work well together. Maybe there are communication issues that need to be dealt with first.

You can also choose to take all the blame. Yes. This is your fault. You didn’t architect your app properly. You didn’t design and decouple your classes correctly. You didn’t refactor enough. The unit tests have holes in their coverage.

Or somewhere in between. A popular, feel-good, folk tale version. We work as a team. We fail as a team. We take the fall together as a team. So it’s everybody’s fault. No finger pointing.

Rethinking Work

From Rethinking work:-

To start with, I don’t think most people recognize themselves in Adam Smith’s description of wage-driven idlers. Of course, we care about our wages, and we wouldn’t work without them. But we care about more than money. We want work that is challenging and engaging, that enables us to exercise some discretion and control over what we do, and that provides us opportunities to learn and grow. We want to work with colleagues we respect and with supervisors who respect us. Most of all, we want work that is meaningful — that makes a difference to other people and thus ennobles us in at least some small way.


From Securing your HTTP API with JavaScript Object Signing and Encryption:-


Basically, the token (JWT) is the simplest structure that you will deal with while implementing JOSE in our architecture; it is a string representation of some data base64 encoded (other types of encoding might be applied, but this is not madatory): the JWT differs from raw base64-encoded data since it also includes informations about the encoding itself, in the token’s header; by concatenating the base64-encoded version of the token header and payload (the actual data) you obtain what the specification calls signature input, which will then be used to create the signature (JWS).


After the JWT comes the JWS, which is a signed representation of the JWT; it differs from the token just because of the signature; on an higher step of the ladder comes the JWE instead, which lets you encrypt the data in order to achieve an higher security level: the examples in the ietf draft show you how to create JWEs with a pair of private / public keys.

ISO 8601

From biztalk360:-

Out of the 2 important tricks we applied, one of the trick is agreeing on the standard date and time format string between the client and REST API. It’s a simple no brainer decision to use the ISO-8601 format, it’s pretty much THE internet standard when it comes to handling date and time in web focused applications.