The Reverse Engineering Stops Here?

I used to have this in my email signature:

gnireenignE

As a developer of training, it was my duty – my calling – to save software users from having to reverse engineer how the software worked.  Reverse engineering is hard, it’s really time-consuming and it’s error prone.  Reverse Engineering the software is supposed to stop with me.

I’ve recently dipped my toe back into migration services for the first time since I started using (and loving) OpenRoads.  

Maybe it’s the fact that most of my career has been primarily modeling and only rarely sheeting.  Maybe creating sheets from your models is easier that consuming someone else's.  Maybe I’ve just fully embraced the idea of working in an immersive native 3D What-You-See-Is-Really-What-You-Got (WYSI-Really-WYG!) environment.  It’s probably all of the above, but looking at sheet sets from the “old” 2D modeling days…

Holy Stick Figures, Batman!  Trying to make a mental picture of the 3D Engineering in my mind from 2D line drawings is reverse engineering of the worst sort.  It’s painful. 

Apparently Reverse Engineering is a major component of that old paradigm. Who is good at that?  Who enjoys it?  How error-prone is it?

I’ve always considered Poetry a high-loss compression algorithm that impairs clear communication.  I get that there is a subculture that enjoys it.  Unless it’s song lyrics, I have no time for that kind of ambiguity.

I get that there is a specialized experienced sub-group of people who are adept at reading plan sets and perhaps even enjoy the process.  Is it fair of me to think of them as cultists who derive status from excelling in a skill that few can master?

Is it rude of me to consider the skill analogous to reading entrails (without the precision or the aroma)?

We see the underlying model being requested by earthwork contractors as they can save a lot of money working directly from the terrain model.  Sheeting requires high effort to create, it is prone to error in creation.  It takes high skill to consume and is prone to error in interpretation.  It persists because when the lawyers get to fighting, all they can handle is paper. 

The industry is moving from the paper towards the model.  OpenRoads makes the model revelatory.

As a long-time modeler who seldom consumed sheets, and who has fully embraced the WYSIWYG 3D modeling paradigm, I loathe sheets as deliverables.  As someone who had dedicated a career to helping others transcend reverse engineering in particular and bad process in general, I loathe sheets in principle. 

How bad is it for you?  If you are comfortable consuming sheets, how long did it take to feel good about them?  How do you feel about the shift to modeling? 

Am I wrong not to ever want to work with plansets?

Is my brain simply not big enough for sheets?   I'll take your word for it.

Thanks for reading..

-jeff martin

Parents
  • So why does OpenRoads force you to work in 2D?  And just what is it that OpenRoads can do that SS2 couldn't?

  • I built a career on InRoads: I can't bear to use it anymore.  Corridor is order-of-magnitude similar, but InRoads geometry is dramatically inferior to OpenRoads (not even considering the fact that things like Generate Longitudinal Feature is one-off immediately-forget, one-change-requires-rework-of all-dependencies).  And not being able to trust the graphics and having three incomplete redundant data models (dgn, alg, dtm) is simply an unbearable burden compared to the WYSIWYG one-format dgn...   Not only can I go on and on, I probably will be.  Watch this space.

  • It's not entirely true to say that the graphics are the data.  Generally, I can't edit a terrain model directly, I have to edit the elements that the terrain is "ruled" to.  Similarly, editing geometry requires changing "design intent" rather than editing the geometry directly.  For both surfaces and geometry SS2 includes a more complete set of tools for creating and editing DTMs and alignments, respectively.

    SS2 allows the user to easily identify and work with features, individually or in groups.  ORD has made it much more difficult to work with them individually.  In SS2, if I want to distinguish different fence types, I can use a "fence" feature style and indicate the type in the name or description.  In ORD I need a different feature definition for each type, not to mention different heights or materials.  If I need to check the effect of including or excluding a feature, I simply change the triangulation flag in SS2.  ORD essentially requires deletion/recreation.

    ORD's implementation of spiral segments, relatively easy to use in SS2, is almost nonexistent.  In our state spirals have been required almost since sometime in the 1920s or 30s.  That includes the spiral segments in the middle of compound curves.  Tick a radio button in the SS2 curve definition dialog and the curve is placed.  ORD all but requires use of a calculator.  In ORD I've successfully inserted a vertex into a tangent only to later discover that the following PI is still ruled to the prior PI.  That was certainly not the design intent!

    By its nature highway design is iterative.  Many of those iterations will be thrown away in their entirety but most will have useful portions.  The alignments will be copied and saved for later evaluation because the designer doesn't always know which is which until several iterations have been processed.  In ORD, each copy of the alignment must be in a separate model - for most users this means different files.  Successfully piecing together the valuable bits from multiple iterations is not easy.  Would I rather have multiple files, each containing a different iteration, and a challenging process for piecing together alignments or would I rather have a single file with many alternatives and relatively simple, straightforward methods for assembling alignments from multiple sources?  That's a no-brainer for me - I'll go with the more flexible solution.

    In InRoads, roadway components could only be accurately displayed with the modeling process - the real-time behavior of corridor design makes this less of an issue.  The superelevation wizard is a definite improvement over SS2's.  Although it needs a couple of tweaks, most notably the ability to apply slope constraints for a point both back and ahead, less so the ability to edit directly in the graphical half of the superelevation editor, I would say that superelevation design is much better.

  • Great post, Ray. 

    I would say on The Big Picture side of things, I'd rather a single extensible datasource (the dgn) than 3 incompletely overlapping sources (especially if they can be in conflict with each other).   I'll take your word that there are more tools in SS2 for editing those incomplete data models than there is currently for editing the dgn. 

    No, we don't have a I've Changed My Mind About the Engineering Assumptions button yet, but I find it pretty easy to go down What-IF rabbit holes by Setting A Mark, fooling around, and then Undo to Mark (granted those are short-term, small scale explorations).  Big requirement upheavals will always require extra steps.

    I don't know if it's true or active or if I'm "allowed" to say it, but I believe we're looking into parametric featurization for those detail-y variations.  Utilities, in particular, would benefit dramatically with parametric pipe and structure resizing.  

    There's a saying in economics "When you're out of a job, it feels like the Unemployment Rate is 100%".  I think it parallels "when that specialized niche tool goes away (temporarily), but it's yours, it's neither specialized nor niche".  

    I expect that all the enhancements you are looking for are ITNR (In The Next Release) Laughing (I bet they're in the enhancement queue, though). 

    I have faith (after all these decades working with software) that a better platform will lead to better details and broader capabilities.  I trust your arguments, but I still look at InRoads as someone who stole my heart but was unfaithful to me.  My new girlfriend, ORD, is getting a big fat ring from me.

    Again, thank you for such a valuable post.  I'm going to use it to brain-pick some Product Managers with it.  

    Thanks, Ray!

  • "Currently", in your first paragraph, is key.  Probably my biggest beef with Bentley's implementation of ORD is abandoning InRoads, a mature platform, before ORD is complete.  SS3 and SS4 were positioned as transitional products.  Bentley is now calling direct replacements for tools found in SS2 "enhancements".

  • changes to software tend to fall into two categories "fixes" or "enhancements", so I don't think that's intended as sneaky.  InRoads had 20+ years to enhance its awesomeness.  ORD is in a really good place in a few short years (even with the "pause" caused by the 64-bit rewrite).  The gaps are getting tinier.

  • There is a "Nimble" philosophy in software: get stuff out fast, even if it's not complete to get market feedback to establish priorities for the next quick release".  The key is getting the feedback.  Our Communities and Connect Center are two primary feedback gathering mechanisms.  Ray, if you have a list of your primary ORD Beefs, can you send it to me?  I'll get the items in our database. 

    I appreciate your feedback; I interact primarily with class students, so we don't spiral off into the deep weeds very often.  I find ORD dramatically easier to teach and I think, long term, the reasons for that are indicative of a much better software platform design.  

    Thank you, sir!

Comment
  • There is a "Nimble" philosophy in software: get stuff out fast, even if it's not complete to get market feedback to establish priorities for the next quick release".  The key is getting the feedback.  Our Communities and Connect Center are two primary feedback gathering mechanisms.  Ray, if you have a list of your primary ORD Beefs, can you send it to me?  I'll get the items in our database. 

    I appreciate your feedback; I interact primarily with class students, so we don't spiral off into the deep weeds very often.  I find ORD dramatically easier to teach and I think, long term, the reasons for that are indicative of a much better software platform design.  

    Thank you, sir!

Children
  • Thank you for the offer.  We are currently working with Bentley to develop our new Connect workspace and I'm pretty sure my specific complaints have already been registered.

    My biggest beef, though, is that ORD is not complete.  The last complete product was InRoads SS2 (I can't speak to Geopak or MX) which has been abandoned.  The incompatibility between updates is evidence that Bentley recognizes that ORD is unfinished.

    Because of the data and operating differences between SS2 and ORD, 30% design, plus or minus, will be our cutover between versions.  The duration of a typical highway project from 30% to final quantity measurements is 2-3 years, larger projects could be as long as 6 years.  We will be using SS2 for the next five years or so.  Bentley's approach may force us into maintaining separate, standalone, Win7 machines until we no longer have any SS2 projects.

    Thanks for listening.  I do see ORD maturing, although that process is not fast enough for me.  We will probably deploy with Release 3 or 4 of this year and I expect that some of my complaints will be addressed by then.  For those that haven't I may resort to SS2 and import into ORD.

  • Let me be clear: I don't know your work, but I recognize that you know your workflows, needs, gaps and challenges extremely well.  I'm sure you've streamlined your operations to maximum efficiency.  My responses here are ignorant of your details, they can be seen as shallow and reflexive, and that you've probably heard many or most of any explanations.  Know that my offered "defenses" are something of a compulsion, that there is a slight, but non-zero, chance of a nuance you may not have considered, most importantly, I offer them with great respect and certainty in your expertise.  

    Most new schema variations between versions now are due to "enhancements": new capabilities.  These are not for filling gaps of missing old technology.  Things like enhancements to Subsurface Utilities and the brand new revolutionary (!) OpenSite technologies  are  primary schema "breakers".  Development and Product Management recognize the potential for disruption and are pursuing strategies to mitigate.  And, absolutely, everyone wishes the pace were faster.  Concerning InR SS2, bunches of us run it on win10 without challenge...

    I'm not sure how big the audience for these posts are, but I thank you for the spirit in which you have provided your insight and the time you took to express them.  There's great value in here, I hope the right people on our side are getting (I'm not sure if they pull it, but I tend to push it to them).

    Thanks again, Ray.