lukesan

Take a look at the works of Nicholas Felton http://feltron.com/ especially his reports of his years of personal data like http://feltron.com/FAR09.html These might give you ideas.

Simplicity is overrated. Experts often need more than the simple mantra 'do one thing well'. What is often needed for the user (novices and experts) is clarity. An unambiguous, clear interface is much better than a simple one. Even a simple interface can be confusing.

Thanks a lot.

Thank you for taking time and the effort to response. I appreciate that. I agree with the notion that you need to be free in choosing what you want to build. I like the notion of why, what, how in http://abbytheia.com/2016/02/07/why-what-how/

So we should be free in what we build but how should be influenced 1) by the what and 2) your team's experience. The why is key to know what to build. Without knowing why, pondering about what is pointless.

The constant potential for modification in an efficient manner is indeed a key of software development and very difficult to achieve in my experience. Besides concentrating on small things you need to watch and maintain your architecture of the system. Alas there is a point where you need to change the architecture. I think Martin Fowler was it what found out that at a certain point an architecture which was a right fit at the beginning cannot be maintained in a reasonable way and has to be stepped up. I would be interested what are the combination of practices that work for you is (even if they do not apply to my team). With pragmatism I refer to the artifact, the what, it needs to be a good fit to the problem and the users. And it is important to thing with what solution can "you get away with". Not in the way it is build but what does it achieve, the capability it provides. I have seen too many developers failing to fulfill requirements in time and budget because they stuck to the wording of the requirement. The requirement was a box for them, a prison. The problem behind the requirement is the one the developer needs to solve, not the requirement as is which is often wrong or unclear anyway. I have seen so much leverage here that I am putting most of my effort here: teaching to find and eliminate assumptions, getting to the problem, goals and needs of the user and the business, ...

The practices, the how. In my 15 years of professional development I tried many different practices and some are good for some situations, others feel like a waste of time and effort. I am yet on the search for a consistent set that fits me and my team. How do you consistently apply the practices? Only in projects? Or do you use katas or something like that?

Again thank you for discussing. I believe such honest and clear discussions are needed more than the many arguments about what is better or worse.

"maybe we can get away with X", or "maybe this will be good enough"

I think it is important to ponder about what is the best (efficient, best matching, ...) solution to the problems the user has. In your definition agility sounds like the absence of pragmatism.

Sounds great. Do you know any good resources for building a react application by progressive enhancement?

What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

But as with other things based on taste: the perception matters most, not a scientific double blind study. If my perception makes me prefer one coffee over the other, I am happy.

"To clarify, add detail" - E. Tufte

I don't think reduction only leads to perfection. If it would be, then our starting point must always be the right one. But in practice you start somewhere, reduce, move forward, add stuff, move sideways, try out and test. Sometimes you need to add stuff to make it clearer to your users.

Yes, in an iterative way. Maybe it is also agile :)

>What we really do is assess the validity and feasibility of what an user wants

Then why do software developers get no training in talking to users? In understanding them and make sense of what they tell us and what they really?

This to me is the biggest short coming of today's software 'engineering'

I would start with Refactoring by Martin Fowler. For me this is the quintessential book when it comes to basic software design principles. It introduces code smells and tells you step by step how and why to improve your code design