the concrete aspects of software design practice

[Paul Becker]

Hello all,

When you are designing a collection of modules, say for the development
of a library, how do you keep track of them all? (Do you draw diagrams?
Write up specifications? Talk with people (or ducks) about it?)

How do you ensure that you consider both the interface and
implementation parts of the design of each module? (When i get to
implementing, am i suddenly discovering that something i had assumed
would be simple, actually needs a bunch of design?)

How do you ensure that you consider the full space between the
user-facing part (functionality) of the library, and the lowest-level
tools (libraries) you have to work with? (large-scale version of the
last question)

I realize that some of this is "iteration in development" and the wisdom
that comes from exploration and experience -- but i'm thinking
specifically of how we handle these things, in concrete ways, as best we
can during design.

Thoughts?

thank you,

paul

[The Future of Programming]

Hello Paul

>> "how we handle these things, in concrete ways, as best we can during design"

Each project is a different story based on many factors like

1- Goal (Prototype/Production Ready/Research/Just Fun/etc.)

2- Scope: Small/Large

3- Contributors: Alone/Team

4- Previous Experience: Is this the first time to do such a project? or not?

5- Similar Projects (Related Work): What I learned from others

6- Known Use-Cases & Tests

7- Programming Paradigm

8- Programming Languages & Development Tools

9- Cost (Time/Money/etc.)

10- Project Spirit (What really matters - Values/Principles)

The most important lesson is to see the big picture for each project and get an answer for each of the previous points, and to know that it will be a partial answer in most cases and will grow along the time.

Say you will start a five-year project, while you have 20 years of experience, and you set a vision for this project and started working

After five years, you will have 25 years of experience including 5 years of related experience on this particular project, believe it or not believe, you will hope that you have a time machine to back in time and change a lot of things, something could be done using refactoring while other things could require a fresh restart.

Trying to know everything in advance is like saying (We will not learn anything new from this project so we can just do the right thing from the first time)

For some projects and based on points like (4) and (5), this could be done if the problem is already solved before (we know the solution)

Summary: 

(1) Don't try to have a complete design that includes all of the details, just try to have a complete vision and select/change/adapt the design based on practical needs and according to the vision.

(2) Different factors like (4,5,6) will grow/change during development and you have to manage this

(3) In programming and software development there are many ways to achieve your goals. This includes many right ways and many wrong ways. Don't think about problems like (I have to find the perfect/unique/best solution) - There are always better solutions and selecting/doing one of them is related to many things like (1,9,10).

(4) Successful programmers understand this and provide maintainable solution and know how to manage complexity and choose wisely between different solutions according to our limited knowledge.

I am not trying to provide a complete answer, I just sharing some hints.

Also, these are my opinions (I could be wrong or miss important things)

Greetings,

Mahmoud

[Venkat Dinavahi]

Hi Paul.

Bit of a brain dump but hope it helps!

I usually find it helpful to do something roughly like this:
1) Spend some time thinking up front about the design. If you are not making progress, stop and move to implementation. The implementation and design process are a back-and-forth. Each one informs the other so it's normal to go between them.

2) Get something working up and running. The reason for this is that it's hard to internalize all of the details of the requirements without actually building the thing. Keep the design in mind from (1) but use it as a guideline.

3) Once you have something working, you will almost always redraw the boundaries. I will go back to the design stage with my new knowledge and sketch out different boundaries. I will compare the different approaches. I might, for example, find that a particular boundary/interface results in a very tiny interface that hides a lot of complexity. You might even ask yourself how you would implement the thing with the knowledge of hindsight. Sometimes I will throw everything out if a simpler design occurs to me.

I find it helpful to simulate designs in my head. I might even visualize the different pieces of the system as though it's a machine with parts. Or I might visualize how I would use a particular abstraction. Doing so is faster than actually typing stuff out.

 

The other thing I find helpful is to pay close attention to yourself when you are using the abstractions. Do you keep mistyping something or forgetting to configure something? I will almost feel disgust when I feel something is too complicated to me. (Why do I have to think this batch_size?! Why can't API figure this out for me?!)

I think this is similar to usability testing when you observe someone struggle with a new product and use that to inform UX improvements to the product. The only difference is you will observe *yourself* struggle implementing some changes. Then you use those observations to improve your own design.

I think all of this is a long away of saying there's a tight cycle between designing something, implementing it, using it (observing the issues), and repeating. The best designs result when you switch between those regularly.
 

[Nikaa Haris]

Software plays a key role in the development of modern technologies and helps automate work processes. Today, it is important to choose reliable solutions that can be adapted to specific tasks. PerspectiveTeam offers an innovative approach to the creation and implementation of IT products tailored to business needs. This approach makes work more efficient and simplifies process management.

понедельник, 4 августа 2025 г. в 23:13:36 UTC+3, Venkat Dinavahi: