Showing posts with label developing process. Show all posts
Showing posts with label developing process. Show all posts

Sunday, August 28, 2016

Mobile or Web (or both)?

Many beginning developers are questioning themselves about the area of the software development they want to build their career in and I was one of them (I'm still beginning, but I did choose already).

Today there are several major areas you can focus on.

  1. Operation Systems (Windows, Android, iOS etc.) - here you would write pretty low-level code that would handle interaction with the hardware.
  2. Game Developing - could be broken down into many subcategories, such as game engines, UI in games, gameplay etc. 
  3. Mobile - building apps for mobile devices running Android, iOS, Windows Phone etc. This area is growing really fast nowadays because of new mobile devices. Android is embedded in TVs, cars, VR and IoT (I personally think, that someday Android development would be one of these major areas of software development itself).
  4. The Web is growing just as fast as mobile, and the reason for it is online clouds. Almost everything is going to the web, it's convenient, you can access it almost everywhere, and in developed countries, it's fast and cheap. 
  5. Data science - this one is about big data analysis, machine learning and sometimes artificial intelligence. Note that it's actual science. You would be learning much theory before doing something actually working, unlike the other categories.
  6. Embedded software - this is low-level software that is built for one particular product, for example, for a digital camera. This category got a second breath with the emergence of the Internet of Things.
There are more, but it could take a whole post to list them all. If you think there is a category that definitely should be on this list, please drop a comment I will include it.

Today I want to talk about the two most popular (for now) categories: mobile and web development.

Mobile VS Web


Some people think that there is some kind of competition between these two. And they are right, in some way.

Mobile and web developers always try to make the experience on their platform feel better that on the other. 

Which is better, create a mobile app or just make an ada``ptive design of web version for mobile devices?

What is great about this competition is that it's healthy, it makes both platforms create new ways of interacting with the users, enchant them, simplify their life, and make them amazing.

I even heard the opinion that you should both web and mobile. Which, as I think, is wrong because if you want to build the career it's better to focus on something instead of picking all into sight.

So if you want to be a developer what should you pick? Unfortunately, it's not that straightforward but let's look at advantages and disadvantages of every category and I hope it will help you to decide on your own.

Web Development

Advantages Disadwantages
Cross-platform. You can run your app on every device that has a web browser. Runs only with browser so if you want to build offline app using web technologies (e.g. Atom) you need to ship a browser with it
A huge developers community You can only use JavaScript and it's kinda slow so you limited in optimization.
Fast development cycles (write->build->test->repeat) You do not have the computer resources control unless you're using some framework for building offline apps

Mobile Development

Advantages Disadwantages
Over a billion of people have a mobile phone There are two major platforms and you should choose only one (while it's better to have your app on both)
A huge developers community as well (for Android and iOS). Slow development cycles.
Full control over resources. You should care about optimal resources usage.
You can use native low-level processing (for example NDK) to optimize your app

For me, mobile is more convenient. And I don't mean that Web is worse, it should be your choice.

If you want to build something more interactive it's better to learn mobile, if you want your apps to be accessible from anywhere and anything that has a browser it's better to get to Web development.

I hope I helped you to choose the direction to go.

See you in the next one!

Sunday, August 21, 2016

The Boy Scout Rule in Coding


The Boy Scout Rule is the simple rule that can solve a huge problem of software development within a team.

It states: "Always leave the campground cleaner than you found it". Sounds pretty simple, right?

But, despite its' simplicity, not every developer follows this rule (me neither sometimes).

Sometimes, it's just kinda hard to take responsibility for someone else's code. I tell myself: "If someone else made that mess, why I should even work with it?".

But undoubtedly, it's way better for everyone to take care of the code you working on with a team. All the same, we are programming in the high-level languages and those were made for people who work with machines, not the machines themselves.

What is clean code?

To keep the code clean you obviously should know what clean code is and what it takes to write one.

Let's formulate some qualities of the clean code.

1. Clean code is focused.

You don't want your methods to consist of various blocks of unrelated code. You want one particular method to do one particular thing.

First of all, it's easier to remember what the method does and if it has a good name (which is a quality of clean code too) then the user of this method don't even need to know what it does behind the scenes, he can use it out of the box.

But you can say, what if my method should do many things behind the scenes? The key to handling this problem is an abstraction. 

For example, take the Glide library which I discussed in one of my posts Image Loading With Glide. To load an image you should handle HTTP connection, media decoding, memory and disk caching etc. But Glide makes it look like one thing, loading an image.

2. Clean code is expressive

I already talked about it when mentioned that method should have a good name.

Good naming can make your code self-documenting and make documentation less important and in some cases even redundant.

Let's think of a simple example.

  int method(int[] array) {
    if (array == null || array.length < 0)
      return 0;

    int integer = array[0];
    for (int number : array)
      if (number < integer)
        integer = number;
    return integer;
  }

It's pretty easy to determine what this code does, but it would be even easier if we choose better names for the method and variables.


  int min(int[] numbers) {
    if (numbers == null || numbers.length < 0)
      return 0;

    int currentMin = numbers[0];
    for (int candidate : numbers)
      if (candidate < currentMin)
        currentMin = candidate;
    return currentMin;
  }

I just changed the names, nothing else, it does the same thing (and now even the name implies that it searching the minimum in the array). But now it looks much much better.

To be honest, when I was writing the example of bad naming, I made a mistake. I wrote `number > integer instead of `number < integer` and noticed it only when I changed the names. In such a simple procedure, such a huge mistake just because of bad naming. Imagine what can happen when you work on a huge system!

3. Clean Code is minimalistic

Some studies say that it's better to keep your classes and procedures small. 

For classes, there is a magical number that states how many public methods it should have this number is 7. 7 public methods per class makes it easy to remember all the responsibilities of the class. But it doesn't mean, of course, that every class should have only 7 methods, just keep this number close to it.

For methods, there is no concrete number. Robert "Uncle Bob" Martin in his book "Clean Code" says
The first rule of fucntions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Funcions should hardly ever be 20 lines long. 
While Steve McConnell in "Code Complete" says the following
The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no bore error prone than shorter routines.
Some people (including Steve McConnel) say that a method should fit the screen without scrolling which is, in my opinion, is the good estimate, despite the fact that everyone has different screens.

I personally think that you should break down the method as soon as you find yourself trying to remember what does some part of the method do. Probably, when someone will look at this part he won't understand it, so it's better to replace it with well-named procedure.

These are in my opinion are top 3 qualities of clean code. There are more of course and you can find all of them in already mentioned books: Code Complete by Steve McConnell and Clean Code by Robert C. Martin.

Now when you know what clean code is you can start following The Boy Scout Rule of coding and make your and your co-workers' live easier. Sometimes it would be easy as renaming some variables. Sometimes it would require changes in the architecture of the software but it always worth it because you are the one who will work with this code.

Now let's make our code a better place! Maybe there is a badge for it ;)


Sunday, April 17, 2016

What if there is a similar app that is more successful than yours?



It's so much easier to publish your app in Google Play than in Appstore, that's why there are so many similar apps in Google Play. It creates conditions for healthy competition among developers.

To perform well in this competition you should always keep your app better than the others.

But what if your app is already losing? What if there is an app that has a larger audience than yours?

Actually, I think that it's not even a problem. It's an opportunity!

An opportunity

Wait, what? An opportunity? Why losing to another app is an opportunity?

Because you losing a battle not the war!

Actually, I think that software market is a place where nobody can win the war. It's Infinite War (not the Infinity War, though), with many many small battles.

Still, why losing a battle is an opportunity? Because if you analyse the reasons of losing, and why your opponent is winning you can gather very useful information.

With this information, you can come up with a plan that is even better than your opponent's.

What kind of information?

You should pay your attention to some key moments while analysing your loss.

These key moments are

  • Is your opponents app is actually better (be honest with yourself, it's the only way to improve), if so:
    • What is the feature/features making this better than yours?
      • If you find some, can you improve the idea of this feature in build it in your app?
    • If you can't find these features pay attention to the implementation of features both apps have, maybe it's just about the quality.
    • Look at things that are in your app but not in opponent's, maybe they are surplusses and making UX worse.
      • By the way, if you decide to remove these things, you should be very careful because if you have some decent audience they can use this features and removing them will be harmful.
    • Maybe it's all about graphic design. Some users migrate from one app to another (that has the same functionality) just because of design UX can make a huge difference.
  • If it is not, likely the reason of succes of other app is marketing. 
    • Unfortunately for many developers, better code and design doesn't mean larger audience, it only means an opportunity to get a larger audience. 
    • Pay attention to how your opponent marketing his app.
    • Does he have landing page about his app?
    • What traffic sources he uses?
      • Maybe he has a blog where he writing about this app (blog can be a huge source of traffic)
    • Compare this to your ways of marketing your app, find differences and figure out what you should change to gain more audience.
Another really important source of information is feedback, not only from your app, but form every similar app out there. You can find out what people need from their own testimonials.

With all this information, you can take action and make your strategy better.

Is it even legal?

About the first part, it might seem like stealing features, yes it is, but you should be a clever thief.

You shouldn't just take your rival's app and make another x.x.x version of it. Actually, you should do the things your way.

You probably already have some picture of what is your audience and why they like your app. So do everything with this on the background.

Your actual audience is your potential audience

Actually, in every business, you should aim at the audience you already have. Improve your app for them. I think that actual audience is your potential audience. It's word of mouth marketing. 

With this approach of satisfying your actual audience, you can get exponential growth. 

It's really important, but many developers and entrepreneurs don't understand that, and they are drowning while trying to attract new users. 

When you trying to walk through someone else's path you will eventually discover that you're always second.

So don't just steal someone's features try to adapt these for your users. And if you can't do so, just don't, it means that it's not for your app.

For example, look at Apple, everyone knows that they are stealing features and ideas from other mobile manufacturers, but they do it in their own way satisfying the users they already have. I think, that this is the reason of their success.

Overview

The main idea of this post is when there is some app that already has more users than yours, it can be a source of really useful information for you if you will analyse it carefully.  But you should be pragmatic about what you doing with your app when trying to gain more users.

Okay, build your audience guys, see you next week, peace!

Sunday, April 3, 2016

How To Combine Learning And Developing part 2


Read 1'st part of this post where I talk about Learning While Developing.

Hi! Today I'll tell you about the second (and I think the right one) way of combining learning and development. This way I call Developing While Learning.

Oh wait, sounds like it is the same thing as Learning While Developing, isn't it?  Yes, it might sound like the same thing, but in fact, it's opposite. Let me explain what it all means.

The essence of Developing While Learning

As I said Developing While Learning is the opposite to Learning While Developing, so you might already guess the essence by yourself.

Developing While Learning is about creating some product while learning something. But it shouldn't be your dream project. It should be something appropriate for your level. With time, probably your learning projects will be more difficult, but when you're starting out don't go right off the bat. Even most experienced developers start with "Hello world!" app when they start to learn  new technology.

Defining a success project

When you learn something you have to define your success project. Like the end point of learning, the point where you know you learned what you wanted to learn.

This project should be something really specific because when you trying to achieve something blurry and not concrete you still don't know where is the point of success. 

Here's the example of good success project
  • Weather App
    • Fetching forecast data from API
    • 3 activities
      • Weather forecast for the week
      • Details about weather for specific day
      • Settings
This project used in Developing Android Apps course at Udacity (which I encourage you to enroll).
And here's the success project that can actually harm your learning process.
  • An Android app
You'll never find something like this in any course at any University because it's too broad. I can build "Hello World" app and I'll be happy with it as an elephant (it's the Russian phrase, means very happy)  or I can try to build something with 3-5 killing features, bells, whistles and brilliant design and still not be satisfied with it. So be as specific as possible when defining success project.

The other reason why your project should be specific is that you can break it up into subtasks and for each subtask you can find out what you should learn to perform it. It's psychologically easier to perform multiple small tasks than one tremendous one.  

How to define your success project

I think the best way to define your success project for learning is to steal it. Yes, you read it right, just steal the idea from some app. Steal from Gmail, Dropbox, Instagram, Facebook, any app you know. Just take something for your level.  

It's sounds like reinventing a wheel, but it's actually reimplementing a wheel because to learn how to make a good wheel you should make some wheels (probably bad).

With this approach, you will not spend your time on thinking up and sifting ideas to just learn something. 

And who knows, maybe you'll make a better app than one you stealing from.

You also can implement your own idea, of course, just make sure that it's appropriate for your level and for what you want to learn.

Benefits of Developing While Learning

The most evident benefit is an experience. You're facing challenges that you will face in real development, but when you'll face it in real development you'll already have a solution for it.

Another benefit is your very own code. Anything you developed that way is now yours and you can use it any way you want. You can rebuild using your new skills you acquired or improve it some other way and publish it. You can take some parts of your code and make a framework from it or contribute to an open source framework. Now you can use it the way you want it to be used.

And last but not least benefit is that one day you can set your dream project as success project for your learning. With any app you develop your knowledge gets higher and higher, and there will be the moment when your dream project is appropriate for you as a success project so why not to try it?

Learning 4 life

Actually, I think that developer's professional life is about constant learning. Every developer learns something new with every new project (if it is not routine, of course). Some developers just know more than others, but there's plenty thing that they'll learn in their professional life.

So don't be afraid of saying that you just learning, everyone is just learning! 

Overview

So here's what we know from 2 parts

  1. There's 2 ways Learning While Developing and Developing While Learning
  2. Learning While Developing is not as good as may seem (but it's still a way)
  3. Developing While Learning is beneficial and actually fun!
  4. Define your Success Project! (you can steal it, nobody will know ;) )
  5. Make it as specific as possible! 
  6. Have fun learning!

That's pretty all you should know about combining learning and developing.


See you in the next one, peace!


Sunday, March 27, 2016

How To Combine Learning And Developing part 1


I think there are two ways of combining these two things, today I will tell you about one of them Learning While Developing.

The Example of Learning While Developing

Consider you have the idea you passionate about, like a web or mobile app that solves all peoples problems at once. So you want to implement it as fast as possible, but you don't have much knowledge about the app development. So you decide to start developing and just learn new things while doing your app.

So basically, it's about this approach, you have something you really serious about and you
don't have much knowledge about how to do it.

Is it a good approach?

First of all, let's find out the reasons to do things that way

  1. You're really passionate about your idea.
  2. You are afraid that somebody can "steal" your idea and implement it while you still learning.
  3. You want to do it as fast as possible. 
  4. You think it'll be a great success.

And now let's find out is it a good approach.

I'm absolutely sure that it's not. I had an experience of doing things that way and I didn't finish any of projects that started with this in mind. The reason, I think, that a big idea requires big efforts to develop. And when you know nothing about how to develop your idea into a product it requires even more efforts. 

Don't be delusional


Last 2 reasons to do thigs that way are delusions because of the first reason. When you're passionate you can't be pragmatic and evaluate your possibilities.

You'll can't develop your idea fast if you don't even know how. You'll spend most time Googling things and always reworking your old code because you learned how to make it more effective. You'll end up transferring your project from one framework to another because you "need" that "cool feature". And then your passion will end and you just move to another great idea. But when you already have some experience in the field you can decide what tools you should use to meet your goal.

But why great success is a delusion if there's such a great idea? Because for users, quality is more important than an idea. Don't forget they don't know that your app can solve their problems until they actually use it on a regular basis so the only way to estimate your app is quality but you can't provide it yet.

What if somebody will develop a similar app? Actually, I think it's not a bad thing. I even think when you're starting out it's a good thing. Because you have an example of how your app should work and you can focus on how to implement it and improve it instead of thinking about every small detail in your own app. Also, someone who has the same idea and has skills to implement it will do it faster and better than you anyway. Picasso had a saying he said "Good artist copy, great artist steal". (by the way, I stole this phrase from Steve Jobs)


I will tell more about similar apps in one of my future posts.

The right way to combine learning and developing

So there is the other way to do that, and I will tell you about next week in the second part of this post so stay tuned.

See you in the next one, peace!