Evan Light’s Post

Make it Work, Make it Right, Make it Fast In the realm of software development, there exists a mantra that encapsulates the essence of crafting quality software: "Make it work, make it right, make it fast." This three-step approach serves as an outline or framework for software development, emphasizing the importance of prioritizing functionality, correctness, and performance in the development process. Of course we want all projects to be elegantly designed, completely correct, easily maintainable and fast, cheap and profitable. But you don't get there in a single step and that's where these phases come to bear. First and foremost, "make it work" underscores the significance of delivering functional software that meets the intended requirements. This initial phase involves prototyping, coding, and iterative testing to ensure that the software performs its intended tasks reliably. This is not a POC, it's an MVP so there may be edge cases that are not yet covered. Once basic functionality is achieved, the focus shifts to "make it right." This phase involves refining the codebase, enhancing readability, and adhering to coding standards and best practices. Emphasis is placed on code hygiene, long term maintenance, ease of reading and extension. You'll also deal with those other edge cases and extend the functionality a bit here.. Finally, "make it fast" addresses the optimization of software performance. This entails identifying bottlenecks, optimizing algorithms, and improving resource utilization to enhance the speed and efficiency of the software. You can substitute words like "efficient, affordable, profitable, and scalable" for "fast" because this is the phase where you really focus on long term ownership and profitability. People have been through this cycle many times will tell you that you need to keep all three phases in mind throughout the project. And they're right. You should always be planning for making things right and fast even when doing the MVP. You just won't try to deliver all of the eventual design in your first delivery. If your initial design considered things like performance and scalability then this last phase is a tuning exercise. If you skipped over the design and design review, this last phase may require revisiting some of your architecture, which is likely to be a disappointment.

Estimating Tasks (Developer Perspective) Developers often don't want to make commitments about deliverables, mostly due to hesitancy about requirements and the uncertain nature of software development. While I agree with many arguments supporting that side, I also understand clients, who can't effectively manage their business when everything tends to fall under this category of "unknown". In the next post, I'll describe the client perspective, but let's start with the developer's side first. The complexity of even the simplest projects has grown tremendously over the last two decades, and it's still increasing. You no longer start with an HTML file where you just start typing, but you bootstrap an empty project with dozens of dependencies on other software, platforms, and infrastructure elements. It makes software more scalable, reusable, and ultimately easier to work with, but such complexity comes at a cost. Especially since things have become complicated on every single layer of a software developer's responsibility: codebase (with libraries and frameworks), managed services, cloud infrastructure, and more. ⭐️ It's hard to be responsible for areas outside of your control. With such an overhead of things that your software is dependent on, it's reasonable to consider it somewhat unpredictable. ⭐️ There's no such thing as "it's just a button". While some features might appear easy to build for a non-technical role, the effort needed to resolve all hidden complexity behind it might be more than initially expected. ⭐️ Clients sometimes make the mistake of assuming that requirements passed to the dev team are precise enough for everyone to understand them. Two sentences might not be sufficient input for providing an accurate estimate. ⭐️ Software is not the only reason for unknowns. It's not easy to give an estimate when adjusting a feature built by someone else, working on a functionality without domain expertise, or just not having enough experience to deliver a particular task. What would you add to that list? . . . #developers #software #softwaredevelopment #business

How to know the difference between when you can cut corners and when you absolutely mustn't cut corners (in software development)? Often times we know what the right, clean, well tested solution for our clients is. However, very often they don't have the budget nor the timeframe for it. And very often software development teams get asked if there is a way to make it faster or cheaper. This is where business and development "clash" and where it is important to have understanding for both, so you can make the right decisions. As a perquisite for this I'd say that it is necessary that the development team understands (at least in broad lines) the business needs and the business concepts of the client. The development team needs to bring to the table the understanding of what is "less important" and could be done "quick and dirty" and which parts of the system are crucial and need to be made clean and maintainable. I'll give two basic examples: 👉 A design is requiring a nice graph with an animated gauge meter showing a number ==> in development you just write a number in text. Yes, it loses UI quality, but the info you wanted to convey is there and you possibly saved 2h of work. This is an example of a GOOD SHORTCUT. 👉 You need a way to work with primary keys connecting your system to another system. You just assume that the combination of first name and last name can be used as a primary key. You check if it works for the current data you have and it does. Here you solved a complex problem in minutes, but are potentially opening yourself up for a lot bigger problem that will be complex (if not impossible) to solve once a second John Smith appears. This is an example of a BAD SHORTCUT. How does one know good shortcuts from bad ones? ✴ Knowing the business domain is extremely useful ✴ Knowing the technical concepts and the technical solution inside out is a must ✴ Discussing these decisions with the stakeholders makes it clear and open ✴ 20 years of experience in the software industry helps a bit How do you make these decisions? What are the worst ones you made? #softwaredevelopment

How to build your software fast? So let’s stop there! I would rather be an efficient and performant programmer that understands what they code and how to explain it rather than someone that codes to make things work. Hear me out. 1. You can’t guarantee the next developer’s threshold and adaptability Your current developer might be fast in delivery but your next might not be as good. Let’s be real some if not majority will job hop once their goals are achieved. The talent threshold differs from person to person in any industry, you cannot compare the strength of the bridge, by the length of the tree. I’ve heard over and over how some companies need to purge their current software after outsourcing this happens when you hire someone who only and I mean only prioritize delivery. Yes the main focus of the software is to start making money tomorrow but in the long run it should continue to make more in the future. 2. Scalability A programmer who knows what they code can whip up something fast. They know what it does and how it does it guaranteeing ease of communication between colleagues and workers and documentation generation. These types of programmers can make it easier for the next person to add-on,scale, optimize and debug software because of their organized code, clean architecture, robust structure. Poor unpragmatic code can lead to a lot of problems and causes more harm than good: • Hinders Scalability and drag due dates. • demoralized programmers and agitate investors. So how can we build our software faster? •Dedign first, draw later. Instead of just jumping into the editor. Focus on the primary objective and trace down the end product from there you csm connect the dots to form an efficient and performsnt software. •By knowing the language, and I don’t mean by heart just enough that you know how to design your software and what utilities or apis to use for each use case. •Sprint reviews, after each story or feature. Do reviews, the initial one will determine the whole architecture and structure of your software, they are the foundation that determines the project’s future. That’s sll for my ted talk today, stay safe. Drink coffee and happy coding!

People often talk about software development teams going faster. I don't think it's about speed. A lot of my engagements begin with a call or an email that includes something along the lines of "Our developers are too slow". Which usually turns out to actually mean "We need to get ideas into the market sooner". So it's not about writing software "faster". It's about delivering value sooner. And not necessarily more value. Just the same value. But sooner. So we can make money from it sooner. Or test our ideas more quickly. So that we spend less on the ideas that don't work. And in most cases, I find that part of the solution is for the software developers to take more care. Write more tests and create fewer defects. Slow down. Another part of the solution is to stop working on stuff for tomorrow. Create smaller releases, and release more often. And finally, keep the code habitable. So that the next feature can be added without increasing the code's overall complexity. - Slow down 🚶♀️ - Take more care 👷♀️ - Keep the code habitable 🌳 - Keep the code releasable 🚗 Magic.

The problem with thinking and talking of software development as "building software" and "software delivery" is that it misses the point and diminishes what we're doing... You can't "build" something until it's developed and you can't deliver something until it's built... The fact that we call the compilation and automated tests (and other checks) "the build pipeline" is the clue. That's the only time we're "building" the product. The rest of the time, were "developing" it. While we accept others (e.g. product managers) asking us to "build" (or worse, "deliver") a new feature, and use the same terminology ourselves, we're denying everyone else an appreciation of the skill, effort and exploration involved (so don't complain when they don't grok why something is going to take so long). We're also denying the company the opportunity to more quickly discover the product that customers really need rather than the product that someone believes customers want... If we are just "building" that new feature, it's done when a contract of "delivery" is met, not when we've achieved the intended outcome. It makes the ways of achieving the outcome in small increments and iterations harder to see because we're working towards that one new "feature" or worse, a whole product. At that point, we're all placing a much bigger bet, rather than a series of much smaller ones that allow us to discover the right path to making our new product or product capability a success.

Estimates in Software Development I see a common issue when it comes to asking for and communicating estimates. Most businesses run on time-bound plans—they want a certain level of predictability. The problem I notice is what gets considered an estimate. The obvious, common question from stakeholders (especially those without a software development background) is, “When will this be done?” or “How many days will that take?” This is a very detailed question, and most software professionals know it’s hard to pinpoint exact dates when doing creative, complex work. If you’re in that situation, take ownership by understanding what question really needs to be answered. Start by asking with genuine curiosity: “Sure, I’ll help you out. Could you let me know where this will be used so I can calibrate? Why do you need this estimate?” 💡 Dig until you know the actual purpose of the estimate. Here are some real-life examples: 👉🏻 “I’m working on stack ranking and need to know if this will take more or less time than these other projects.” In this case, all you need is a comparison. You could use T-Shirt estimates here since it’s just for prioritizing. 👉🏻 “We need it for quarterly planning. I want to know if we can deliver it in Q4.” Now, you know you’re estimating confidence in a Q4 delivery, not an exact date. 👉🏻 “Once you’re done, I can start designs for the next project.” Here, it’s a scheduling dependency. You might say, “You won’t block us; we have urgent technical updates we can do while waiting.” 👉🏻 “We’re in early talks with a client, and they asked for a cost estimate.” Here, it’s about giving an answer to the customer. Maybe you could use a past project: “It’s likely to be 90-110% of what we spent on Project XYZ last year. Just let them know we’ll get more precise once they’re more invested and we can do a proper discovery.” Get it? Answer the real questions—don’t settle for a surface-level understanding. You’ll be able to help more with less effort than if you were guessing detailed estimates. ______ 💚 Like and ♻️ re-post to help me reach wider audience. ➕ Follow me for more weekly content like this

"Walking on water and developing software from a specification are easy if both are frozen" - Edward V. Berard While core software components (think databases / load-balancers) are thought through up front and have a large stable specification, application software (think webpages / mobile apps / business logic) suffer from entropy. However, software development lifecycle works backwards from a specification and as this specification evolves so does the underlying software system. At times, the business needs leave little time to refactor systems and leaders have to choose between taking on tech debt or pushing out deliverables. This balance often leans towards taking on tech debt. Software engineers are not experts in managing chaos on their first day of the job, like any other discipline, we get wiser through experience. With delivery pressure, most season engineers succumb to short-term thinking which eventually leads to a "Big Ball of Mud" architecture. "Building Evolutionary Architectures" by Neal Ford / Rebecca Parsons / Patrick Kua argues we are not as helpless to change as it may seem. Making “evolvability” a first-class “-ility” in software projects and capturing "non-functional requirements" as "fitness functions" coupled with a combination of relatively rigid guardrails that allow a walled garden for incremental changes makes it easier to evolve without making software brittle and incurring tech debt. Reading this book was a watershed moment in my journey as software engineer and helped expand my mental model to include aspects like team composition, the stage in the product lifecycle, performance vs flexibility tradeoffs which ultimately helped me ensure I'm able to guide the team through their own journey while de-risking business outcomes. I'd highly recommend reading this book. What are some books / blogs that have influenced how to approach software design ? Book link : https://lnkd.in/g5Pd9_Hy Photo credits - O'Reilly

Programming faster doesn't really work; it needs to flow to production more smoothly with fewer waits and rework-rejection loops. Sometimes that means taking more time in development, and approaching the work differently. Eliminate the waits and returns, lower the WIP, and you'll see a big difference in delivery speed. Also, when people say 'the programmers need to go faster' they consider the entire software development process to be "the programmers" -- they don't know that only 3-6% of the time an item in "in development" is programming. They think it's all programming. People don't think about the queues and waits that they can't see; they focus on busyness instead.