A full sequence diagram conveys nothing to the reader that the code itself wouldn't. A full class diagram for any non-trivial system is a bird's nest. IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. One team tried to use it within their project. We used it for a while, having entire separate 'code' projects to maintain artifacts. Together was a UML-as-code tool, and I never saw how you could deploy a working system using it. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us)ģ) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defectsĤ) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months.ĥ) Things like CI/CD exist which would’ve made a 90s developers head spin. So to bring this full circle, what changed since UML’s heyday?ġ) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here)Ģ) Object Oriented programming hype has died down. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code.ģ) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers.Ĥ) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects:ġ) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersonsĢ) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. I got my start in a shop whose CTO was a big believer in UML. > Ernesto Garbarino says that UML was killed by decreasing standards among programmers: “Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).” But that's sad, because the value is there, just obfuscated. Given that I know a lot of the influencing methodologies, and I've even developed tools myself, if this now looks like crazy enterprise sales&consulting cash cow nonsense to me, then I can't be surprised if other effective software engineers are turned off by what they see. When I try to use particular models and views of UML myself, the documentation and tooling I find in the time available borders on unusable, and I end up improvising what I need. We've got a lot of people writing one-star Amazon Customer Reviews for a screwdriver, who've never seen a screwdriver used properly, and only know hammering.Ģ. Even before UML, there've always been people who used modeling tools without understanding them, there've always during OO era been people who really only wanted to see a class inheritance hierarchy, and knowing when to use the models and when to code or do other things is an art like much of the rest of software development. It seems that almost everyone commenting has seen only bad uses of UML. As someone who learned and used a lot of the methodologies before UML, and developed CASE tools for some of it, looking at discussions of UML are painful, for two reasons:ġ.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |