Software Development’s Post

👨🏼💻Take your project schedule with a grain of salt and don’t be surprised when your project deviates. Examples of a schedule deviation are: 1️⃣Material from your supplier can arrive as non-conforming or their facility could be hit with a natural disaster causing them to stop work which flows down to create delays in your schedule. 2️⃣Your customer could request a change mid-project that may make you pause progress, reevaluate, and worse case, start over. 3️⃣The code your software team developed may not show an error until integrated late in the development. This may cause a backtrack, or a simple pause and rework.

In reality, it depends on the situation, but this statement is very underrated. Duplicated code in two places isn't bad by itself. Your priorities may be readability and speed of project delivery. Instead of looking for perfect pattern where to place that duplicated code.

Before coding, make sure you know the dependencies for your projects and get those in order. Start this process as early as possible because you never know how long it will take to resolve dependency issues. Especially if your dependencies are other teams or other services. You don't know what they are going through or what load they're currently dealing with. You need to get all that information as early as possible to help you create an accurate project timeline and an accurate timeline to get through your ticket. I recently faced a situation where I didn't manage my dependencies early on, and it nearly cost me my deadline. The dependency took much longer than expected, putting unnecessary pressure on the project. In engineering, always, always handle your dependencies early. It can save you a lot of headaches and keep your projects on track. ♻️ Repost if you found this valuable #SoftwareDevelopment • #ProjectManagement • #EngineeringBestPractices

One question I’ve spent a lot of time thinking about over the past few months is how to quickly assess if a software project is “good” and to get a high-level analysis that is useful without spending a ton of time and money on a comprehensive audit. I know this is a very subjective question with a lot of strong opinions…but at the end of the day, one can usually intuitively say “this sucks” or “this is ok” given the stage of the company in its lifecycle. Code review is an area where LLMs can be extremely helpful. Even though they can’t replace human architects and experts, they can give pretty good answers quickly which provide a useful and affordable method to frequently assess the state of your project. We’ve been working on a privacy-compliant product that can produce these high-level code audits very quickly and are now ready to beta test. If you are a non-technical founder (or technical, but not close to the day-to-day work of your code base), feel free to DM me and I’d love to provide you with some insight about your code base and a summary report. This also works very well for investment/M & A diligence if you need to quickly kick the tires on something before diving in more deeply.

Ask First, Code Later: The single, most important question! Developers should question project requirements rather than blindly implementing them. By asking 'why' and engaging in early discussions, they can uncover the true reasons behind requests, thereby leading to better solutions.

Exposure to large projects is overrated, to put it mildly.  You can write the most obfuscated code (repeat: the most obfuscated code) in large projects and then beat yourself in the chest for the participation in these large projects. Beside, your participation in a large project inevitably boils down to a certain limited number of tasks, which you have to program, as well as points of contact of your piece of code with the large project, for which you also have to take care of. So, first you have to make sure that your code functions as it is meant to be, for instance calculate distance, or whatever, and then you have to ensure the proper interaction of your code with the larger project, through the points of contact. If you participate in writing software for an airplane, does it mean that you have to keep track of the millions of lines of code? Of course not!! You are given a certain task as well and how your code should interact with the whole through the points of contact. Unless you are a project director something like that, who also alone can not keep track of the millions of lines of code, your task is just that: write perfect code for the task and take care of the proper interaction of your code with the whole, through the points of contact.

Ever made a project too complex? This can happen because of: 👈 Too many layers 👈 Mixed systems 👈 Poor tracking 👈 High mental load 👈 Doing it all in-house 👈 Rushed choices These slow work, cause bugs, and add tech debt. The cause? The Blue Dot Effect. This is when we see problems even when they aren’t there. As real issues go down, we see non-issues as problems. In coding, this means over-engineering and more complexity. How can we fix this? ✅ Clear limits: Keep the design simple. ✅ Track your project: Use tools like logs and metrics. ✅ Write it down: Document key choices and why. ✅ Focus on ease: Use tools that save time, like frameworks. ✅ Simple design: Only add what's needed, nothing more. ✅ Regular checks: Review the code to find extra steps. Focus on real problems, not fake ones, for smoother work. Found this helpful? Let me know by commenting and liking. Want more? Hit the 🔔 icon in my profile. Get notified of my next post.

🔹 Basic Plan 🔹   Ideal for: Code Reviews, Regular Fixes, Minor Updates, and Quality Enhancements. Need reliable support for minor improvements or want an expert to check your code? Our skilled engineers are online, ready to deliver top-notch quality and quick solutions whenever you need them. 💻🔧 ✨ Free Pre-Project Consulting ✨   Ready to kick off your project? Let’s connect — the consultation is on us!  In this free session, we’ll dive into your ideas and business goals to understand what you truly need. From there, we can provide a high-level project outline, complete with time and budget estimates. Already have a system but facing issues? We’re here to offer an honest, expert assessment. Start today by filling out our quick form — let’s make your project a success! 🚀

Simple. But, very often overlooked process #ProjectPlanning #ScheduleDevelopmentProcess #ProgramDevelopment

That’s a reason why estimations are not easy. A good tip is the t-shirt sizing. As humans we are not even great at guessing/estimating the t-shirt size of other people. However something that helps is getting examples/cases to compare. If I tell you I am a size M, J. a size L, M. a size S, and present you someone else, you probably manage to get their size pretty right. Therefore the tips is: - Execute and complete some projects. - After completing a few compare them against each other and assign “t-shirt size”, noting the time spent for their execution. - Then get new projects outlined, allows for brainstorming/breakdown/q&a. - Then try to compare them with the completed projects. - Go ahead and keep iterating the exercise with the new upcoming projects, and if you are lucky enough (yep you always need some good luck!) after a few iterations you start to get closer and closer between the estimations and the time and effort required But they are ESTIMATIONS not PREDICTIONS, so don’t expect them to be perfect in any way, shape or form. If we had a crystal ball 🔮 we would do another job, or be the most successful ever ever ever in our jobs😅