The most common issue in software is not how to build things but building things that are not useful. The same can be said of most companies - it is usually not how to do the thing but whether that thing is worth doing. This phenomenon is often called The Build Trap and is why we should prioritize Solutions > Systems. https://lnkd.in/euZCbhdT #softwareengineering #productmanagement
Hamilton Greene’s Post
More Relevant Posts
-
What keeps software running smoothly long after launch? It's the often-underappreciated art of maintenance. Let's break down the 4 essential types: Corrective: Think of this as software's routine check-up. Fixing bugs and glitches keeps things running as they should. Adaptive: The world changes, and so does your tech environment. Adaptive maintenance ensures your software stays compatible. Perfective: Good software gets better over time. This is where enhancements and new features come in, improving user experience and performance. Preventive: As the name suggests, this type focuses on catching potential issues before they become problems, leading to more stable software in the long run. #softwaremaintenance #softwarelifecycle
To view or add a comment, sign in
-
-
When building software DO NOT make product decisions on how your customers tell you they feel. Make product decisions based on how your customers behave. Seems like a subtle difference but its the difference between a good and great product.
To view or add a comment, sign in
-
By knowing the unique challenges in different areas of industry, Logicielity can adjust the product development process to the client’s specific needs and use our experience to shape any kind of product in an even better way. But, in general, the product discovery framework in our software development process includes the following stages: ✅Problem Discovery ✅Solution Discovery ✅Concept Implementation (Design and Development) ✅Concept Validation ✅Rollout (Commercial Availability) Our dedicated teams always work together to make your project delivery on time and successfully. For further information, you can contact us or visit our website (link in the comment). #productdevelopment #softwaredevelopment #productdiscovery #frameworks #processes
To view or add a comment, sign in
-
-
Cost saving in software development doesn't always mean cutting corners. In fact, it's usually about improving efficiency - and that means investing upfront. Here are three ways to save money in the long run: 1. Documentation: Detailed documentation leads to fewer misunderstandings, less rework, and fewer bugs, which saves time and money. 2. Scalable Architectures: Building scalable architectures prevents overprovisioning and underutilization of resources. 3. Automated Testing: Automation reduces the risk of human error and increases speed to market. Investing now can lead to significant cost savings in the future. Have you seen cost savings from any of these practices? Share your experiences below! #efficiency #softwaredevelopment #businessinvestment
To view or add a comment, sign in
-
As simple as that !
Helping software businesses trying to scale • Fractional CTO • Bringing Tech Strategy to Business Goals
Why is simple software not just a goal, but a necessity? In an age where complexity is often seen as a by-product of innovation, the art of keeping things simple in software development has never been more critical. Complex systems are harder to maintain, scale, and ultimately, deliver value. Focusing on simplicity from the outset: - Enhances the scalability of your software - Reduces maintenance costs - Improves team efficiency - Increases customer satisfaction The pursuit of simplification in your software architecture is not about taking shortcuts or compromising on functionality. It's about being deliberate in every line of code you write and every architecture decision you make to ensure that your software remains robust yet flexible, powerful yet intuitive. Let's champion simplicity in our software projects. It's time to shift our focus from how much we can add to how well what we have performs. What steps are you taking today to simplify your software?
To view or add a comment, sign in
-
The #1 property of good software: It does everything it was designed to do. The #2 property of good software: It's easy to change. Specifically, you a can add/remove/modify functionality in a minimum amount of time with a minimum amount of effort. This is absolutely critical for any company that wants to stay competitive in the market. Let's break it down. What does easy to change entail? - First, the software has to be SAFE to change. You can add features today without breaking yesterdays features by accident. If you can't, your software doesn't qualify as easy to change. Scrambling to fix broken features is high effort. This is where automated regression testing comes in. It scales and preserves your momentum far beyond manual testing. Essential for any team that wants to move fast. Without it, constant fire fighting will hold you back. - Second, the software has LOW COMPLEXITY. The architecture is simple & modular -- maybe at the cost of scalability -- anticipating changing requirements. No architecture is better than the wrong architecture. Instead, the system is primarily optimized for change. Its modules have low coupling - you can change one without affecting the other. It has high cohesion - the blast radius of change is small. Technical debt is kept at bay and the most obscure & hazardous pitfalls are dealt with as soon as possible. In short, avoid premature optimization. Optimization takes specialized architectural decisions, and architecture is hard to change. Let the requirements stabilize before you make irreversible decisions about it. -- Good software is easy to change. #softwareengineering
To view or add a comment, sign in
-
Does your software systemn consist of multiple internally built tools? Chances are that you do not you have a separate repository that combines these tools for a production release, and you really want to rethink this strategy. When building a software system, it is common practice to use specific versions of third party libraries. Your code and that of the external libraries become one: You deploy it as a whole. We tend not to use the same strategy for the multiple tools we built internally and form 1 solutions. These tend to be deployed separately. This is a dangerous strategy, because that new version from your colleagues, might not be compatible with the version that you have deployed. A better strategy is to to create a new repository that's responsible for the build and deployment and it contains all the tools that make up your solution. A deployment means that you deploy the system as a whole, and you can always roll back to a previous version in case things go haywire. You might not be able to add all dependencies to your deployment repository, so it is still VITAL to communicate across internal teams to discuss upcoming changes. There's a lot more to it, but it's a good starting point for discussion within your team.
To view or add a comment, sign in
-
-
Should we let software visually decay? This thought came out of some recent discussions I had regarding the problem around software modernization, as this is something still hard to get budget, understanding and time for. And most cases companies than start enormous modernization projects once it is actually to late.... One reason being is that software is an intangible asset and in contrast to physical assets where you can immediately see the lack of modernization and maintenance, in software it is not visible and for most people who are not an engineer not really understandable. But what if over time software would start to decay like physical assets? Buttons maybe not arranged in proper angles anymore, text boxes only accepting input after a second or third try, cracks on the screen or maybe some strange noises when submitting a form? Would this help to raise the case for modernization or would it just alienate business and IT even more? (Which is one of the core reasons why modernization is so hard, but about that some other time...) #software #modernization #businessandIT #IT #softwareevolution #technology #continuousimprovement #softwaredevelopment
To view or add a comment, sign in
-
Rapid and efficient product delivery has become a critical factor for business success. The ability to launch new features and updates regularly and reliably is essential to meet market demands and stay competitive. In this article, we will discuss various strategies and practices that can help you improve software delivery, optimizing processes and maximizing efficiency at every stage of the development lifecycle. #softwaredelivery #softwaredevelopment #strategies #practices https://lnkd.in/dEicQcQg
To view or add a comment, sign in
-
An important part of building reliable software is to make it a habit to simplify design and to remove cruft. I find that if I allow complexity to build up, it gets increasingly difficult to keep an evolving system stable. In other words, to build reliable software we have to manage unnecessary complexity well. #softwareengineering
To view or add a comment, sign in