The table of two values, Behaviour and Structure!

The table of two values, Behaviour and Structure!

Is it more important for the software system to work or is it more important to be easy to change? If you ask the business managers they will say work is more important, some developers also go along with this attitude but that’s the wrong attitude.

Why the wrong attitude?

  1. If you give me a program that works perfectly but impossible to change, it means it won’t work when the requirements change.
  2. If you give me a program that does not work but easy to change, it means I can make the change to make it work.

If you’re a programmer with the attitude (1.) then one day your system will reach to the point where the change will be impractical (cost of change will be unaffordably high).

Eisenhower Matrix

Eisenhower said, I have two kinds of problems, the urgent and the important, where the urgent are not important and the important is never urgent.

when it comes to software, The first value of software is behavior, is urgent but not always important. The second value is architecture, is important but never urgent. Of course, some things are not urgent and not important.

  1. Urgent and important
  2. Not urgent and important
  3. Urgent and not important
  4. Not urgent and not important.

Screen Shot 2018-09-24 at 9.51.23 PM

Mistakes that business managers and developer make is to elevate items in position 3 to 1. It means they always fail to separate those features that are urgent but not important from those features that are really urgent and important and this failure leads to ignoring the important architecture of the system in favor of the unimportant features of the system.

So if you are a software developer, you are hired to maintain the quality and structure of the system and only you know the importance of the architecture.

Thanks for reading it, if you want to read in more detail, buy “Clean Architecture by Robert C. Martin”

 

What are the Design and Architecture?

Screen Shot 2018-09-23 at 7.23.12 PM

 

What are the Design and Architecture?

The design is more often seems to when it comes to structures and low-level decisions whereas Architecture is often used in the context of something at the high level where we can see how components are connected with each other. But for starters, there is no different at all.

What is the GOAL of good software design?

The goal of software architecture is to minimize the Human Resources required to build and maintain the required system (By Uncle Bob Martin)

Basic fundamentals measure the design?

The measure of design quality is simply the measure of the effort required to meet the needs of the customer if the effort is low and stays same through the lifetime, System design is good else it’s bad.

The Signature of a system design mess?

  • Developer point of view
    The graph says developers started with nearly 100% of productivity but with each release, their productivity going down

Screen Shot 2018-09-23 at 8.00.44 PM.png

  • Executive point of view?
    Release 1 was delivered with a few hundred thousand payrolls and by the time of 5 release, it’s going to touch $500,000.

Screen Shot 2018-09-23 at 7.55.59 PM.png

What is going wrong?

The moral of the story says everything in one line: “Slow and steady wins the race”. Yes, it all because of overconfidence. Everyone wants to hit the market first or release the app asap with the statement “We can clean it up later” and they can’t go back for cleaning the things up because now we have the new feature, new release so maybe next time, next time and next time.

The only way to go fast is to go well.

To take the software architecture seriously we have to think and need to know what good software architecture is, compare the different architecture with the requirements.

Thanks for reading it, if you want to read in more detail, buy “Clean Architecture by Robert C. Martin”

4 Ways to Solve The Problem | Quick-Notes

Problem-solving requires two types of mental skills, analytical and creative. I know this sounds very high level So let’s talk about the basic fundamentals what generally I try to follow in day to day professional and personal activities.

  1. Listen carefully You need to pay very close attention to any information in the problem description. The optimal solution for a sorted vs unsorted array will be totally different so don’t miss anything.
  2. Brute Force Yes correct, Get the brute force solution as soon as possible, don’t think about the optimal solution. I always catch the first thought that comes to my mind. Don’t think about code, the algorithm just rough idea.
  3. Optimize Now it’s time to work on your Brute Force with some BUD (Bottlenecks, Unnecessary work and last Duplicated work) techniques.
    1. Remove the unused information.
    2. Solve it manually on paper with an example.
    3. Reverse engineer your thought process. HOW DID YOU DO?
    4. Make a Time VS Space trade-off.  CAN YOU REDUCE-IT MORE?
  4. Implement Congratulations now you have an optimal solution on paper. The last goal is to write beautiful, modularize code.

If you are trying to solve the problem in interview KEEP TALKING because your interviewer wants to hear how you’re going to approach the problem and it will make the interview more interactive.

Thanks a lot for reading the quick-notes!

Clean Code | TDD | Swift | iOS | Quick Notes

TDD is a way of writing software, where we write as little code as possible to make the test pass and then late refactor the code.

Golden laws from Uncle Bob

  • You may not write production code until you have written a failing unit test.
  • You may not write more of a unit test that is sufficient to fail and not comping is failing.
  • You may not write more production code that is sufficient to pass the currently failing test.

Whenever we create a new iOS app, we start with UI/ViewController/Business Login directly but Idea here is to start with the Test-cases. How? Let’s say you want to add the functionality to find out the divisible or not as below mentioned the code. Write down the test-case first.

func testIsDivisibleByThree() {
let brain = Brain()  
let result = brain.isDivisibleByFive(number: 5)
XCTAssertEqual(result, true)
}

But we don’t have the class Brain till now!!! So create a class adds the function, don’t forget the aim is to write as minimum code as you can.

class Brain {
    func isDivisibleByThree(number: Int) -> Bool {
        return true
    }
}

Because as of now, we are returning static boolean value, test-case will be a pass for sure. Same pattern we need to follow for each and every code we are going to write.

Simple words I can say there are 4 stages in TDD.

RED – Write down the test case
GREEN – Write just enough code to make the test-case pass
REFACTOR – Clean up existing code
REPEAT – repeat the cycle

In above codebase we have done RED and GREEN, let consider the stage 3rd, REFACTOR.

Let’s say now we have to write a function where we need to check whether a number is divisible by given number or not, like this

func isDivisibleBy(divisor: Int, number: Int) -> Bool {
  return number % divisor == 0
}

So we have refactored the code, Utilizing it like.

func isDivisibleByThree(number: Int) -> Bool {
    return isDivisibleBy(divisor:3, number:number)
 }

the idea is to repeat these steps so we can make sure when we are making any new changes, is it breaking some existing functionality.

I have tried to create short notes on how to follow TDD but also Idea is here is to decouple your code from UIViewController as much as possible so that it will give you more testability scope (for implementing this I have tried MVVM design pattern in few my recent projects, will share one quick notes on that as well).

Thanks for reading.

Clean Code | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_

A handbook of agile software craftsmanship by Robert C.Martin.

Two reasons for reading this book, you’re a programmer or you want to be. So by the end of this, we’ll know how to write good code because we are going to look code in each and every direction.

There will be a code, some peoples say we are at the end of the code and we don’t need the programmers because business people will generate the program from the specification.  That’s not true because at some level details can’t be ignored so we have to be specified.

It is bad code that brings the company down.

Why do we write the bad code? go fast, in a rush, don’t have to time to think before writing the line of code. One thing we’ve all said we’d go back and clean it up later. But we didn’t know LeBlanc’s Law: Later Equals Never.

The Total Cost of Owning a Mess, we all see teams that were moving fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two, three other parts of the code. As the mess builds, the productivity of the team continues to decrease. Now management adds new developer to increase it but it creates the new mess because the new developers are not aware of current architecture and then together they create more mess.

The Grand Redesign in the Sky, eventually team rebels and they inform management that they cannot continue with the codebase and they demand redesign, Management doesn’t want to expend the resources but they can’t deny because productivity is 0. A new tiger team is selected and everyone wants to be on that team, now they have to develop same what old app is doing also the new changes that are coming in. It takes time but after some time, the developers of tiger team is gone and current developers demand new because it’s mess.

Attitude, Why does this happen to code? we complain that the change in requirements, schedules that were too tight, we blame stupid managers, intolerant customers etc. but the fault is in ourselves we are unprofessional.

The only way to make the deadline, the only way to go fast is to make your code clean as much as possible.

What is Clean Code? there are lots of definition given by different deep experience programmers, here I have mentioned one that I like most.

Bjarne Stroustrup, Inventor of C++. I like my code to be elegant and efficient. The logic should be straightforward to make it harder bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimisations. clean code does one thing well.

Thanks for reading this, here I am also including my point what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.

Clean Code | Introduction | Quick Notes

51bPR2V9fBL._SX258_BO1,204,203,200_.jpg

A handbook of agile software craftsmanship by Robert C.Martin.

Writing clean code is what you must do in order to call yourself a professional, there is no excuse to do anything less than your best.

In this series of quick notes, I am going to share the quick notes from this book with you, So welcome aboard, let’s start with the introduction.

So think 2 mins, what is the valid measurement of code quality for you? The answer according to the book is funny but its WTFs/minute. haha 🙂 Now you can easily measure the quality of your code.

Next question will be, How to handle bad code? the answer is Craftsmanship. There are two parts of learning Craftsmanship: Knowledge and Work. It means you must gain the knowledge of principles, patterns and best practices and you must also grind the knowledge into your finders, eyes by working hard.

Yes, that’s why this book is divided into three parts.

  1. First will teach you principles, patterns, and best practices.
  2. Second, Case studies of ever-increasing complexity. Here you have to think and give the reason for making each change.
  3. Third, a list of heuristics and smells gathered while creating the case studies.

Thanks for reading this, I am also including what I like most and I must recommend this book to each and every person who is responsible for writing/reviewing code. For more just buy the book.