Arek Panek

Adding more people to a late project will speed things up? Odds are, probably not. In collaboration with Mirije Shefiti Kayis, Freelance Developer at German HubSpot Agency maka Agency GbR, we have a look at Brooks' Law! Brooks’ Law tells us that: Adding manpower to a late software project makes it later. Shouldn't more people help it move faster? Here's why not: - New team members require onboarding, taking time away from existing developers. - More people = more communication overhead. - Productivity can take a hit as focus shifts to integration instead of progress. Does that mean this is ALWAYS true? Not necessarily! In my experience, I've seen projects move towards "late" because one developer is trying to juggle parallel work streams. Instead of landing complete work, there's too much work in progress. In these situations, I have seen that you may be able to add members to help with the parallel work streams. But the points from Brooks' Law still need to be considered! Have you had success with adding more people to late projects? Or does it do more harm than good?

46

32 komentarze

🤓 It's not hard to hire a senior developer You're just not offering them what they want. I posted a survey in a Slack group with devs, asking this question: "Would you as a senior developer be open to change jobs NOW if you can work 100% remotely?" (Btw, many of them are social and will come to the office more often. They just want true flexibility and quality of life. And to be fair, they want to do what they love, which is coding, with the minimum amount of interruptions.) Although the dataset is small, the results are interesting. 💸 38 % are willing to take a lower salary if they can work remotely ❓ 17 % would join a company that has some financial uncertainty if they can work remotely 😑 41 % would take a job with a less exciting role, product and techstack if they can work remotely This is an incredible opportunity to hire some seriously great engineers. Especially if you: — Can't pay the highest salaries — Don't build spaceships or AI agents — Are located in a small town or rural area Are there tradeoffs and challenges with (some) remote team members? Of course. But I just can't understand why more companies are not willing to take some risk here. You might regret this when the market turns upwards again. 🕺🏻

105

43 komentarze

Many of us are working on exciting projects but only few succeed. During my attendance to two European Ruby conferences in June, I had the opportunity to ask top Ruby developers this crucial question: why do software projects fail? These are some great insights they shared on common pitfalls, unexpected challenges, and lessons learned from project failures . Watch my full video on my YouTube channel for more in-depth insights and discussions: youtube.com/@tillcarlos

6

The cost of poor quality is far higher than the cost of good #QA. At Quarry, we've seen firsthand how good QA can make or break a project. Why is QA so crucial? Let's break it down: Bugs are expensive. Catching them early? That's just smart business. User experience is everything. QA ensures your site works as smoothly as it looks. It's your reputation on the line. A glitchy site with delays is a fast track to lost customers. Security matters. QA helps catch vulnerabilities before the bad guys do. It saves time and cost in the long run. Trust us, fixing major issues post-launch is a hassle. QA isn't just about finding bugs. It's about ensuring your product meets your objectives and delights your users. But here's where it gets tricky: Many organizations undervalue QA. They see it as an extra cost rather than a necessary part of the process. We do things differently. At Quarry, QA is baked into our process. It's not an afterthought — it's a core part of how we deliver value. Have you ever launched a project without thorough testing? #QualityAssurance #WebDevelopment #BestPractices

1

It's quite eye-opening to learn that a lot of software development projects hit a snag right at the finish line. Did you know that a whopping 80% of the work actually happens in the last 20% of the project? This crucial stage often doesn't get the attention it deserves. Many development agencies find themselves struggling here because of poor planning and budget issues, which sadly leads to projects being abandoned prematurely. What starts as a 6-9 month journey can unexpectedly stretch into years or, even worse, never get completed.

18

3 komentarze

Hello. My service-as-a-product (SaaP) system will be available shortly. Artur Plugin and I are creating a system where you can check out pre-packaged services that are ready to go and already scripted. We have "discovery" meetup, after checkout, where we set the agenda for the specific product you have paid for. We hope, that these products will enjoy on-demand checkouts and treat our work as simply as ordering something from Amazon. We are building the MVP with a ring release. (If you want early access, please DM me, or send me an email). My Primary Services include: - Fractional CTO services - AMMERSE Training (with Certificates) In addition, we offer via our network, a range of additional services from professionals, ready to conduct your service-as-a-product on checkout. These include Web/UI/UX/Print/Video Editing and Design. Once we have perfected the reach and funnel, we will add more services from trusted providers. The services may be closed to selected subscribers, if capacity is stretched. How it works View the specific product, add to the cart, checkout, we connect, and fulfil the task. With an awesome refund policy in case something goes amiss, we have a fair way to build trust in execution. ---------- No purchase orders, estimations, dozens of emails, no contracts, no fuss. You pay, we do, don't like, we refund. (as always, terms and conditions apply) ---------- I urge you to get in early and let's build a modern, easy to use, professional service-as-a-product and get shit done.

9

1 komentarz

I didn't expect to say it this soon, but I'm enjoying working with TailwindCSS. I have used it for the AutoProject webapp. And with the help of LLMs, writing TailwindCSS has become quite easy. I often just describe the design I want and ask GPT to come up with the TailwindCSS for it. It works well, most of the times. Just a month or so ago, I talked about how I disliked Tailwind for its very long and verbose CSS classes. Every html element in your code will have a long list of class names to get the required design. I still dislike it, but after trying it more, I felt the productivity gain is worth it. Prior to this, I always preferred writing my own CSS because I wanted the design to be very unique and customized to me. In hindsight, that's still good but it reduced my shipping speed and added unnecessary "figuring it out" and "testing" overhead. I am continuing to write my personal CSS + Component library to factor in that uniqueness, but in the meantime, tailwind looks like an excellent tool to iterate very fast and build great looking UIs. With a stable Tailwind version 4 releasing soon, it looked like the right time to pick it up. In version 4, we can expect: - 10x faster builds - 35% smaller in size - Use of lightning CSS (I'm using this for my personal CSS library too!) - A custom parser that's 2X faster than PostCSS. (They literally designed new data structures to achieve this!) If you have been a skeptic like me, to Tailwind or CSS libraries in general, don't sleep on it. I'm thinking of migrating even TechFlix to TailwindCSS.

26

3 komentarze

I heard a story yesterday from a new friend about an unsuccessful software development project that lasted for 1.5 years. It is over 1.2M USD in total budget spent to date and still needs to be finished. How do I know it's not successful? The phrase that he said: "They will probably deliver it this Autumn, but it will be a very raw product that no one needs" So, what went wrong? First of all, the contractor's choice. They selected a large software development agency with offices in 10 countries, and that seemed trustworthy. What you can expect in this case? - You will get your product done with a good quality - You will pay 30-50% more than for small consultancies - You will have a chance to meet someone in person somewhere in your country - Your product will be finished (but you obviously need to pay for every hour worked). What's the downside except the price? One main thing: Your product will be your responsibility only. Was your idea bad? Well, you paid 1.5M to validate it; no one really cares if something built will never be used. In 2V Modules, we have a different approach, which I'm a big fan of. If we start working on something, we dive deep to understand what this product is for, what pains we are addressing, who the ICP is, and whether it was validated or not. Even if it's an "internal" product, there are still multiple ways of building it. It's not only about the business analysis stage, it's about finding the right solutions. So I think small teams are often a better fit because they actually CARE what they are building, not only HOW it is built.

11

2 komentarze

PHP is great and has made significant strides, especially in recent years. As a young developer, I was particularly fascinated by the large community. After working with .net / C# for 6 years now, I can say I really like it. Nevertheless, I have good PHP code in my libraries that I would like to use. In my attempt to homogenize my code base, i came across https://www.peachpie.io/ and can say after a short time it's great. My personal benefits: 📈 The performance of PHP code is improved. 🧓 Old, well-functioning classes/services can be reused in new .NET code. 🧑‍💻 As a developer, I reduce coding overhead from project/tech stack switching while I work.

8

It seems to me that traditional software development needs a heavy transformation. I've witnessed the limitations and disadvantages of classic software projects firsthand from my old jobs. ↓ 1. Crazy costs Traditional development can cost "millions". This is because teams of coders build everything "by hand". 2. Sluggish speed Even basic applications require months to develop using conventional methods. Most of the apps being built now can be developed up to 5x more efficiently using no-code. That's why in QikBuild, we pivoted to embracing the no-code approach. It allows us to reduce costs and boosts efficiency. It's like compressing years of progress into mere months. What’s your experience with no code? If none, what are your concerns?

46

MVPs and Prototypes are NOT the same thing, and it's sad how often they are  confused, because it’s costing companies millions of Euros — and it doesn’t need to. After 11+ years leading digital product and software development projects in Europe, I can tell you this with absolute certainty: ⭕  Understanding the difference is critical to your product's success. Here's what most people get wrong: ↳ They waste time over-engineering prototypes ↳ They launch MVPs that aren't actually viable ↳ They confuse stakeholder presentations with market validation ↳ They mix up concept testing with value delivery ↳ They collect the wrong type of feedback at the wrong time Here's what I ruthlessly focus on instead: Prototypes for TESTING  🗳️ Quick, dirty, throwaway experiments to validate concepts. If your prototype is pretty, you're doing it wrong. MVPs for REVENUE  💶 It must generate real sales from day one. If your MVP isn't generating value , it's not an MVP - it's just a fancy prototype. Feedback that MATTERS  🗣️ Early adopters should be fighting to become paying customers. If they're not, go back to the drawing board. I've seen countless products fail because teams didn't understand these distinctions and build full products that are not viable. Your prototype demonstrates promised value; your MVP delivers tangible value. There's no middle ground. Want to know if you're building the right thing? Simple test: Can your customers use it intuitively and quickly? Are they willing to pay for the product? If not, you're just playing with expensive mockups 🙅 Agree or disagree? I'd love to hear your experiences in the comments below 👇 #ProductDevelopment #MVP #DigitalTransformation

17

6 komentarzy

Before I go on holiday I try to: Do: - Prepare all the tickets I can to be ready for QA - Leave instructions for other devs on other tickets that need more work and should be delivered soon - Set autoreply in my work email Don't: - Merge any new gem or ruby updates at the last moment - Leave anything that would block others from doing their work - Promise to finish the ticket the first day after I'm back from holiday Did I forget anything? #RubyOnRails #Ruby #DevLife #softwareengineering #programming

4

4 komentarze

https://lnkd.in/dB5rsj9T ⚛️ React 19 is coming. Reading this article giving and idea how is orchestrated the bundling and the separation from server side components and client components thanks to Bun the new last trend bundler tool. 🤔 Even if the simplicity of the Bun tool is unexpected some doubts still need to be clarified: 😯 1. Why for resolving the server request it uses ".filter((file) => file.endsWith("page.tsx"))" If we are in a bundled project this tsx file shouldn't be exist. I think this is the core concept of the Extra chapter that the author has tried to explain. 😯 2. It seems there are 2 renderToPipeableStream 1 for RSC and 1 for client components. Isn't it? Why is it necessary? 😯 3. What kind of server configuration I need in production to serve SSR and RSC? I'm going to solve these points in my next steps but your help and thought are always appreciated so feel free to drop your messages here. Hoping you have found interesting this article #react #rsc #reac19 #ssr #exitement

3

When I arrived in London 12 years ago (!), the term "full-stack developer" wasn't on recruiters' lips. The question was always: "But where is your expertise?" Today, full-stack developers reportedly outnumber specialists - a dramatic shift, yet "full-stack" remains a somewhat nebulous term. (Pro tip: Ask a candidate what happens when you type a URL in a browser. The answer is often revealing.) This shift reflects the evolving needs of organisations and the rise of specific new technologies. True full-stack mastery is rare, but T-shaped professionals - those with broad knowledge and deep expertise in select areas - are invaluable. For SaaS startups, this trend has been particularly impactful: 🚀 Early-stage: Versatile, T-shaped developers are crucial. They effectively wear many hats, and cross-functional teams are built around skills rather than titles. 📈 Growth-stage: As the startup scales, the need for specialists emerges alongside your generalists. 🏢 Mature stage: A balanced team of specialists and versatile developers becomes essential for maintaining agility while deepening expertise where it matters most. Key takeaway: Sustain agility while focusing expertise where it counts. 💡 #FullStackDevelopment #StartupScaling

50

9 komentarzy

If your teeth hurt, would you go to a psychiatrist? No? Then read further, because I AM ABOUT TO BLOW YOUR MIND!!! Proper role separation in software development teams yields a huge productivity and quality boost. Traditional separation of roles and concerns sorts developers in two main blocks: backend and frontend. Let me say plainly: this is just wrong. There are a lot more layers, and the cutting lines should be put elsewhere. The first layer is design+HTML/CSS. Professionals working in this layer create and implement the UX, both the Interaction Design and the Visual Design. The ideal situation is achieved when the designer is free to code for fastest iteration cycles. The second layer is the API layer. This spans across the frontend and backend systems. Implementing a feature at this layer requires processing data, exposing it (securely) via the API, and then consuming this data in the frontend with the right business logic. The extremely tightly coupled integration between the two requires fast iteration, and having a (sometimes bureaucratic) separation here is the worst efficiency killer. Developers here are software engineers experts in concurrency, high-frequency/low-latency processing, and security. The second layer is ridiculously complex and should be treated with respect. The third layer is the background processing layer. This is the layer that makes sure that data is synchronized between all the data sources such as external ERPs, product catalogues, CMSes, etc. as well as our own local data stores (hopefully a normalized good DB like Postgres and a document DB like Elastic). The processing here is asynchronous and in the background, so there is not a lot of pressure on high frequency/low latency even though of course incremental concurrent processing of large data syncs such as to and from an ERP must be done intelligently or you might end up with latencies of 24h (the 90's called and want their ridiculous delays back). Data people (architects/engineers/scientists) are the ideal professionals to work on this layer. Finally, DevOps. Whenever DevOps is done by a backend engineer who "likes DevOps", a DevOps fairy falls from the sky. DevOps is a specialization and should be done by experts, especially if using the mega overkill of Kubernetes: old school Linux SysAdmins are Kings and Queens here, they know how to turn a 200k a year Kubernetes into a faster, simpler, safer, 30k a year Docker cluster.

12

You can't become the I HAVE NO IDEA WHAT I'M DOING dog as a professional identity. Don't embrace being a copy-pasta programmer whose chief skill is looking up shit on the internet. Treat it as part of a learning process to actually understand what's going on. Not merely as a shortcut to solve today's problems. If you never dig deeper, your competence will be stuck at the surface.

3

How Often Should We Meet? Finding the Sweet Spot In the tech world, excessive meetings are a clear sign of broken processes. Developers often feel frustrated with endless meetings, which seem to take up more time than actual work. This issue usually arises when management is either missing key roles like a technical specialist or analyst, or when a product owner is offloading their responsibilities. There are three main types of questions that dominate these meetings: - What have you done and what will you do next? - How would you approach this problem? - What should we do overall? A well-structured project team should consist of a product owner, an analyst, and a team lead or CTO. This trio is responsible for creating tasks, defining requirements, and setting deadlines. Once tasks are prepared, they’re handed off to the team for the sprint. Ideally, meetings should be minimal and focused on individual issues that arise during execution. Tasks should come with clear business logic and a rough technical outline, especially for complex tasks. Developers should simply take the task and execute it. The rise of excessive meetings is often due to ineffective management or a lack of budget for proper managerial roles—or sometimes just a need for idle chat. For example, on one project, a team of six developers plus a team lead was spending two hours a day in meetings, amounting to 280 hours a month. This time could be better spent on developing new features. My approach is different: the team lead handles most meetings, reducing them to once per sprint, totaling 16 hours per month. This frees up time for the team to focus on development, with just 10 additional hours allocated for troubleshooting throughout the month. The benefits to the client are clear: - More features delivered within the same budget. - Less time wasted on unnecessary discussions. - No bad advice from misaligned developers. The problem isn’t the number of meetings—it’s the flawed processes that require them. In well-organized environments, teams might only have one meeting per month, with tasks managed through a Task Tracking system. This can result in a shorter workday, with developers enjoying more free time and clients paying only for the hours worked. In another case, a project had a product owner who harshly criticized developers during meetings. Ironically, this led to more motivated coding, just to avoid further confrontations. In conclusion, meetings should align with the project’s needs. If your team is bogged down by excessive meetings, it’s time to reevaluate the underlying processes. Improving meetings' quality will lead to better productivity, more features, and happier teams.

66

4 komentarze

Software Development works in waves The Tech Development stages come in peaks through the years sometimes, everything looks great for companies other times, it's a bit more chaotic. --- This can lead to certain strains on your budget and planning. Namely, the issue of having idle resources is very common. --- Resources that can't be put to good use'll lead to things like Diminishing talent pools, less financing, and overall development issues. --- Understanding where these waves will peak, understanding your own company's cycles is important in order to be prepared for these events. Of course, there are other alternatives - if you're interested in hearing about them, be sure to let me know in the comments and keep following my videos.

15