The Agile shop I currently work for treats UML as mandatory before any code is written. Then we proceed to ignore all designs until the next time someone has to look at the design doc again
Does anyone else find themselves performing a UML-like design phase, but with code?
I like to create classes/methods with little/no/mock implementation to see how it will fit together. If there's something where I'm not sure how it works (third party API/lib I've not used before) I'll get more granular with it.
There's tooling to produce diagrams from code if someone really wants it. But either way my design phase is now usable code.
That being said, I still have to admit this rarely survives contact with actual implementation. It just feels better.
Yeah this is sorely needed -- I did wonder why Martin Fowler was espousing this pretty out-of-touch viewpoint in 2023 when design is a major part of feature completion.
On average, I'd say we have much better design and UX now compared to 2004!
It is interesting to read perspectives from a past era to understand how we got to today’s status quo.
In my career I’ve encountered a lot of projects that have been designed to death; They start with good intentions to do things “right” and then hire a lot of people who do a lot of designs and documents and meetings and committees. Two years later, nothing is done because everyone is too busy designing and re-designing.
At the core of it all is the idea that if you’re not following all of these formal techniques and processes then you can’t possibly deliver anything good.
I think it has too much regimentation to be a good communication device, or even a good design specification. Labeled boxes, arrows, and sometimes color are more than sufficient for diagramming how a design works. The small details in a design doc are not going to stay the same when building the thing, so writing them down is just a waste of time.
(Personally, I’m a fan of doing less design, less documentation, and making the code as obvious as possible. It’s a lot of friction to have multiple sources of truth that have to be kept in correspondence with each other.)
UML was, at least partly, advertised as something that would make software developers obsolete. You just needed domain experts to wire up the right class diagrams, sequence diagrams, activity diagrams, etc., and it would output code that met the specifications. No developers needed!
Imagine you want to have a conversation with a colleague about how to approach a new project, but some smart-ass is constantly pestering you, forcing you to use a heavily formalized, technical language that requires you to put every idea into a well defined box. Caveats, questions and loosely defined entities, processes or relationships cannot be expressed.
Or "(2000)", actually, since it seems to all be a 2000 keynote which has been digitized. Probably a good time for a retrospective - 23 years ought to provide a lot of hindsight & commentary.
This is quite the classic from the days UML was used unironically.