DEV Community: Loicniragire

Key Takeaways For A Successful Startup

Loicniragire — Fri, 22 Nov 2019 03:51:15 +0000

I've spent the last two years working for a software startup company and have learned a great deal about what goes into such a venture. It's allowed me the opportunity to study and appreciate great leaders in the Tech industry - people such as Steve Jobs, Elon Musk and so on. In this short essay, I want to dive into my three takeaways from this journey thus far.

Culture means everything and should be thoughtfully crafted every day. Sure sounds like a cliche but let me expand on that a bit. A startup takes a lot of work and dedication from the entire team to get off the ground. If your CTO has the vision but developers are not fully engaged, chances are this will likely fail. Nothing of significant value and size will get accomplished from a bunch of folks working 9 to 5. It takes a certain culture and leadership to give this mindset established. Morale has to stream down and throughout the entire company daily.
Get rid of titles. They create egos more than anything. Startups tend to be full of meaningless titles that no one can explain. From vice presidents to chiefs and so on. Just confusion. Keep it simple and have people work together on what they are best at. Eventually, people will find where they fit best without forcing a title on them. What they can contribute to or perhaps what they want to stay informed about. Each individual should feel a sense of ownership for the entire process. Titles and departments just add barriers within the company and prevent the creativity and collaborative spirit needed to succeed in this environment. It sounds chaos, but its an organized type of chaos.
You need leaders, not managers. Most managers out there are mostly concerned with keeping the boss happy so they can earn their next badge. These are not the individuals you need around. Managers create workers and workers ought to be your worst enemies. How do I define a worker? Folks who sit around waiting for their next assignment. 9-5 folks with zero motivation besides the paycheck and the weekend. You get the idea. Leaders empower others through a sense of ownership and responsibility while fostering the next batch of leaders.

Is it SOA or the New Spaghetti World?

Loicniragire — Mon, 11 Nov 2019 20:17:35 +0000

As developers, we love to twist and turn the greatest concepts to ever surface our world. For certain, there is nothing wrong with that and it is how you learn and grow. Take Service Oriented Architecture, for instance, a great idea, right? Yes of course. Until you see it implemented. How about Object-Oriented? Great concept, right? I guess you know where I’m going with this. Most recently I’ve been contemplating SOA in its various implementations – more specifically through Microservices. Who doesn’t love Microservices? Like most great ideas, if not well understood and thought out properly, the result is often worse than anticipated. In this short article, we will look at the spaghetti code done in the name of SOA.

The most lacking tool in most software development teams out there is not the right technology. Most technology stacks in use today will sufficiently get the job well done. It’s mostly a matter of taste and other factors but rarely the ability to get the job done. Discipline, however, that we don’t have much of. Often, new concepts are not all that new after all. Why did we go from Services to Micro-services? Well, "Microservices* are services done well. Better yet, why services to begin with? Loose coupling? Easy to deploy and test? Maintenance? Nothing new here. Discipline is more important than whatever architectural style your team implements. No language or style will prevent you from writing shitty code. I guess we can say that architecture is more about people than technology.

Is your SOA implementation more like our good old spaghetti friend? There is a thin line between, and this is centered around the concept of the “service consumer” and “service provider”. Typically, to help SOA systems achieve loose coupling, the service consumer does not ask for a specific service from the service provider. The bus and repository building blocks are responsible for communication performance when the service is called. A simplified model can, of course, be realized by bypassing this communication block and soon or later you will find your organization in a spider web of services – time to welcome back our spaghetti friend. A bunch of services all calling left and right to accomplish a simple task. Dependencies that only get worse as your application grows. Not only is this such a bad dependency problem to have, but it also impedes productivity as your team grows and more services go up. One must become intimately familiar with a huge landscape of services to get up and running. SOA is complex to achieve for most organizations despite what most architects would confess to. Half-baked implementations are even worse, but is Monolithic the only alternative? One would hope not but whatever the answer to this is for your organization, discipline is the most important ingredient – the basis of any successful architectural style within your organization.

A "Built To Throw Away" Mindset in Software Development

Loicniragire — Thu, 17 Oct 2019 20:00:37 +0000

Let’s discuss your production code. Yes, all that junk you’ve been writing and currently sitting in production. We've all contributed to some of that and there is no shame to be had about it. Perhaps it was the best you could do at the time with what you knew. Maybe the technology simply wasn't there. Its all lessons learned even though some of us may like to pretend that this does not apply to them. They've crafted procedures and protocols in place designed to prevent this exact problem. Weeks are spent on sizable design documents, UML diagrams, and all the bells and whistles that go with that. Everything is accounted for before coding takes place. With the premise that, by the time the associated piece of code is done, it is as solid as it can get. Built to last we should say. Except that it's not what the client wants by then.

Besides the fact that these documents have no profound value, any team out there on a mission to build tanks or bulled proof code needs to reevaluate their basics. Software is like any other living thing. It's there to serve a purpose within a given set of constraints. It should be allowed room to grow and change. This may sound mundane but it has profound implications on your speed of delivery and simplicity. Please note that I'm not promoting some type of careless practice with endless refactoring. I'm softening your fear of change and advocating pragmatic solutions. No amount of design and documentation will foresee business needs. Be open to modifying your code as constraints and time allow. This should be expected and your system should be designed as such by segregating fundamental business rules from external dependencies.

With a "built to throw away" mindset, dependencies are minimized and responsibilities managed. More importantly, developers welcome change with open arms as this can be achieved in small increments without having to carve out an extended time dedicated to refactoring. No single module, class or function is considered irreplaceable. In this mindset, progress can be better evaluated as a function of how much code you threw away than how much you've added. Any portion thrown away means you've understood the problem a bit better. This is progress.

An Improved Software Development Workflow

Loicniragire — Fri, 11 Oct 2019 05:30:12 +0000

Increase throughput
Reduce single points of failure
Maximize individual productivity
Allow room for developers of all levels

Principals outlined below are aimed at increasing productivity within a small software development team – 10 to 15 developers. Although applicable in large environments, they result from a direct observation within a small setting. Why another workflow? Frankly agile is a bit cumbersome to get right. Meanwhile waterfall is not suitable in today’s market – especially in a startup environment.

PRINCIPAL 1 – ABSTRACT OUT PROJECT INFORMATION FROM TASKS

Do not have developers tied to a project. Project details belong at the business and architectural level. It is the role of the architect to devise how each project is to be realized within the infrastructure. With the help of senior developers and business analysts, projects should be divided into sets of tasks that can be completed independently. Thus, developers should mainly focus on completing these tasks – irrespective of the project they are associated with. This increases velocity and reduces single points of failure. Not to mention, new team members are productive on day one – regardless of their level. While talking about "task", no single task shall exceed a day’s worth of work. It makes code management a nightmare the long these get. While a single developer solely delivering a huge project may seem productive, it’s a liability to the team in the long run.

PRINCIPAL 2 – ARCHITECTURE OVER DETAILS

Do not define tasks before architecture. Contrary to common misunderstanding, software architecture is a dynamic structure - far from static. A considerable effort is needed as new functionalities or constraints are added to the system. Your architecture should never learn about new functionality from ongoing tasks. Architecture is about boundaries and flow. These should remain flexible over the course of your software and dictate the shape of your tasks.

PRINCIPAL 3 – MEASURE

Your Software solution lives and dies by the accuracy of your estimation – or lack of. If you can’t tell how it takes your team to complete a set of requirements within a reasonable range, it won’t take long before your competitor takes over. The ability to measure progress is very crucial. The challenge is always maintaining a high throughput without burnout. Meanwhile, most teams couldn’t tell you their velocity. Charge your team with a sizeable bucket of tasks and let them organize themselves to get the work done within your time constraint. This approach increases team morale and allows developers to work closely.

What Darwin Understood - Classification

Loicniragire — Thu, 04 Oct 2018 13:52:15 +0000

Most likely the name Charles Darwin rings a bell somewhere in your memory – perhaps from your high school biology. He was an English Biologist best known for his theory of natural selection. As a computing professional, I do share an appreciation for his approach to problem-solving through classification. I would like to draw similarities between this concept as it relates to software development. Classification provides a frame of reference and allows us to reason about our applications in a broader sense. This is exactly what a good software architecture aims for.

Software architecture is concerned with drawing boundaries and crafting relations among them. In other words, each block of code is carefully be placed within a bounded area. Moreover, these areas are designated based on their problem categorization. So, in the end, we are really dealing with a categorization problem and providing facilities to address specific sub-problems within those categories. Important to note here is that other fields, such as Mathematics, tend to have a similar approach whereas problems are addressed through a certain frame of reference. For instance, we can reason through a given problem as an Algebraic problem or Geometric problem and so forth. A frame of reference guides our decisions based on existing knowledge in that domain and provided facilities in our infrastructure.

A good architecture facilitates greater reusability by providing clean categorization – an abstraction of some sort. The further apart components are, the less likely they share any reusable code. The opposite can be said for components in close proximity. This is even more so for items placed in a similar category. What does this all mean? We address the general problem first, therefore providing facilities to describe our specific needs. Thus, categories emerge as more general problems are solved, and patterns are forged. So what problems are you solving – category? What other problems are you familiar with in that category? Can your problem be framed in a different category? It all boils down to classification and your system should be expressive in terms of the types of problems it addresses.

Software Architecture Demystified

Loicniragire — Wed, 05 Sep 2018 15:51:02 +0000

Software architecture is one of the most difficult technical discussion among fellow developers. Simply because there is no right or wrong answer in most cases. It seems to always depend. What's the best way to architect a client-server application to handle millions of live transactions with zero downtime? Ok, I hope the answer is clear in this case; it depends. What I want to discuss in this article is a generalized approach I've recently been using to access software architecture quality. Its all about namespaces and references.

Architecture is about drawing boxes around code blocks and adding lines to connect them. Its quality is determined by those connections. In programming terms, these boxes are typically referred to as namespaces or packages depending on the language in use. Then, of course, we create connectors by adding references. When building enterprise level applications, this I have found to be very crucial. The act of designing namespaces and their corresponding references is what I call software architecture.

So how do you draw these lines, you may wonder. I tend to think about it by looking at what to keep out with the goal of holding my connectors at minimal. Another characteristic I use is grouping code block by their anticipated change frequency. Things that change very frequently are isolated from those that tend to remain stable. Also, those that change for related reasons are kept in proximity. At the end of the day, it all depends but this I highly encourage you to bear in mind.

Who is Who?

Loicniragire — Wed, 27 Dec 2017 18:28:02 +0000

I once had a fellow colleague who loved photography just like myself and we used to have numerous conversations about lighting and all sorts of things that photographers talk about. Then one day I showed him an image that I had taken and told him that it reminded me of Garry Winogrand and to my surprise, he didn't know whom Garry Winogrand was. Ok, so maybe Garry is not that relevant to his type of shoot – I thought to myself. I continued. Well, since you’re a fashion type of photographer, you must know Richard Avedon or Mario Testino then? Well, you guessed it; he didn't have a clue either. Then it occurred to me, how relevant is the historical aspect of your craft? Moreover, can you be of a significant value in your field without regard to its history?

I will make a bet for instance, that no Mathematician out there can say that they never heard of Paul Erdos. If such a Mathematician existed, his/her alma mater ought to be discredited. It is absurd that one can do any significant work in any field without regard to its history, which is usually full of a number of giants. Now let's talk Computer Science and programming in general. How many giants can you name and what were their contributions? Does the name; Ward Cunningham, Martin Fowler, Alan Turing, Charles Babbage or Donald Knuth, ring a bell?

The point I’m making here is that as professionals, we need to make an effort to be familiar with the type of work that other colleagues are producing. What problems are being worked on? What are some of the advancements being made? How would you solve such problems differently? And who is doing what? These are not trivial things but often overlooked. So maybe you can say that this is academic talk, which is partially true and doesn’t dismiss my point. It's crucial to be intimate with your surrounding and community in an effort to make a contribution. Welcome to the Computer Science community!

P.S - This is probably of less significance if all you care about or want is a job. In which case it's sad.

What’s the architecture of your system?

Loicniragire — Thu, 21 Dec 2017 16:42:18 +0000

I once had an interesting debate with fellow developers over a software performance concern, which prompted us to revisit our architecture. Some argued that we needed a new architecture and indeed some of that work was underway. I had raised a few concerns over some of the architectural decisions that had been made in the past when I first joined the team but for entirely different issues. My particular concerns centered on testability. More precisely, it was practically impossible to test the system without having everything connected. From the UI down to the database – everything had to be running.

The first architectural decision made was Angular. This clearly struck a chord in my spine as I wrestle the idea. I thought to myself, Angular is a detail. Moreover, a detail that ought to remain hidden from an architectural perspective. The architecture of a system shouldn’t deal with how it is delivered – in my view at least. It is almost like describing the architecture of a house by the types of bricks and cement used. To architect a system is to carefully draw boundaries around the various components that make up that system and connect them in a thoughtful manner, i.e manage dependencies, without revealing the details. The delivery mechanism is a detail.

But what about agile, you may ask? Didn't we abandon the idea of big upfront designs? Is this what I'm suggesting? The answer, of course, is no. Good architecture is revealed slowly over time as the system grows. It is not something that you and I can craft over the weekend and be set for the remained of the system's lifetime, but rather something fragile - Hence the idea of keeping details hidden. I find it helpful to think of what to keep out rather than what to include when dealing with architectural design. The more I can keep out, the better.

Why you should save the UI for last

Loicniragire — Thu, 24 Aug 2017 18:24:11 +0000

A very common practice in our industry is to first build the UI and tie in the back-end thereafter. The argument, for the most part, has been that the end-user gets more involved from the start with this approach and thus it gives us confidence that we are indeed building the right product. One major downfall I've realized with this approach is that we tend to end-up with a poor domain layer or lack of it for that matter. Since we are so focused on feeding data into our shiny UI. Here is a quick example to illustrate my point. Decouple the UI and the data layer from your application and see how much can be reasoned about with what's left. In other words, when all the bells and whistles are stripped off, what do you have left? How rich is your domain or what's your domain for that matter? What is your application about and how apparent is that in your code?

Ok, so maybe you can make a point that there is such a thing as a two-layered application and that not everything needs to be domain driven. Point taken. The most compelling reason I've seen for thriving toward a rich domain is that it's easy to test and reason about your application. I find it extremely helpful to think of my application as serving use cases rather than serving data. Huge difference. And what a better place to exercise your use cases than through a rich domain.

So what's a rich domain? I think of it as a layer that speaks my business domain and expresses allowed use cases. How rich it is, depends on how versed it is. Therefore, next time you find yourself designing user interfaces prior to expressing use cases to be served, my suggestion is to start from the latter and walk your way up. Let your UI plug into your domain.

On code readability in object-oriented languages

Loicniragire — Fri, 09 Jun 2017 18:39:50 +0000

Writing code, as in many other forms of communication, comes with a challenge of clearly expressing thoughts and ideas into a limited set of words. Quite often we envision the end-goal but the process of translating that vision into words does not always lend itself nicely. Moreover, it gets more complicated when consideration is given to not only what was communicated but how it was conveyed as well. In this essay, we explore ways object oriented languages have addressed this challenge and how developers can leverage these building blocks to increase readability of their code.

Before we get started, note that we specifically referred to programming as a communication form. Take a minute to let this sink in, because it’s going to be very important moving forward. Back…? Good. Now, this communication takes place among three parties; there are the original programmer, the machine, and the future programmer. As you can probably figure already, most complications will arise from the “future programmer aspect of this communication triangle and more often this is ignored completely. Just in case you are not totally onboard with this third party, suffice to note that even the “future you can be regarded as a third party!

Now that we have the basics covered, it is time to briefly look at what constitutes an effective communicator. This is a broad subject itself so we only offer a small glimpse but you are welcome to read more on your own. To quote the master of rhetoric, Aristotle, to be an effective communicator you have to “Tell them what you are going to tell them, tell them and tell them what you just told them”.

If you are starting to wonder how this all relates to programming, ask yourself this; what do we or should we be communicating in programming? We’ve already established that it’s a communication form. As ridiculous or simple it may sound, it is imperative to understand this if we are going to be effective at it. As an example, suppose you encounter the following definition of function foo:

Public int foo(int a, int b)

What have I communicated to you? Ok, you may say, function foo takes two integers and returns an integer. If that were all that was given to you, would you consider it effective? To a machine this is sufficient but what about the future programmer? Hint; recall that we are in an object-oriented language here, therefore, there is a thing called "state". So the short answer is no. The above snippet fails to clearly communicate its intent. More important than the details of how a specific task is accomplished, the intent is the thing we should strive to communicate at all levels.

So then, where and how should intent be communicated? The obvious location is in the comment section, as most of you would agree. But what should we put there? Contrary to popular practice, for those who comment their code, I argue that less is more. What do I mean? It is often advised to put as much information as you can think of in the comment section with the idea that over-communicating is better than under-communicating. While this is sometimes true, it also highlights a deficiency. We don't know what to say so we say everything and you sort it out as you see fit. The trick here is to go for less. If more is needed, perhaps the functionality is too broad or we are getting into the how. Recall the quote from Aristotle, so basically state what a particular piece of code is intended to do, any pre-conditions expected and what effects such functionality has on the object’s state – i.e post-condition.
Ex:

///Intent:
///Pre-condition:
///Post-condition:
public int foo(int a, int b);

The idea of communicating intent is that one should be able to follow your code, without ever stepping into definitions. This applies at the module, class and function level.

The second location for communicating intent is in naming. This is without a bought one of the hardest problems in programming and in Computer Science in general. Therefore all we can say is try your best to keep it meaningful! This serves to highlight the importance of a comment section as described above. Naming itself is not reliable enough to communicate our intent no matter how clever the name seems.

The last and most unappreciated location to place our intent is in unit tests. Sure, a unit test is meant to confirm that a piece of code accomplishes what it was set out to do, you may say. This is an important reassurance to communicate to your “future programmer and it serves to keep the integrity of the original intent. Additionally, what makes it absolutely indispensable is that it is executable. Therefore we are able to change how a particular functionality is achieved and be confident that the intent is still intact. Surprisingly, it is also the case that unit testing strengths naming and commenting.

So what constitutes a readable code? We discussed the importance of looking at programming as a communication form among three parties where "intent" is the most important piece of information to be communicated. There are three places where this intent can be stated; namely in the comment section, naming, and unit testing. When it comes to commenting, we also urged the programmer to strive for less as opposed to over-communicating. A readable code communicates its intent over approach. In the case of object-oriented languages, this is achieved with the proper use of classes.

Lazy – Exploiting a New Programming Paradigm

Loicniragire — Thu, 27 Apr 2017 18:36:26 +0000

Should developers adopt habits of their compilers? In the world of modern programming languages, a new paradigm of laziness has emerged. In this essay, we exploit what this means at a slightly higher level and see what implications could be brought forth in terms of programmer’s attitude. Just to give a clarification about what laziness we are referring to, suffice to say that it’s not about programmers being lazy but rather the language itself – So if your language is lazy, what would being a lazy programmer look like?

For those familiar with the C# compiler, words such as “Just-in-time compiler” or “Lazy loading” should ring a bell. I should add that this is not only pertaining to the C# and .Net folks, just an example. Also to be noted, what I’m interested in here is not another torture explanation of how these compilers accomplish those tasks or the design of such features. But rather, what implications, if any, should these features carry to the developer’s mindset. Ok, so that's a bit handful. Allow me to expand a little more.

Perhaps you may be scratching your head by now, wondering where this is going. Am I really suggesting that programmers adopt “Laziness” from their compilers? To your surprise, the short answer is yes. So how would this be productive? You may ask. After all, you are in the business of shipping working solutions to your costumers on time and within budget. Let us exploit these questions below.

Lazy. A lazy programmer implements the bare minimum in the simplest terms possible to get a working solution. Quite often, you find complicated solutions involving a gazillion third party references and complex notions to a business problem that could have been solved using excel spreadsheet for instance. Or, my favorite one, optimizing solutions that command no optimization. Being lazy in this instance, forces the programmer to dig deeper into the problem itself and consider all aspects surrounding the problem at hand before writing a single line of code.

A lazy programmer procrastinates and has no problem throwing away lines of code. This is a good thing. Have you ever met one of those programmers with an attachment to their code to the point of madness? At times it may even seem though as they are willing to go as far as inventing non-existing business problems just to keep their code around. Being able to throw away your lines of code implies that the software is so modularized to the point where new ideas can be realized without affecting the whole system.

So should you adopt laziness as a programmer? Absolutely. I hate to say think before you write, but in a sense, that's the point. Learning to distinguish business or customer’s needs versus programmer’s thirst for new tools and tricks can go a long way in satisfying your clients. Note that by any means, I'm not suggesting you stop expanding your skill set but rather understand the problem at hand before attempting to solve it. More importantly, prefer simpler solutions to complex ones. Take your time!