6 ms·

My first real-world job in the industry was in a large-ish shop that worked as follows: Create a full-detail schematic of the system in version-controlled UML.

by m_fayer 11y ago

My first real-world job in the industry was in a large-ish shop that worked as follows: Create a full-detail schematic of the system in version-controlled UML. At some point, "deploy" the UML by printing it into a 4 cm-thick binder of paper, then distribute these binders to the head architects. Iterate on the UML until the architects are happy. (The architects spent many years trying to auto-generate code from the UML diagrams and have the results "fleshed out" by lowest-bidder consultants, though this never really worked. Their stated goal was to no longer have to write any code in house, but rather nothing but UML.) Begin implementing the system in house with auto-generated code from the binder-of-UML as a baseline, after the lowest-bidder consultants had failed. Quickly get into big fights between the coders-on-the-ground and management when it was found that the UML diagrams contained major architectural flaws and the UML-phase would not, actually, account for 80% of the project's duration and budget. Needless to say, more than half of the projects failed entirely. This experience nearly made me leave the industry, before I discovered that there was plenty of software being written in a saner way. This was more than a decade ago, but to this day, just seeing UML diagrams turns my stomach.

arethuza 11y ago
I had a similar experience about 12 years ago - turned out the company in question simply used their UML based methodology as a sales tool. Projects never actually worked that way in reality - what they said they did and what they actually did were completely different. Once I realised that the development process was actually perfectly OK and nobody actually looked at the UML I was fine.... ;-)
- henrik_w 11y ago
  I was developing SW in the 1990s (before XP, then Agile, become popular), and we were supposed to use UML, Rational Rose etc. However, that was how it was supposed to work, not how it actually worked. The biggest relief in starting to use XP was that the methodology described how we actually worked, not how we were supposed to work.
  - crdoconnor 11y ago
    I always thought the quality of rational rose itself was the best argument against UML. After all, that's probably what it was designed with.
    - julian_t 11y ago
      Oh my, I can so identify with this. I used to do product reviews for a magazine, and Rose was the only review software I decided not to keep. And I'd have felt bad giving it to anyone else. From that time on, any mention of Rose in a job description automatically disqualified it.
  - mml 11y ago
    I was on a big project in the early aughts (pure XP, pairing, tickets, stories, tests (40,000 of them at the end) etc), on which, we were contractually obliged to A. hire on at least 4 accenture consultants, and B. purchase 4 rational rose seats. We simply stuck the accenture clowns alone in a room with rational rose, and we never heard from them again (nor did we ever see any uml). Best case scenario.
jmartinpetersen 11y ago
I hope UML as blueprint (or even, shudder, UML as a programming language) now mostly lives on in the memory of those who suffered under it.
- SSLy 11y ago
  Unfortunately, I am having two mandatory courses that focus on it (it's a BSc CS programme).
  - jagger27 11y ago
    Carleton University? Christine?
    - ImNotAKompjoetr 11y ago
      could be anywhere, mine also has a mandatory course on it, including a lecturer that believes in the magic of auto-generated code from the UML tools.
  - SmellyGeekBoy 11y ago
    Wow, I remember studying UML in BSc CS nearly 10 years ago. I'd imagine it's much less relevant now than it was even then.
  - brianpgordon 11y ago
    Two courses that focus on it? What school is this?
gopowerranger 11y ago
Part of your story reminds me of the customer of the computer company I worked for that would, every week, print out sales and financial reports that ran for hundreds of pages and about as thick as you mention. The girl who ran the reports told me that the only people who ever looked at the reports were the sales guys who would flip to page 20 and look at the bottom line sales number. It was then filed away in the warehouse, never to be seen again.
- m_fayer 11y ago
  Back then, I found it strange that people would cheerfully exchange stories such as yours, stick Dilbert strips all over their offices, swap dailywtf links, and just carry on. I was never able to compartmentalize enough to be happy while also admitting that I live in some Kafkaesque version of Office Space. I remember being told by my seniors that I'll grow up and grow a thicker skin, and that I will accept that this is just how things work. Now, I'm happy to find out that that is not indeed how things HAVE to work, and I'm a lot happier and less conflicted. And now that we have many prominent examples of more functional and humane corporate and engineering cultures, I'm sad for all those people still toiling away in dilbert-land.
  - aklemm 11y ago
    What are your best examples on non-Dilbert-land cultures? I want to go to there.
    - jerf 11y ago
      Startups aren't Dilbert land. They literally can't afford it. They have their own pathologies, of course, but they aren't Dilbert pathologies. (And due to scale, if you are motivated, they are often, but not always, more amenable to fixing.) You can also look around for medium-sized places where software is the primary product; they can typically afford some Dilbertiness, but not too much, or they get eaten by somebody else. Depends on your tolerance, and on your ability to carve your own defensible niche out. But either way, the key is certainly to start looking. No, working in Dilbert is not inevitable, but you'll have to take positive action if you are stuck there now.
smoyer 11y ago
"Their stated goal was to no longer have to write any code in house, but rather nothing but UML" This goal was promoted heavily in the late '90s and early '00s. Some tools could supposedly "round-trip" between UML and code, but I never saw that actually work. As originally conceived, UML was supposed to foster communication and there are times when a UML diagram is the perfect means to communicate the intent. I tend to use sequence diagrams and ER diagrams the most (yes - I know ER diagrams aren't UML but they're roughly analogous to class diagrams and what we're usually trying to flesh out is the relationship between models). As an aside, there were/are graphical programming languages. I wrote a couple of Windows and Mac utilities in ProGraph [1] during the '90s. The ProGraph environment lives on as Marten [2] which I recently played with on Linux. It's not nearly as clean as I remember it being. [1] https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph [2] http://www.andescotia.com/products/marten/ http://www.andescotia.com/products/marten/
- nine_k 11y ago
  There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams. ER diagrams are super useful, too.
  - detaro 11y ago
    Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...
    - noxToken 11y ago
      It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that. The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png http://s18.postimg.org/gxfkjytft/diag.png You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML. Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.
pjc50 11y ago
In 2013 I encountered a major IC design company that still works in this way: spec -> complete English+diagrams description of all system components -> Verilog -> production.
- jpmoral 11y ago
  I left hardware engineering less than a year into my first job more than ten years ago. I'm curious, how is it supposed to work?
  - lfowles 11y ago
    Agile hardware sounds dauntingly expensive!
j03m1 11y ago
yes this. When I read the title and clicked the link, I thought, shouldn't this page just be blank?
sswaner 11y ago
I was involved with one of those UML -> Code systems back in the early 2000's. It was company called Nuevis. I had proposed a simple CMS to be written in ASP (or maybe Cold Fusion). We had a project plan, requirements and design documents and developers ready to start. Some architect said we would be the perfect use case to test this new technology. We met with them, licensed their system and began to make UML. After several weeks we started to generate code, but it wouldn't run. Several more weeks and we had running code, but were missing key functional requirements. We pulled the plug after 6 months. It turns out that UML class and state diagrams are just not robust enough to explain specific functional details. The system generated thousands of lines of code to do simple things. We ended up writing it ourselves in ASP, it took us about 3 weeks to code everything. Nuevis went out of business in the original dot-com bust.
ArkyBeagle 11y ago
I worked on at least one project that used ObjecTime, a predecessor to UML. You were coding in it, in a very ship-in-a-bottle way. The article completely ignores how state machine patterns are done in UML, which ( IMO ) is where you start to see some gain. This being said, just doing state machines in a non-OO way isn't exactly rocket surgery. It was tolerable. But changes were a bit expensive, and we kept a reference machine for builds, which was not very nice. The environment was hard to replicate - behind the scenes was a sandbox of Smalltalk and that was sort of ugly. We did a port to Rose, but Rose was not, frankly, as capable. What's funny-peculiar is - as described in your experience - the whole idea of "architects that can't code." At the very least there's apparently no market for tools to enable that.

by m_fayer 11y ago

arethuza 11y ago

I had a similar experience about 12 years ago - turned out the company in question simply used their UML based methodology as a sales tool. Projects never actually worked that way in reality - what they said they did and what they actually did were completely different. Once I realised that the development process was actually perfectly OK and nobody actually looked at the UML I was fine.... ;-)

henrik_w 11y ago
I was developing SW in the 1990s (before XP, then Agile, become popular), and we were supposed to use UML, Rational Rose etc. However, that was how it was supposed to work, not how it actually worked. The biggest relief in starting to use XP was that the methodology described how we actually worked, not how we were supposed to work.
- crdoconnor 11y ago
  I always thought the quality of rational rose itself was the best argument against UML. After all, that's probably what it was designed with.
  - julian_t 11y ago
    Oh my, I can so identify with this. I used to do product reviews for a magazine, and Rose was the only review software I decided not to keep. And I'd have felt bad giving it to anyone else. From that time on, any mention of Rose in a job description automatically disqualified it.
- mml 11y ago
  I was on a big project in the early aughts (pure XP, pairing, tickets, stories, tests (40,000 of them at the end) etc), on which, we were contractually obliged to A. hire on at least 4 accenture consultants, and B. purchase 4 rational rose seats. We simply stuck the accenture clowns alone in a room with rational rose, and we never heard from them again (nor did we ever see any uml). Best case scenario.

jmartinpetersen 11y ago

I hope UML as blueprint (or even, shudder, UML as a programming language) now mostly lives on in the memory of those who suffered under it.

SSLy 11y ago
Unfortunately, I am having two mandatory courses that focus on it (it's a BSc CS programme).
- jagger27 11y ago
  Carleton University? Christine?
  - ImNotAKompjoetr 11y ago
    could be anywhere, mine also has a mandatory course on it, including a lecturer that believes in the magic of auto-generated code from the UML tools.
- SmellyGeekBoy 11y ago
  Wow, I remember studying UML in BSc CS nearly 10 years ago. I'd imagine it's much less relevant now than it was even then.
- brianpgordon 11y ago
  Two courses that focus on it? What school is this?

gopowerranger 11y ago

Part of your story reminds me of the customer of the computer company I worked for that would, every week, print out sales and financial reports that ran for hundreds of pages and about as thick as you mention. The girl who ran the reports told me that the only people who ever looked at the reports were the sales guys who would flip to page 20 and look at the bottom line sales number. It was then filed away in the warehouse, never to be seen again.

m_fayer 11y ago
Back then, I found it strange that people would cheerfully exchange stories such as yours, stick Dilbert strips all over their offices, swap dailywtf links, and just carry on. I was never able to compartmentalize enough to be happy while also admitting that I live in some Kafkaesque version of Office Space. I remember being told by my seniors that I'll grow up and grow a thicker skin, and that I will accept that this is just how things work. Now, I'm happy to find out that that is not indeed how things HAVE to work, and I'm a lot happier and less conflicted. And now that we have many prominent examples of more functional and humane corporate and engineering cultures, I'm sad for all those people still toiling away in dilbert-land.
- aklemm 11y ago
  What are your best examples on non-Dilbert-land cultures? I want to go to there.
  - jerf 11y ago
    Startups aren't Dilbert land. They literally can't afford it. They have their own pathologies, of course, but they aren't Dilbert pathologies. (And due to scale, if you are motivated, they are often, but not always, more amenable to fixing.) You can also look around for medium-sized places where software is the primary product; they can typically afford some Dilbertiness, but not too much, or they get eaten by somebody else. Depends on your tolerance, and on your ability to carve your own defensible niche out. But either way, the key is certainly to start looking. No, working in Dilbert is not inevitable, but you'll have to take positive action if you are stuck there now.

smoyer 11y ago

"Their stated goal was to no longer have to write any code in house, but rather nothing but UML" This goal was promoted heavily in the late '90s and early '00s. Some tools could supposedly "round-trip" between UML and code, but I never saw that actually work. As originally conceived, UML was supposed to foster communication and there are times when a UML diagram is the perfect means to communicate the intent. I tend to use sequence diagrams and ER diagrams the most (yes - I know ER diagrams aren't UML but they're roughly analogous to class diagrams and what we're usually trying to flesh out is the relationship between models). As an aside, there were/are graphical programming languages. I wrote a couple of Windows and Mac utilities in ProGraph [1] during the '90s. The ProGraph environment lives on as Marten [2] which I recently played with on Linux. It's not nearly as clean as I remember it being. [1] https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph [2] http://www.andescotia.com/products/marten/ http://www.andescotia.com/products/marten/

nine_k 11y ago
There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams. ER diagrams are super useful, too.
- detaro 11y ago
  Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...
  - noxToken 11y ago
    It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that. The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png http://s18.postimg.org/gxfkjytft/diag.png You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML. Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.

pjc50 11y ago

In 2013 I encountered a major IC design company that still works in this way: spec -> complete English+diagrams description of all system components -> Verilog -> production.

jpmoral 11y ago
I left hardware engineering less than a year into my first job more than ten years ago. I'm curious, how is it supposed to work?
- lfowles 11y ago
  Agile hardware sounds dauntingly expensive!

j03m1 11y ago

yes this. When I read the title and clicked the link, I thought, shouldn't this page just be blank?

sswaner 11y ago

I was involved with one of those UML -> Code systems back in the early 2000's. It was company called Nuevis. I had proposed a simple CMS to be written in ASP (or maybe Cold Fusion). We had a project plan, requirements and design documents and developers ready to start. Some architect said we would be the perfect use case to test this new technology. We met with them, licensed their system and began to make UML. After several weeks we started to generate code, but it wouldn't run. Several more weeks and we had running code, but were missing key functional requirements. We pulled the plug after 6 months. It turns out that UML class and state diagrams are just not robust enough to explain specific functional details. The system generated thousands of lines of code to do simple things. We ended up writing it ourselves in ASP, it took us about 3 weeks to code everything. Nuevis went out of business in the original dot-com bust.

ArkyBeagle 11y ago

I worked on at least one project that used ObjecTime, a predecessor to UML. You were coding in it, in a very ship-in-a-bottle way. The article completely ignores how state machine patterns are done in UML, which ( IMO ) is where you start to see some gain. This being said, just doing state machines in a non-OO way isn't exactly rocket surgery. It was tolerable. But changes were a bit expensive, and we kept a reference machine for builds, which was not very nice. The environment was hard to replicate - behind the scenes was a sandbox of Smalltalk and that was sort of ugly. We did a port to Rose, but Rose was not, frankly, as capable. What's funny-peculiar is - as described in your experience - the whole idea of "architects that can't code." At the very least there's apparently no market for tools to enable that.