Ask HN: What are up-to-date methods for software development?
I know that waterfall and spiral are both old. I would like to know the more recent methods and its step-by-step guide. What is the best software for small projects?
7 comments
The best approach is dependent on the definition of "best", and for whom it's best, etc.
For example, in the last 10 years I've seen numerous companies I know switch to Scrum/Agile. They always seemed to have a worse result than before (bad software quality due to lack of long-term planning, lots more meetings and overhead than before). For example one company I'm aware of recently informed me they had to do a "huge refactoring" taking a whole day of the whole team, this was for a project that isn't even online yet, the project is maybe 6 months old. Surely this is a failure?
Why were they continuing to use it? I think Scrum really is "best", for the following definition of best:
- For the customers who are stating the requirements, if they make a huge mistake the person making the mistake could be fired. The only sure way to make sure a decision is not a mistake is not to make any big decision at all. Scrum promises you you don't have to plan out e.g. 6 month projects in full, only specify the stories in the next sprint in detail.
- For an agency billing by time, the more meetings there are, the more hours they can bill and the more money they can make. The worse the software quality is, the more refactoring is necessary, the more times you do things the more hours are billed.
So, for an agency selling to a large customer, Agile really is "best" for the participants personally.
It might not produce the best software, or the cheapest software, but that isn't what actually matters to the people involved.
For example, in the last 10 years I've seen numerous companies I know switch to Scrum/Agile. They always seemed to have a worse result than before (bad software quality due to lack of long-term planning, lots more meetings and overhead than before). For example one company I'm aware of recently informed me they had to do a "huge refactoring" taking a whole day of the whole team, this was for a project that isn't even online yet, the project is maybe 6 months old. Surely this is a failure?
Why were they continuing to use it? I think Scrum really is "best", for the following definition of best:
- For the customers who are stating the requirements, if they make a huge mistake the person making the mistake could be fired. The only sure way to make sure a decision is not a mistake is not to make any big decision at all. Scrum promises you you don't have to plan out e.g. 6 month projects in full, only specify the stories in the next sprint in detail.
- For an agency billing by time, the more meetings there are, the more hours they can bill and the more money they can make. The worse the software quality is, the more refactoring is necessary, the more times you do things the more hours are billed.
So, for an agency selling to a large customer, Agile really is "best" for the participants personally.
It might not produce the best software, or the cheapest software, but that isn't what actually matters to the people involved.
I strongly recommend ShapeUp (see details here https://basecamp.com/shapeup)
In very few words how we implement this:
- We have a small team (Designer, Product, FE, BE, Mobile, Devops) = total 4-5 people (not all features have needs for all components). The team can change from cycle to cycle, but in practice it stays more or less the same
- A cycle is defined as a period of 6 weeks where we do feature development. What we work on is decided by Design + Product with feedback from us. During the cycle we refine the scope to be able to ship the feature at the end of the cycle
- Followed by 2 weeks of CoolDown where we usually do refactoring or paying technical debt or small improvements or bug fixing. The Cooldown is driven by technical team and during it the product and design are there to support the technical team when needed
- Very important: At the end of the cycle what is not ready to ship will not be released and has great chances of not being picked up again as before every cycle starts there is an assessment about what is most important/valuable to work on.
For me this is the best combination between doing product progress and keeping the quality of our technical assets on a steady line.
Also I really like the ingredients of a Pitch and how to shape the work to be done in a cycle. It is - so far - truly the most flexibile and most team oriented approach. A nice balance between driving the product and keeping the team happy (where happy = technical advance + being involved in decision making, discovering themselves the scope and working on constraints + making progress).
In very few words how we implement this:
- We have a small team (Designer, Product, FE, BE, Mobile, Devops) = total 4-5 people (not all features have needs for all components). The team can change from cycle to cycle, but in practice it stays more or less the same
- A cycle is defined as a period of 6 weeks where we do feature development. What we work on is decided by Design + Product with feedback from us. During the cycle we refine the scope to be able to ship the feature at the end of the cycle
- Followed by 2 weeks of CoolDown where we usually do refactoring or paying technical debt or small improvements or bug fixing. The Cooldown is driven by technical team and during it the product and design are there to support the technical team when needed
- Very important: At the end of the cycle what is not ready to ship will not be released and has great chances of not being picked up again as before every cycle starts there is an assessment about what is most important/valuable to work on.
For me this is the best combination between doing product progress and keeping the quality of our technical assets on a steady line.
Also I really like the ingredients of a Pitch and how to shape the work to be done in a cycle. It is - so far - truly the most flexibile and most team oriented approach. A nice balance between driving the product and keeping the team happy (where happy = technical advance + being involved in decision making, discovering themselves the scope and working on constraints + making progress).
I want to second this this method. It also works great in a research setting. There, the cool down also allows reflection on the past few week to update expectations and goals for next cycle. While not following this method strictly, I've been cycling through my work like this for past 12 months.
The current hotness is "Agile". A government contractor friend of mine cynically calls it "Waterfall but with 1 week, rather than 1 year, deadlines". Atlassian[0] has a good guide to generally understand what it is I think:
As far as tools, any of the big git providers (GitHub, Atlassian, GitLab) generally cover most of your bases. That kind of stuff is referred to as DevOps.
[0] - https://www.atlassian.com/agile
As far as tools, any of the big git providers (GitHub, Atlassian, GitLab) generally cover most of your bases. That kind of stuff is referred to as DevOps.
[0] - https://www.atlassian.com/agile
Government (and government contractor) Agile is Waterfall-but-faster. In fact, often "Agile" is only applied within the development phase and they retain everything else Waterfall. It often looks like this:
Design phase - waterfall-styled, 3-12 months
Development phase - "Agile", but with sprints planned out for the next 36-60 months
Test phase - waterfall-styled, 3-36 months
Deployment phase - waterfall-styled, 3-120 months
They don't incorporate testing properly during the Scrum-based development phase (only some testing, too limited to really provide confidence). They then use their experience to say, "Agile is bullshit". And they're right, if you take their definition of Agile which is: What we did before but with finer-grained "planning" of the work for 5 years.
Design phase - waterfall-styled, 3-12 months
Development phase - "Agile", but with sprints planned out for the next 36-60 months
Test phase - waterfall-styled, 3-36 months
Deployment phase - waterfall-styled, 3-120 months
They don't incorporate testing properly during the Scrum-based development phase (only some testing, too limited to really provide confidence). They then use their experience to say, "Agile is bullshit". And they're right, if you take their definition of Agile which is: What we did before but with finer-grained "planning" of the work for 5 years.
The underlying layer is problem solving: digging deeper until you find the problems to solve. Then there's product and management. Then there is writing software and the skills inherent to it. Then there are the methodologies. Then there are the tools.
It is a combination of all these and more. You take one out, and you're developing for the wrong problem or one that does not exist. You take the other, and you take too long or do it. You take yet another, and you're making cool technology for its own sake. You take the other, and you're solving problems in the wrong order. You take another, and people are making different things than the one you're thinking about.
Depending on what you are trying to accomplish, you stress on one more than the others. It is a balancing act in which the weights and priorities change, assumptions change, landscape changes.
You can follow agile all you want, if you're in a brainstorming meeting where you haven't clearly defined the problem, the job to be done, and are instead talking about buttons and interfaces, the project will fail and not all the great code will save you. It is tricky especially if you are with a client and they're very into it and you have to focus everyone on problems.
You can have SWEBOK in your head, if you are too dogmatic about it you risk of missing the bigger picture, or a market.
You can wield GitHub, GitLab, and editors all you want, if it is your main concern you risk of spending way more time on their interfaces than thinking.
You can know all these, if you don't get out of your metaphorical room to confirm the problem exists, or lack interviewing skills to extract a problem, then the software will be a thought experiment with no usage.
What are you up to? Working on an idea?
It is a combination of all these and more. You take one out, and you're developing for the wrong problem or one that does not exist. You take the other, and you take too long or do it. You take yet another, and you're making cool technology for its own sake. You take the other, and you're solving problems in the wrong order. You take another, and people are making different things than the one you're thinking about.
Depending on what you are trying to accomplish, you stress on one more than the others. It is a balancing act in which the weights and priorities change, assumptions change, landscape changes.
You can follow agile all you want, if you're in a brainstorming meeting where you haven't clearly defined the problem, the job to be done, and are instead talking about buttons and interfaces, the project will fail and not all the great code will save you. It is tricky especially if you are with a client and they're very into it and you have to focus everyone on problems.
You can have SWEBOK in your head, if you are too dogmatic about it you risk of missing the bigger picture, or a market.
You can wield GitHub, GitLab, and editors all you want, if it is your main concern you risk of spending way more time on their interfaces than thinking.
You can know all these, if you don't get out of your metaphorical room to confirm the problem exists, or lack interviewing skills to extract a problem, then the software will be a thought experiment with no usage.
What are you up to? Working on an idea?
Can I suggest AABS? Anything Agile But Scrum