I guess no.
What you should instead?Start small, improve it, then extend.
Incremental design should be your guide.
Here is how you would use it to design a calculator:Plan a system that does only addition and nothing else.
Implement it.
Improve the now-existing system’s design so you can add other operations also.
Plan subtraction and repeat step 2 and 3.
Plan multiplication and repeat step 2 and 3.
Plan division and repeat step 2 and 3.
11.
Predictions“A prediction is simply a forecast that something will happen in the future.
It could be factual and based on some kind of objective data or it could be based on an assumption.
”When faced with the fact that their code will change in the future, some developers attempt to solve the problem by designing a solution so generic that (they believe) it will accommodate to every possible future situation.
Being too generic involves a lot of code that isn’t needed.
You can’t predict the future, so no matter how generic your solution is, it will not be generic enough to satisfy the actual future requirements you will have.
Most probably, this time will never come and the code you wrote to solve future problems will increase complexity, make it hard to change the pieces of code and eventually it will become a burden that may destroy your software.
Don’t predict to future.
Be only as generic as you know you need to be right now.
12.
AssumptionsWhat is the assumption?“An assumption is something that you accept as true or suppose to be true, although you have no conclusive proof.
”One of the great killers of a software project is assumptions.
Let’s see how an assumption can kill a software project.
A developer knows that they have to develop a system to do X.
Then they think that the system will require them to do Y in the future, and they implement Y as well.
They write thousands of lines of code to design Y.
In the future, the developer realizes that the current requirements are completely different than what they thought.
But now, the software has unnecessary codes that make it hard to throw away because everything is intertwined.
It takes months to refactor the code and now they think to rewrite the whole software from scratch which will cause them to lose months.
To avoid being a victim like this developer, follow this simple rule:Code should be designed based on what you know now, not on what you think will happen in the future.
13.
Stop ReinventingIf, for example, you invent your own garbage collector when a perfectly good one exists, you’re going to be spending a lot of time working on the garbage collector, when you could just be working on your software.
The only times it’s okay to reinvent the wheel is when any of the following are true:You need something that doesn’t exist yetAll of the existing “wheels” are bad technologies or incapable of handling your needsThe existing “wheels” aren’t being properly maintainedSimple rule:Don’t reinvent the wheel.
14.
ResistanceAs a developer, your first reaction to changing requests should be “NO’’.
Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them.
Because unnecessary changes will increase defects in your software.
How can you know that there is a need for them?Go back and remember your software purpose.
Then remember the simple equation in prioritizing section.
From: rsc@plan9.
bell-labs.
com (Russ Cox)Subject: Re: [9fans] design clairvoyance & the 9 wayDate: Thu, 8 May 2003 04:05:31 GMT> What does tomorrow's unix look like?I'm confident that tomorrow's Unix will look like today's Unix, only cruftier.
Russ15.
AutomationDon’t spend your time on repetitive tasks.
Set them up and forget about them.
They can work while you are sleeping.
When you realize that you are doing something again and again, just remember this rule:If you can automate it, automate it.
16.
Code measurementMeasuring programming progress by lines of code is like measuring aircraft building progress by weight.
— Bill GatesI see developers who measure their software quality based on code lines.
They think that more code lines mean that they are doing a great job.
The software contains hundreds of thousands of lines of code, which means the software they work on is so big.
The question that pops up here is: Is it really that big, or there is something wrong there?The answer is that most probably there is something wrong with their design.
Most of the simple solutions don’t require a lot of code.
You can achieve simplicity with a little bunch of code and solve the problem.
I’m not saying that the least code is always better.
While you want to avoid having less code, you can easily fall in a trap that will cause you to write clever code that is hard to understand for others.
You should find a balance.
The optimum code is a small bunch of code that is easy to understand, easy to read.
17.
ProductivityHow do you measure your productivity?By writing more lines of code or by throwing hundreds of lines of code away?!Your main goal should be keeping your code base as small as possible.
The question is not “How can I write more code?” rather it should be “How can I remove more code?”“One of my most productive days was throwing away 1000 lines of code.
” — Ken Thompson18.
TestingWhen should you add logging and error handling to your project?You should add logging in a very early stage.
This will help you to find the problem easily and save your time.
I see many mistakes when it comes to testing code.
Let me give you an example.
There were two conditions, a simple if-else block.
The developer gave input to the software which will enter inside the if block.
They tested it and committed code to source control.
Done!.What about else block?.When software was shipped to production, that caused a lot of errors.
When you test your code, you must execute all new lines at least once and you should start to test parts before the whole.
When you have a bug, first you should reproduce it.
You shouldn’t guess the source of the bug and apply fixes based on your assumption.
Most probably, you will be wrong.
You should see it with your own eyes before applying the fix.
You should be reliable.
When other developers in your team see that you committed new code to source control, everyone should know that your code is tested, and works.
Untested code is the code that doesn’t work.
19.
(Under)EstimationDevelopers’ estimation sucks.
Usually, they underestimate things rather than overestimate them.
They underestimate the time and effort required to develop a small amount of code or a feature.
In the end, this underestimation leads to missing deadlines.
The solution: Break the big thing into smaller things.
The smaller it is, the easier it is to estimate.
You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project.
Remember:Everything takes longer than you think.
20.
Running Away From RewritingI believe that when you embrace the fundamental principles of software development mentioned in that article, you won’t come to this point.
However, if, somehow you make these mistakes and find yourself thinking about rewriting your code, here is the main thing that you should know:Rewriting code is often a developer delusion, not the solution in most cases.
Why is it a delusion?Well, because it’s harder to read code than to write it.
This is why it is so hard to reuse code.
This is why our subconscious mind whispers to us “Throw it away and start over” when we read another developer’s code.
There are many cases that you should consider to rewrite your code from scratch and you can read them here.
But, here is simple advice for you:Refactoring should be the first option.
21.
Documentation and CommentingOne of the common misconceptions about commenting is that developers add comments that say what code is doing.
This is wrong.
That should be obvious from reading the code.
If it’s not obvious, it means that it is not readable and it should be made simpler.
When you can’t make the code simpler then you should add the comment to explain this complexity.
The real purpose of comments is to explain “WHY” you did something, not “WHAT” the code is doing.
If you don’t explain this, other programmers may be confused and when they go to change your code they might remove important parts of it.
Write a comment to explain “WHY”, not to explain “WHAT”.
Another thing is documenting.
It is important to have documentation to explain your software’s architecture and every module and components.
This is required to see the high-level picture of your software.
When a new developer joined your team, it would be easier to understand the software as a whole.
When developers don’t have any clue about other parts of the software, they could easily make a mistake in their own part which can affect other parts also.
22.
Picking Technologies (Tools, Libraries, etc.
)First things first, always remember this rule:Don’t depend on external technologies or reduce your dependency on them as much as possible.
Why is that? Because they are another common source of complexity.
They can kill your active development and make everything even harder.
When you are dependent so much on external technologies, you are not free.
What if there is a major bug in that technology? You have to wait for the developers to fix that bug and if this technology is in the center of your project basically you are stuck, you can’t move forward.
So that’s why it is so important to pick the right technologies for your project.
There are a few factors you should consider before you start using some technology:Is there active development behind it?Will it continue to be maintained?How easy is it to switch away from?What does the community say about it?If you can find the right answer these questions, you can reduce the risk of picking the wrong technology.
23.
Self-DevelopmentKeep learning.
Try out different programming languages and tools, read books on software development.
They will give you another perspective.
Every day small improvements will make a real difference in your knowledge and skills.
Be open-minded.
Don’t be obsessive about one technology.
Use the required technology to solve a specific problem.
Don’t be in the unnecessary discussion like Microsoft vs Linux:)Know that every specific problem has its own specific solution.
24.
Don’t be a heroA lot of times it’s better to be a quitter than a hero.
For example, let’s say you think a task can be done in two hours.
But four hours into it, you’re still only a quarter of the way done.
The natural instinct is to think, “But I can’t give up now, I’ve already spent four hours on this!” So you go into hero mode.
You’re determined to make it work (and slightly embarrassed that it isn’t already working).
You grab your cape and shut yourself off from the world.
Don’t be obsessive.
Know when to quit.
Don’t hesitate to ask for help.
25.
Don’t Ask Questions… Ask For HelpWhen you have something to implement and you are not sure about the solutions, don’t ask others how to so it …at least not immediately.
Instead, try anything and everything you can think of.
This is more important the less comfortable you are with a concept or language.
When you can’t think of anything on your own, search!.Find answers and try them out.
Modify those answers, see if you can understand why they work, adapt them to your code.
…But always seek advice.
When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice.
Look to peers and senior developers to review your code.
Thanks for reading!.I hope this guide helped you out!Originally published at blog.
huseyinpolatyuruk.
com.
.