This may be true in the virtualised reality of pure software development, but I cannot see any realistic mechanism for this to work where the physical world is involved. For example, PCB design. There are certain constraints and rules that must be defined before the design can commence. Constraints that can't really be changed significantly during development without compromising all prior work.
You may argue that this is nothing to do with software development, but I develop firmware. This is often closely associated with the underlying hardware and is difficult to change in the event the starting principles are updated. In the same way that the foundations for a two bedroom bungalow are unlikely to be interchangeable with those needed for a multi-story carpark despite being identical abstractions.
I would be interested to hear if there is a better mechanism to address these issues using your approach. Perhaps you can direct me to an article that discusses such an approach.
When you have a team working on a payment processor, or an app focused on wealth management, it's true that the development team may or may not have experience in these areas, and it's not easy to establish everything from the beginning based solely on experience.
However, I agree with Allen that we can discover from the start and establish some guidelines or principles according to the area.
I can think of something to start with like:
------
Key Development Guidelines
1. Security-First
- Encrypt all sensitive data at rest and in transit.
- Support various payment actors (IRS, Mastercard, VISA, AMEX).
- Handle batch, near-real-time, and real-time processing reliably.
3. Data Management
- Ensure all entities (Merchant, Card, Transaction, etc.) are trackable.
- Build a data model for efficient reporting and compliance with regulations.
4. Scalability & Performance
- Design for high transaction volumes with scalable architecture.
- Combine monolithic core with microservices for flexibility.
5. Agile & Continuous Delivery
- Adopt Agile practices, with CI/CD pipelines for fast, secure releases.
6. Collaboration
- Ensure strong cross-functional teamwork with shared documentation and clear communication.
7. Compliance & Monitoring
- Enable audit-ready logging, meet regulatory standards, and set up robust monitoring from day one.
------
I've never done it, but I'd like to do something like this. It's a mini team Manifesto for that specific product. It can change, reflects some assumptions, allows us to start talking about important issues from the beginning.
I know requirement is the no-no word ;) But, I think this sometimes ignores certain company or geographic cultural aspects. I sometimes work with teams that, if things would not be formalized, almost nothing productive would happen. It even goes so far that it almost feels like a complete reset from one day to the next, making it seem as though yesterday's discussions never happened. Do you have any angle on this on how not using requirements would be better?
This may be true in the virtualised reality of pure software development, but I cannot see any realistic mechanism for this to work where the physical world is involved. For example, PCB design. There are certain constraints and rules that must be defined before the design can commence. Constraints that can't really be changed significantly during development without compromising all prior work.
You may argue that this is nothing to do with software development, but I develop firmware. This is often closely associated with the underlying hardware and is difficult to change in the event the starting principles are updated. In the same way that the foundations for a two bedroom bungalow are unlikely to be interchangeable with those needed for a multi-story carpark despite being identical abstractions.
I would be interested to hear if there is a better mechanism to address these issues using your approach. Perhaps you can direct me to an article that discusses such an approach.
When you have a team working on a payment processor, or an app focused on wealth management, it's true that the development team may or may not have experience in these areas, and it's not easy to establish everything from the beginning based solely on experience.
However, I agree with Allen that we can discover from the start and establish some guidelines or principles according to the area.
I can think of something to start with like:
------
Key Development Guidelines
1. Security-First
- Encrypt all sensitive data at rest and in transit.
- Implement PCI DSS compliance, strong authentication, and regular security audits.
2. Payment Ecosystem
- Support various payment actors (IRS, Mastercard, VISA, AMEX).
- Handle batch, near-real-time, and real-time processing reliably.
3. Data Management
- Ensure all entities (Merchant, Card, Transaction, etc.) are trackable.
- Build a data model for efficient reporting and compliance with regulations.
4. Scalability & Performance
- Design for high transaction volumes with scalable architecture.
- Combine monolithic core with microservices for flexibility.
5. Agile & Continuous Delivery
- Adopt Agile practices, with CI/CD pipelines for fast, secure releases.
6. Collaboration
- Ensure strong cross-functional teamwork with shared documentation and clear communication.
7. Compliance & Monitoring
- Enable audit-ready logging, meet regulatory standards, and set up robust monitoring from day one.
------
I've never done it, but I'd like to do something like this. It's a mini team Manifesto for that specific product. It can change, reflects some assumptions, allows us to start talking about important issues from the beginning.
I know requirement is the no-no word ;) But, I think this sometimes ignores certain company or geographic cultural aspects. I sometimes work with teams that, if things would not be formalized, almost nothing productive would happen. It even goes so far that it almost feels like a complete reset from one day to the next, making it seem as though yesterday's discussions never happened. Do you have any angle on this on how not using requirements would be better?