Posted by: lrrp | December 16, 2017

Why Finishing Software Is Hard. And What To Do About It.

Yes, The Last 10% Is Hard.

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time”

— Tom Cargill, Bell Labs (ancient software wisdom — if you know an Agile equivalent, I’d love to hear it)

There’s nowhere to move the deadlines — time’s up. The thing you are building, which used to feel like a set of well-understood building blocks, now streams towards you in an endless river of barely connected details. UX wording needs to be exactly right; reliability, which was “good enough for beta” now needs to be 100%; that niggling bug everybody has been working around for weeks needs to go away, today; a feature that you thought worked great is missing something — not clear what it is, but it is clear that the beta users have to have it; the CEO has an idea and…

The more you do it, more you learn to pattern match on traps you’ve fallen into in the past. But I’m not sure anybody ever learns enough to bring their projects into the final deadline smoothly and without stress. (Maybe you do — if so, let everybody know your secret). There’s something more fundamental going on here.

Why Finishing Any Creative Project Is Hard

We think of software as “engineering”, which gives it a mechanical, logical feel. Some of it is. But mostly, software is a creative act. Parts are knowable: they are understood libraries, or built to known templates, but the most interesting, the coolest parts, aren’t.

Creating those pieces is more like writing — the engineer (coder? writer? yes, writer), is translating a set of abstractions (business requirements, wireframes, architectural outlines) into expressions of those ideas in language.

And like writing (or painting, music, sculpture — anything), we discover software as we make it. We can sketch, plan, write user stories and build prototypes, but however diligent we are, those are representations of the thing, not the thing itself. We can only discover the thing itself by building it. We accept this for writing novels (who would ever publish a first draft?), but we are less comfortable applying this to software. For some reason, software is still “engineering”, and “engineering” is seen as precise, knowable (yes, even when we’re deep into Agile and Lean). It isn’t.

The last 10% is hard because we can’t know what the “last 10%” is until we get there. That’s the nature of the creative process. All the final details, the hidden difficulties, the polishes that make a piece of software (or a novel, or a song, or a sculpture) brilliant don’t fully reveal themselves until the rest of the structure is built. The software “tells us what it wants to be” — we have to build it to find out.

Why People Don’t Like Finishing

And then there is the uncomfortable fact that a lot of people don’t actually like finishing things. We do like being finished, which is different. It’s that lovely sense of having something behind us, of completion. We really want that. Especially during the long “last 10%” which is so much more work than we expected. We badly want that lovely hit of dopamine, that change, that relaxation, that comes from being finished. So, as humans, we gloss over details, try and ignore user feedback, hope that a patch to a reliability problem will hold, and generally avoid the hard truth that it isn’t done yet.

And then there’s the fact that the world is eventually going to see our work, and judge it. It’s scary. So we put off exposing it to the outside world, because the outside world is going to tell us what it thinks (whether the “outside world” is beta testers, your investors or your buddies at the co-working space). It’s the “nah nah can’t hear you” approach: as long as we don’t let anybody see it, we won’t suffer the possibility that it isn’t done yet.

We want the answer to the question “is it beautiful?” to be “yes”. And for quite a while, the answer will be “no, not yet”, or “no, not even close”. Scary to hear. So we’d rather “polish a few things”, or “just do another pass”, or “get the design exactly right”. Anything to avoid the bright lights…

A Note on Agile and Lean

Agile and Lean help. The Agile and Lean models are process structures which help us model fundamentally creative and fluid business of building software. By emphasizing that software isn’t done until it’s done, that iteration is a fundamental methodology, not a bug in development, and that the sooner software is exposed to real use the better (among many other things), these frameworks more closely match how people express themselves in code. (And it’s worth reminding ourselves that a software project is only that: people expressing themselves in code).

But all frameworks can be hot-wired. The definition of “done” can be fungible. Features that are “hard” can mysteriously end up way down the story list. Judgement, management and leadership still apply. Finishing is still hard.

Getting Finished — Management

Accomplishing anything worth doing with a group of people meansmanaging: tracking details, setting deadlines, assigning tasks — building and checking off lists. Finishing a software project means lists. Long lists.

There’s no real magic here. Your job is to hold the truth up to the light, and that means you just have to track everything: the truth is in the details. All of them.

Everything. Bugs, issues, opinions, performance, you name it. Anything you don’t track will be incomplete or dropped. Could be you’ll get away with it, but eventually the habit of producing incomplete results will catch up with you and your team. There are plenty of tools for tracking, and entire books on how to do it well. Find one, and do it.

It will feel like overkill to track every single thing. It’s not. It will perhaps feel overwhelming. You may feel you are being unreasonably stubborn, or too detailed. You’re not. You are providing a vital service to your team to help them achieve the difficult and rewarding task of finishing something difficult.

Eventually the lists will start shrinking rather than growing. And you will be close to being finished.

Getting Finished — Leadership

So you’re managing. You’re also leading. Your role is to provide the energy to help your team through the barrier of not wanting to see where things stand — to see that yes, you’re not finished yet but you will be.

Your leadership role is to have courage and confidence that what you’re building will work, and that each detail, bug and nasty little issue taken care of is a step towards finishing. Really finishing.

So you celebrate wins. You celebrate finding bugs. You dig mercilessly into performance reports. You ask questions about quality levels. You show progress daily, weekly and monthly, and you let your people know what yes, it’ll be finished, and yes, it’ll be great. You know that, right? No? Well, what do you need to fix?

Finishing Is How You Leave Your (And Your Team’s) Mark

Pieces of software I had a hand in building over twenty years ago are still being used by thousands of people (hi, FrameMaker!). Projects that I thought at the time would kill me and the people working for me helped allow our company to go public (hello — and goodbye — Director). I love the fact that we built them. I love that people are still, to this day, working in careers that are possible because of them. The act of actually finishing them? Hard! Unfun. Not sure I loved it, but all of that intensity was necessary to bring them into the world, and I’m glad they are there. They are parts of my mark in the world.

Finishing a challenging, creative task is one of the harder things human beings can do. We are wrestling something out of the realm of thoughts and ideas into the real world. We have to see, and come to terms, with all of it — every detail, every flaw. To do that requires a constant focused, concentrated effort.

If you are leading software people, your job is to help your team get into that uncomfortably intense pocket of growth.

And then you’ll be done. And you will have added something to the world, something that you, and the people that work with you, have created.

Posted by: lrrp | December 4, 2017

When to Switch to Microservices

With the rise of microservice architecture in the past couple of years, many developers find themselves wondering if it’s right for them. There are two frequently asked questions I’ve seen concerning microservices:

  1. Should I switch to utilizing microservices?
  2. When and how should I switch to microservices?

Should You Switch?

The focal point of whether to change your architecture can often be productivity.

Productivity drives developer happiness. When developers are productive and able to make the changes they want, things are good. In an ideal world, programmers would be less concerned about implementing a feature than designing it. The goal ultimately is that we design more than we code.

The problem with all of this is that our applications become harder to change as they grow in size and age. Technical debt starts to pile up and bring productivity to a crawl. What were once considered arbitrary changes then become six-to-eight-hour rabbit holes of trying to understand why a change doesn’t work.

Eventually productivity hits such a snag that something has to be done about it. This is the point where microservices start to appeal to many teams. They offer what looks and seems like a welcome change of pace.

However, microservices are not a short-term bet. They’re a long-term investment.

Neither are microservices a total solution to developer productivity. In fact, they change your team’s entire workflow, skill needs, and way of thinking. The early days of implementing microservices for your projects will likely be full of the trashing and troubleshooting you’re trying to avoid. However, this short-term annoyance should eventually usher back the productivity and organization your team is after.

I’ve learned that teams that are sizing up the switch to microservices should ask themselves a few questions:

Do we want to make a long-term investment in our application architecture?

Are you planning on eventually sunsetting your application? Think three to five years into the future on this one.

Are we feeling limited by a language subset in our application suite?

Do you feel limited by a language’s speed or tooling? We often tout about how a certain language is faster, cleaner, more usable than our current stack. Yet, what would it actually look like if you could write a service in a “better” language? Would the concept appeal to you and your team?

Are we wanting to invest more in serverless services?

Serverless services are a trend with microservices where we delegate certain parts of our architecture to a third-party service. Utilizing serverless services like AWS Lambda could be a really helpful means for your team to start writing microservices.

Are our engineers willing to share problems and issues across different services?

Most small teams have to be able to hand off microservices issues and bugs to one another. You have to be willing to spread out the knowledge base and understanding, perhaps a whole lot more than you’re used to.

Let’s assume you finally decide that you want to pursue microservices, but there’s still a question lingering in your team strategy: “When and how should we switch our architecture?”

When and How Should You Switch?

The truth is there’s no perfect time to switch to microservices. However, there are a few important considerations you can put in place beforehand to try to make the transition smoother:

  1. Cut down on feature churn and refine the product you want to decompose into microservices.
  2. Commit to a certain stack of languages and tools.
  3. Establish, at least generally, the product’s design as a microservice.

I can’t express how difficult it is to convert a constantly changing application into microservices. If you don’t have a core product to decompose and refine, you’re going to be doing a lot of redundant changes to your services instead of making them more stable.

Committing to a certain language and/or stack is a bit harder in practice than theory. Many companies will tell you that they use a certain set of languages and frameworks, and they certainly might. However, there’s always a crisis at hand as to whether to keep or move on from a certain element of it. Being committed to a certain stack (at least for the time of transition) makes it a lot easier to decompose. You can certainly try to risk a new technology or idea on a microservice. However, you’ll be wrestling with the cost of integrating something new as well as a new architecture type.

Have an idea of what you’re trying to decompose into. Try to cut down on the tendency to wing it and change it later just because it’s a smaller service now. Microservices work best when they’re modular but also well-defined.

Digesting It All

While it might be easy to think of our applications as soulless digital machines, I’m becoming more convinced we should treat them as our homes. We want to make our codebases warm and inviting to anyone and everyone who encounters it. Does your house have the space for careful organization, for example? Does it give you the ability to only allow specific things in each room?

With microservices, we have to have a preference for that level of organization, and we need the ability to implement that sort of separation. Yet you also have to want to have a finer separation of concerns between each part. If that idea resonates with you and your team, then maybe it’s worth looking into.

The transition isn’t easy. However, it could lead to a much more organized and long-lasting codebase at your company.

Posted by: lrrp | November 28, 2017


Posted by: lrrp | October 15, 2017

Never Stop working on yourself…..

Posted by: lrrp | October 15, 2017

The software engineering notebook

Fellow software engineers/hackers/devs/code gardeners, do you keep a notebook (digital or plain dead-tree version) to record things you learn?

Since my days assembling glassware and synthesizing various chemicals in the organic chemistry lab, I’ve found keeping notes to be an indispensable tool at getting better and remembering important lessons learned. One of my professors recommended writing down, after every lab sessions, what had been accomplished and what needed to be done next time. When lab sessions are few and far apart (weekly instead of daily), it is easy to forget the details (for example, the mistakes that were made during weighing of chemicals ). A good quick summary helps with this!

When I first started working for a software company, I was overwhelmed. Academic software development was indeed very different to large scale distributed software development. For example, the academic software I wrote was rarely version controlled and had few tests. I had never heard of a ‘build’ or DEV/QA/PROD environments, not to mention things like Gradle or Jenkins. The academic software I worked on was distributed in zip files and usually edited by only one person (usually the original author). The systems I started working on were simultaneously developed by tens of developers across the globe.

To deal with the newbie developer info-flood, I went back to the concept of a ‘software engineering lab notebook’. At first, I jotted down commands needed to setup proper compilation flags for the dev environment and how to run the build locally to debug errors. A bit later, I started jotting down diagrams of the internals of the systems I was working on and summaries of code snippets that I had found particularly thorny to understand. Sometimes these notes proved indispensable in under-stress debug scenarios when I needed to quickly revisit what was happening in a particular area of the codebase without the luxury of a long debug.

In addition to keeping a record of things that can make your development and debug life easier, a software engineering lab notebook can serve as a good way to learn from previous mistakes. When I revisit some of the code I wrote a year ago or even a few months ago, I often cringe. It’s the same feeling as when you read a draft of a hastily written essay or work of fiction and then approach it again with fresh eyes. All of the great ideas suddenly seem – well- less than great. For example, recently I was looking at a server side process that I wrote to perform computations on a stream of events (coming via ZeroMQ connection from another server ) and saw that for some reason I had included a logging functionality that looped through every single item in an update (potentially 100s ) and wrote a log statement with the data! Had the rate of events been higher, this could have caused some performance issues, though the exact quantification of the impact still remains an area where I need to improve. Things such as these go into the notebook to the ‘avoid-in-the-future-list’.

Posted by: lrrp | October 14, 2017

Do You Have ‘Self-Taught’ Imposter Syndrome?

In a world where devs are increasingly self-taught, it may be easy to negatively compare yourself to those colleagues who have a BS or MS in Computer Science. But don’t.

A lot of you are brilliant, and you don’t know it. It saddens me to see such wasted potential in those that think they are not good enough but in fact are amazing and often 10 times better than those that think highly of themselves. These people, not all of them, but some, I feel suffer from imposter syndrome.

I will do my best to explain my experiences with this mental state of mind and how I’m currently battling with it. Once you understand what imposter syndrome means, and a read a real life example, I hope you get some mental clarity.

Always Planning: Procrastination

Once you see what I’m talking about you will understand the importance of taken action instead of planning. This is the only cure for “imposter syndrome.” Allow me to explain.

What Exactly Is Imposter Syndrome?

By its very definition, it is a concept describing high-achieving individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud.”

Let me start with my personal experience. I know I’m good at what I do. But often times, I get the fear that I’m not as good as the teacher or that I should not do it because it’s already been done. I believe this has been established since I have been on my own. I know I am good enough, and I know I can get it done. But the feeling that I don’t deserve what I have persists.

Imposter Syndrome: The Roots I’m Seeing

Learning in isolation and being self-taught leaves you (typically) to hold yourself accountable. Whereas in college and other team-based learning environments, you have a team or classmates to compare and be held accountable against. The lack of accountability while learning (no bad grades here) sets an unvalidated tone in our society. You didn’t go to school, why should you be trusted? Other forms of validation are also, in my opinion, critical to our success, but understanding which ones to seek makes the difference.

It is important to understand that not being validated is something a lot of people fear in their careers. Being validated means you have the skills or you are “valued” for your achievements. The misconceptions of what validation truly is versus what it is believed to be is the number one thing that holds people back from excelling in their careers and life in general.

Getting the Right Validation

What Is the Wrong Kind Validation to Seek?

The desire to please everyone. Negative, unconstructive opinions and thoughts of you mean absolutely nothing. Get that into your head. If someone doesn’t provide feedback that helps you grow, it isn’t worth accepting. Do not take invalidation from negative peers, take validation from your works and knowing you did your best and always working towards improving.

The piece of paper. – The internet has changed the way we learn by several orders of magnitude. It has lifted us to new heights and has made us excel in research and innovation. This has left some developers who are self-taught without the ability to land high paying gigs in the corporate world. The need for a bachelor’s degree continues, when, in all reality, the real world experience that we have implemented by far exceeds the value of the 4-year computer science degree. Real world experience always triumphs unused knowledge. Don’t get me wrong – having a degree is fantastic! But it shouldn’t be a huge variable in today’s world.

Please don’t let not having a degree bother you. If you are self-taught, you have a lot of skills that many others don’t. It takes self-discipline to sit down and do research in order to learn a new craft. You have to take pride in that. Never undervalue the education you are presented with, even if it’s an education you gave yourself at your own pace.

Where Should You Find Validation?

The answer should be your work. Your work is your validation. At the end of the day, when you lay your head down, your projects, your art, whatever it is you have tossed out into the world is your validation. It shows, “Hey I can do this. I did this. Look here it is.” Hopefully, people will see what you can do and hopefully want to work with you or encourage you in a positive and motivating way.

Improve Daily – Remind Yourself Who You Are!

You have to tell yourself nearly every day that you are good enough. That you have the ability to succeed as long as you put time and energy into your goals. That you will succeed and that there is only one person who could stop you. Yourself.

Keep this in mind: I have to hold myself accountable for all my work. Only I can change my direction. Each day I wait is a day I get behind. I will move forward. I will succeed, and I will establish myself in the areas of my expertise. I will grow every day. I will do something unique to find new people and opportunities. I will not fail. I will never give up. I will always do my best to complete what I put my blood, sweat, and tears into. I will not be scared to hear the word ‘No’ and I will not be afraid to overcome it either.

How to Over Come Imposter Syndrome

One word, execute. I have noticed that when I have the most down time is when the imposter syndrome kicks in. I don’t think I’m good enough. I question life choices. If I’m executing, doing something productive, like writing this blog, then I’m doing something to put something out into the world which serves as my validation. Some people will read this, some will share. Others may not even get past the first sentence. But it is okay. The ones that reach the end are all that matters.

You have built your own success – remember that.

Posted by: lrrp | October 8, 2017

Microservices Communication: Eureka Client

Eureka! No more need to store service URLs in code properties and update them with every change. Service discovery with Eureka will solve the problem for us.

In the previous Java microservices tutorial example, I created a Eureka Server. In this tutorial, I will show you how microservice communication happens. In this tutorial, I will create a Eureka client that communicates with a Eureka server — a microservices service registry.

Before diving into the code, let me tell you more about the about Eureka’s client/server communication.

Eureka Client/Server Communication

Talk to the Eureka server: At first, while the Eureka client is bootstrapped, it tries to talk with the Eureka server in the same Zone. So, suppose a Eureka client instance is in the Asia Zone —  it tries to connect to the Asia Zone’s Eureka server. If it is not available, then it fails over to another Zone.

It determines its targets using the eureka.client.serviceUrl.defaultZone property, so we need to give a URL of the same Zone’s Eureka server. And for failing over to another Zone, the Eureka server should be peer connected.

Register: Next, the Eureka client/microservices share the instance information with the Eureka server and registers themselves with the {service-id } (

Heartbeat: After registration is successful, after every 30 seconds, the Eureka client sends a heartbeat to the Eureka server to renew its leases. So, if after 90 seconds the Eureka server does not get any heartbeat from the Eureka client, it unregisters the Eureka client instance from the service registry and sends the updated registry to all peers and Eureka clients.

Fetching service registry: Eureka clients fetch the service registry from the Eureka server so it can discover other services and communicate with them. After every 30 seconds, this service registry information gets updated by receiving delta updates from the Eureka server. Please note that the Eureka server also caches the delta updates every 3 minutes, so the Eureka client can receive the same delta instances multiple times. After receiving delta updates, it again tries to compare its local registry with the server registry to check that delta is successfully applied. If there are any mismatches, it pulls all the registries again.

Unregister: When the client instances are going to shut down, they send a cancel signal to the Eureka client so the Eureka server unregisters it from its registry.

Synchronization: Be aware that there may be some time lag as the Eureka server and client manage the cache.

Coding Time:

We will make the EmployeeSearchService a Eureka client. To do that, first, we need to add the discovery module for Spring Boot in the Maven pom.xml.


Now add the @EnableDiscoveryClient annotation on top of

package com.example.EmployeeSerachService;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
public class EmployeeSearchServiceApplication {
   public static void main(String[] args) {, args);
After that, run the Eureka server first, then EmployeeSearchApplication. You will see that the Employee Search application is registered in the Eureka server with the service id EmployeeSearchService.

Learn what a Eureka server does, why it is useful in microservice architecture, and how to complete its standalone setup.

What Is the Eureka Server?

The Eureka server is nothing but a service discovery pattern implementation, where every microservice is registered and a client microservice looks up the Eureka server to get a dependent microservice to get the job done.

The Eureka Server is a Netflix OSS product, and Spring Cloud offers a declarative way to register and invoke services by Java annotation.

Why Is the Eureka Server?

To understand why the Eureka server is needed in microservice architecture, let’s understand how one service calls another service REST endpoint for communication.

Say we need to call the employee payroll service to get payroll information for an employee. The payroll service is deployed on the localhost 8080 port (we got that information by passing the employee primary key) so we just call the following:

http://localhost:8080/payroll/1 or

Where localhost/ is the hostname/IP address and payroll is the payroll service context, 1 is the employee primary key.

But this is only possible when you know the hostname/IP addresses beforehand, then you can configure your URL. So here the hostname or IP address is a constraint or a pain point.

If the IP address of a server/container is fixed, then you can use that approach, but what happens when your IP addresses and hostname are unpredictable?

Nowadays, on a cloud platform, it is obvious that all the servers or containers use dynamic IPs for autoscaling. And the interesting thing is that in microservice architecture, the key principle is that your service can autoscaled as per load, so cloud platforms are ideal for microservices.

What I am trying to say here is that we can not predict the IP addresses of the container/server beforehand, so putting dependent services IP addresses in the config file is not a solution. We need a more sophisticated technique to identify the service, and Eureka server steps in here.

Eureka Server/Client Communication

Every microservice registers itself in the Eureka server when bootstrapped, generally using the {ServiceId} it registers into the Eureka server, or it can use the hostname or any public IP (if those are fixed). After registering, every 30 seconds, it pings the Eureka server to notify it that the service itself is available. If the Eureka server not getting any pings from a service for a quite long time, this service is unregistered from the Eureka server automatically and the Eureka server notifies the new state of the registry to all other services. I will write this mechanism elaborately in the next article.

Now one question may pop up our mind: what is the Eureka server itself?

The Eureka server is nothing but another microservice which treats itself as a Eureka client.

What I mean is that the Eureka server has to be highly available as every service communicates it to discover other services. So it is recommended that it should not be a single point of failure. To overcome it, we need multiple Eureka server instances running behind a load balancer. Now when there are multiple Eureka servers, each server needs to have synchronized registry details so that every server knows about the current state of every microservice registered in the Eureka server registry.

The Eureka server communicates its peer server as a client and clones the updated state of the registry, so the Eureka server itself acts as a client. We can perform this by just configuring the eureka.client.serviceUrl.defaultZone property.

The Eureka server works in two modes:

  • Standalone: in local, we configure a stand-alone mode where we have only one Eureka server (localhost) and the same cloning property from itself.
  • Clustered: we have multiple Eureka servers, each cloning its states from its peer.

The Eureka server can have a properties file and communicate with a config server as other microservices do.

Standalone Setup of Eureka Server

Step 1: Create a project template from While creating the template choose the following modules:

  1. Config Client
  2. Actuator
  3. Eureka Server



Step 2: Open the downloaded code template and import it as a Maven project in your IDE. The pom.xml looks like this:

<?xml version=”1.0″ encoding=”UTF-8″?>




    <description>Demo project for Spring Boot</description>


        <relativePath/> <!– lookup parent from repository –>












Step 3: Now open and put the annotation @EnableEurekaServer on top of the class. By doing so, this application now acts as a service registry. All other Microservices can register themselves by using this service URL.
package com.example.EmployeeEurekaServer;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
public class EmployeeEurekaServerApplication {
    public static void main(String[] args) {, args);
Step 4: Now change the to as it may consult with the config server if it has any properties defined in config server. In the file, write the following lines:
Unique name for Eureka server service
It consult with other Eureka server for sync the service registry as it is standalone mode I give the local server address.
In which port server will be bound.
This determines is this server register itself as client as I said earlier Eureka server is also act as client so that it  can sync the registry.The value false means prevent itself act as a client.
Not register itself in service registry
Now our Eureka server setup is complete. We will now run this project as a Java application. Now hit the following URL: http://localhost:9091. You will see the following dashboard:
Posted by: lrrp | October 7, 2017

The Burden of Being a Senior Developer

To truly be a ‘senior’ developer, one needs to not only have the requisite experience but a need to get better a produce quality code.

Who is a senior software developer? A developer who has over seven years of experience. I think this is not quite encompassing. I think it is a developer who possesses a certain state of mind. So a developer with six months’ experience can be senior (theoretically) if they have that state. But this state is usually acquired through knowledge and experience, over time. This state comes with some responsibilities (or burdens).

Any enterprise that is worth something is then worth doing well. And how do we do things right? By ensuring that what we do does not ‘collapse’ or is not done messily. In the field of software engineering, the fear of not incurring technical debt, and the ability to prevent such debt, is the state of being a senior engineer.

With the burden of a technical sort also comes an emotional one. In fact, the latter drives the acquisition of the former. And it is this emotional burden that I want to talk about.

I started out programming as an independent contractor in my home country of Nigeria. I specialized in Java applications. I was self-taught and happened (fortunately) to start out on high-level projects. Having been brought in on a referral, I quickly acquired a senior developer image before my clients (they were mostly international nonprofits), although I was new. I was stretched by these projects to research software engineering best practices (not because I was required to do so by my clients, but for fear of mediocrity). So I had an accelerated path.

Now, seven years after my first gig I have decided to become a JavaScript developer. There is a dearth of quality software firms in my country (and I hate boring jobs). So I have set my eyes on a new American world-class software engineering organization with an office in Lagos. This company is of course very team-oriented in their development approach. But I have been like a solo assassin as a consultant, not like a member of a well-commanded army. So here comes my call for integrity and being true to the craft.

Will I apply for a senior position? By the way, I have seven years under my belt. And yes, I might land the job. But I will have holes in my skills. Now I would be working with people. Perhaps I would need some training.

I will be applying for a technical leadership program offered by the company, as a developer. I have the need (fear) to be competent if I would bear the title senior. When I have completed my training I would apply for a promotion.

Being a true senior developer comes with a huge emotional burden. You have the need for technical competence. You will not rest until you have the right (optimal?) architecture. You must learn and acquire knowledge. It is language-agnostic. You know when a solution or code doesn’t look right. You know (or are able to know) how to fix it. And you have the nightmare of living with bad code. If this does not happen to you, perhaps you are not yet senior.

Posted by: lrrp | October 7, 2017

Let Code Quality Guide You

Back in the 1990s when I was faced with multiple design choices, I’d have to code them up in multiple ways in order to figure out which one was best. This was time-consuming, and evaluating design choices was one of the hardest things for me.

But now I have a better approach, thanks to code qualities. If we agree that CLEAN code is good code, then we simply have to evaluate each design choice in terms of their code qualities and we’ll find the better options. I find that this is a fast way of evaluating design choices and now that I do it all the time, I can make these evaluations almost instantly.

Each code quality represents a key aspect of code. Cohesion means that code is more focused to deal with only one thing at a time, and it makes code much clearer and more straightforward to work with.Loose coupling means the code is more independent and easier to test in smaller units. Encapsulatedcode can’t be overwritten by something external so it’s more reliable. Assertive code is more performant and better organized. Code that is nonredundant costs less to maintain and extend.

Each code quality represents an important aspect in code that when missing can distort the object model and make code difficult to work with in the future.

These code qualities guide me. They are my teachers in the pursuit of understanding good code and I find that when I pay attention to these code qualities, I end up building code that’s more maintainable, more straightforward to work with, that’s in better alignment with the principles of good programming, and I even discovered design patterns.

Understandability in code is for us humans. Computers don’t care but we should. In order to maintain software, we have to understand it. We have to start by building software in such a way that it’s understandable. Architects don’t go off and just draw whatever they want on a blueprint without paying attention to the standards and practices of their industry. In the software industry, we need to establish good standards and practices that we can follow just like builders and architects follow.

Pay attention to code qualities that will help you more than anything else to stumble upon the right designs and have you use principles, patterns, and practices that support good software development. Let code qualities be your teacher and guide you to build code that continues to provide value into the future.

But don’t stop with code. If CLEAN is fundamental to the way we understand the world, then we should see it reflected everywhere—and we do. Good communication is cohesive. Healthy relationships are loosely coupled. Well-formed ideas are encapsulated. Healthy people are assertive. And unique ideas are nonredundant. These same code qualities are in the arts, in sciences—they’re everywhere because they help us understand the world around us. And because they’re everywhere, because they’re at the foundation of how we humans understand, we can and must imbue our software with these same qualities so that it can be understandable to us.

The good news is you don’t have to focus on all five code qualities. Just pick one or two that make the most sense to you and focus on those. What you’ll find is that as you improve one code quality, all the other code qualities will improve as well. They are not independent of each other. In fact, they are very much interrelated, like facets of the same gem.

Older Posts »