Categories
book reviews Enterpreneur Wisdoms Programming

97 Things every Developer should Know – Summarised Notes

I came across this book due to it being popular on a top 10 list somewhere.
Usually I take these "xxx you should know" or "Top 100 essential things" with a pinch of salt.
Everyone is different and everyone has an opinion. Nonetheless I wanted to read this book and see what it is about.

I’ll put the 97 things in headings and have a short summary of each.

Don’t Put Your Resume Ahead of the Requirements

Also known as Solve the problem you have, not the problem you want to have

It is suggesting a tool because it is cool and hyped instead of it being the bet for the job.

Customers being happy with your work is much more important than a new, shiny tool or paradigm.

Also you need to spend a significant amount of time finding out what the tool does and if it is suited to a job – that is always a good idea. More knowledge will let you choose the appropriate tech from a more informed standpoint.

The right solution allows for a happier team, happier customer and far less stress – allowing you more time to do more research.

Always put the customer’s long term needs first.

Simplify Essential Complexity, Diminish Accidental Complexity

Essential complexity – the difficulty of each problem.
Accidental complexity – complexity arising out of existing systems or ways of doing things, things that are suppposed to decrease essential complexity but rarely do…

Overenginnered frameworks add more complexity than they relieve

Developers are drawn to complexity like moths to a flame…

People are your biggest problem

Most projects are built by people, and those people are the foundation for success and failure

You need conversation – treat people with respect and give them the benefit of the doubt. It should work both ways.

Remember conversations, not confrontations.

Communication is king, clarity and leadership – it’s humble servants

Clarity – how you communicate. No one on your team is going to read a 100-page architecture decisions document.
Being clear and concise in the way you communicate your ideas is vital to the success of any software project.

Being unclear and verbose is a huge smell.

Keep things as simple as possible – starting with a long word document is another huge smell.

Application architecture, determines application performance

Switching software vendors rarely solves applicatoin performance issues

Seek the value in Requested Capabilities

The customer or end user shouldn’t think up the solution. They should tell you the problem.

Ask for the intended value.
Collaboration – ask why?

Stand Up

You need to sell your ideas and communicate effectively to do that.
When more than one person is coming for advice – stand up – it communicates authority and self-confidence.
Slow down when making important points.

Everything will Ultimately Fail

No automated system can respond to the same range of situations that a human can

One line of code is worth 500 of specification

Unfortunately it’s far too easy to get wrapped up in the process of design.

The ultimate goal of a software project is a production system

There is no One size fits all solution

Developers should exercise contextual sense to each problem

Make Tests Run Fast

There can be more than one

In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multifaceted, fuzzy, messy world intrudes.

Why not face up to the reality of a messy world and allow multiple, incon- sistent, overlapping representations, services, solutions?

But let’s take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated val- ues arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the nonfunctional properties of a mart.

The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing.

These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes.

Simplicity before Generality, Use before Reuse

Most libraries, frameworks and infrastructure code is general purpose without reference to concrete applications.

This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful.

The best route to gen- erality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experi- ence rather than generality through guesswork.

When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intri- cate one that boasts of generality

Although well meant, many things that are designed just to be general pur- pose often end up satisfying no purpose

People do not on the whole pay for (or need) generality: they tend to have a specific situation, and it is a solution to that specific situation that has value

We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overbur- dened (not just overloaded) parameter lists, long-winded interfaces, and not- quite-right abstractions. In pursuit of arbitrary flexibility, you can often lose valuable properties—accidental or intended—of alternative, simpler designs

Don’t Ever Rush, Don’t ever panic

Rushing is cutting corners

Panicing is lack of clear though

Both do not achieve anything in the short or long term

Database as a Fortress

User interfaces, business and application logic, and even employees will come and go, but your data lasts forever

Consequently, enough cannot be said about the importance of building a solid data model from Day One.

While business rules and user interfaces do evolve rapidly, the structures and relationships within the data you collect often do not

It is critical to have your data model defined right from the start

Normalising your data

The database is the final gatekeeper of your precious data

Warning: Problems in Mirror May Be Larger Than They Appear

  • Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence, and persuasiveness. It rarely happens, even with highly paid, experienced consultants specifically hired to help avoid such problems.
  • Most software developers are optimists. Painful experience teaches us to temper our optimism, but without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are consistently right.
  • Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.

Reuse Is About People and Education, Not Just Architecture

The truth is that even the most beautiful, elegant, and reusable architecture, framework, or system will only be reused by people who:

  • Know it’s There
  • Know How to use it
  • Are Convinced That it’s Better Than doing it Themselves

There Is No ‘I’ in Architecture

Our egos can be our own worst enemy

people who:

  • think they understand the requirements better than the customers
  • view developers as resources hired to implement their ideas
  • get defensive when their ideas are challenged or ignore the ideas of others?

How to avoid it:

  • requirements don’t lie
  • focus on the team
  • check your work, understand others opinions and ideas

Try before Choosing

Creating an application involved making decisions.
Decisions shouldn’t be made from an ivory tower

Delay commitment until the last responsible moment; that is, the moment at which, if the team does not make a decision, it is made for them

I like this…

the later a deci- sion is made, the more information is available on which to base the decision

Understand the Business Domain

Know why a system is needed and how money is made from it.

Insurance lends more to a service oriented approach. FInancial markets are more workflow based.

Programming is an act of Design

software development—is a processes of discovery and learning, not a process of engineering and construction

Give Developers Autonomy

As a developer you rarely get the time to sit back and really look at how the whole system fits together

As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces, and databases, you should be making sure that all those pieces work well together.

If you’re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers

Time Changes Everything

  • Pick a Worthy Challenge
  • Keep it Simple
  • Be Happy with Old Stuff

Software Architect isn’t an Architect

We are not building buildings.

Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field

Practitioners of software development enjoy considerable compensation for work that is highly creative and exploratory

Scope is the Enemy of Success

Expanding scope is the enemy of success because the probability of failure grows faster than expected

What to do:

  • Understand the real need
  • Divide and conquer
  • Prioritize
  • Deliver results as soon as possible

Value Stewardship over Showmanship

There is a desire to prove one’s worth – so you debazzle and baffle the team with your technical brilliance.

This showmanship is counter productive to leading a software development project – architects must win over their team with solid architectural decisions and understanding the environment.

Stewardship is taking responsibility and ownership of a project.

Heterogeniety Wins

Heterogeneous develop- ment affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible

Context is king, and simplicity its humble servant.

For example they needed to choose a database for a tank – all databases achieved more than enough throughput for the systems on the tank.
However the firing of the gun cause an electromagnetic pulse that crashed the DB – so recovery time became the important criteria to base the choice on.

Dwarves, Elves, Wizards and Kings

  • Dwarves – hard workers – steadily producing artifacts in their cave
  • Elves – elegant, cultured creating beautiful and magical things
  • Wizards – immensely powerful and know magic

The architect is the king – must be familiar with the characters and architectures.
A good king will lead through many types of quests.

Architects’ Focus Is on the Boundaries and Interfaces

Divide and conquer – seperation of concerns…

The hard part is finding the natural place to locate boundaries.

With a bondary context map we can see what belongs together and what belongs apart.

Empower Developers

As an architect you should enable developers.
Make sure developers have the tools they need – tools should not be imposed on developers.
Repetitive and mindless tasks should be automated.
Developers should have top notch machines, access and speed to get things done.
If training is required – books etc. make sure they get it.

Record your Rationale

One type of documentation that ages well, doesn’t require much effort, and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture

Why? Why are you using this tech – what is the reason for this project?
What Assumptions are made?

Quality, time, cost and feature tradeoff.

For example you might choose grafana instead of kibana as it is not locked down to a single datasource (elastic) and has users and orgs in the open source version unlike kibana that you have to pay.

Challenge your assumptions

How often is it that assumptions are made up in your own mind – not backed by any evidence.
Just historical reasons cited.

Quesiton these assumptions…they may not be true.

Share your Knowledge and Experiences

We learn a great deal from success and failure.
Disseminating this experience and knowledge is vital in helping sustain progress.

Pattern Pathology

Design patterns are excellent tools for mitigating necessary complexity, but like all tools, they can be misused

Don’t become imfatuated by them – stamping patterns all over a project usually means overengineering.

Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision

It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately

As always…be pragmatic.

I don’t think I can name a signle design pattern…they might even be a smell when someone mentions them…

Focus on Application Support and Maintenance

  • There is no debugging in production
  • Log levels are lower in production
  • The CEO is now aware of the bug – mroe pressure

The relationship between developers and support should be good – most problems require a developer.

Make the support lead a core part of the dev team

Prefer prinicples, axioms and analogies over opinion and taste

Start with a walking skeleton

A minimal end-to-end implementation of the system that links together the main architectural components

Its all about the Data

If you stand back a little, a computer is nothing more than a fancy tool to help you access and manipulate piles of data

Data cuts through the crap

Make Sure the Simple Stuff is Simple

Thinking you are smart – and being clever.

Very bad smells.

Before Anything, an Architect Is a Developer

Perfect is the Enemy of Good Enough

My advice: don’t give in to the temptation to make your design, or your imple- mentation, perfect! Aim for “good enough” and stop when you’ve achieved it.

Avoid "Good Ideas"

The really insidious thing about “good ideas” is that they are “good.” Every- one can recognize and reject “bad” ideas out of hand—it’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.

The Business vs the Angry Architect

At this point we can draw on our experience to provide many solutions quickly, leaving more time to enjoy the challenging issues. We’re confident in our solutions and we deliver as adver- tised. We have reached homeostasis. This is the perfect time to make a colossal mistake—like deciding you know so much that it’s time for you to start talking more than you listen

You aren’t bigger thant he business – the business is our reason for existence

We live to serve the business.

Remember, when you’re talking you can only hear something you already know. Don’t ever start thinking you’re so smart that no one else has something valuable to say.

Don’t allow yourself to become a disgruntled genius who spends all of his time try- ing to impress others by making witty, condescending statements about how poorly the company is run. They won’t be impressed.

Stable Problems get Higher-quality Solutions

Real world programming is not solving the problem someone gives you, in the real world the best architects work around the hard problem – and find simpler solutions.

The skill is drawing boundaries so that problems are stable and self contained

Seperating into smaller chunks

What is interesting is that if the problem is stable, then when it is solved, it is solved permanently

It takes Diligence

An architect’s job is usually charactierised by ingenuity and problem solving

However an equally important characteristic is Diligence

Take Responsibility for your Decisions

  • Decisions should be substantiated and traceable
  • Decision has been communicated to people who are affected by it

Don’t be Clever

general intelligence, resourcefulness, thoughtfulness, a breadth and depth of knowledge, and an affinity for precision are laudable qualities in anyone, and particularly prized in architects

"cleverness " implies the ability to quickly get out of a jam but ultimately rests on a gimmick, a shell game or a switcheroo.

Clever software is expensive to maintain and brittle.

Cleverness should never be required, if it is then you haven’t sovled the problem simply.

Cleverness is tricking software into working.

In simple solutions – one component does one thing.

Your customer is not your customer

In a software requirements meeting the customer you are serving momentarily is not your customer.
Your real customer is you customer’s customer.

If you customer’s customer win, your customer wins

It will never look like that

A detailed design can fool you into thinking you have everything covered.
Planning is guessing.

The truth is no matter how in depth the design is – it will never come out how it is imagined in your head.

Minor changes and external factors add up and it never turns out the way it was designed

Choose Frameworks that play well with others

Think about how easily a framework can adapt, change and update as the system evolves.

A system should be designed with mutually exclusive frameworks.

Make a Strong Business Case

  • Establish the value proposition – executive summary – how it improves the business
  • Build metrics to quantify
  • Link back to traditional business measures
  • Know where to stop
  • FInd the right timing

Control the data not just the code

You need to be able to build the entire application, including the data- base, as one unit

Pay Down your Technical Debt

Do it right or take shortcuts.

Generally business people (sales, marketing and customers) will want the change made as quickly as possible.
Where developers and tested are more concerned with doing things properly.

Technical debt is in the form of system instability and increased maintenance due to no tests or documentation and shortcuts being taken.

Don’t be a Problem Solver

Developers get rewarded for solving programming problems, which are more local in scope than architectural problems

Finding problems and solving them architeturally is what gets you the big bucks and provides the most value

Sometimes the best solution is no solution – it is too easy to jump into problem solving mode – it is how we are conditioned.

Most problems don’t need to be solved at all – they just appear as problems when looking at the symptoms.

We should interrogate the problem itself – not just jump into problem solving mode.

Understand the problem and the context and the value that will be added or removed by solving it.

The Ultimate Tool is the Invisible One

A tool that doesn’t even feel like it is a tool – it is just part of the job

Find and Retain Passionate Problem Solvers

FInd problem-solving skills and passion – deep technical parts are not as relevant.

Asking someone about the process of diagnosing performance issues gives much better insight.

Keep developers motivated and keen.
Beware of negative reinforcement.

Learn a New Language

If you are a programmer – learn the business and testing languages.

It facilitates communication and helps the business do things more effectively

You can’t future-proof solutions

Solve the problem you have, not the problme you want

No one can predict the future – planning is guessing.

Accpet the fact and release yourself from the burden of the future.

Too much analysis and design also has this problem

The User Acceptance Problem

  • People don’t like change. There may be a negative reaction.
  • People have a fear of losing functionality, influence or power
  • People fear unproven tech
  • People have cost and budget concerns

Start early and engage with end users.

Consomme – Refine problems and thoughts

Software architecture requires a continual refinement of thought, a repeated straining of ideas until we have determined the essence of each requirement in the system

Many missed requirements and bugs in software can be traced to ambigu- ous, general language

Focus on what can be removed

For the End User, the Interface is the System

There are too many good products hidden behind bad user interfaces

Great Software is Built not Grown

Start small – the bigger the size at the start the more likely it is to fail.
Design small upfront.

More chance of being untestable and fragile.

Give the system a chance to grow – forget the massive spec ast the start.
Think minimal – think smaller.