My musings below are all largely off-topic. Thanks Mo -- you are speaking my language. I've been sitting in mgmt roles since 1988. I'm stretching myself a bit with some hands-on coding right now, although I have kept my fingers in that too, off and on, over the past few decades.
A lament for the software industry: Even when I have a team of developers now, I am hard-pressed to put as much functionality into production as reliably and as quickly as I did in the summer of 1977. I don't know if the software development industry can ever be that productive again from the standpoint of the organizations we are serving as when we were automating business workflows for the first time. Armed with a server (mini-computer, at the time) running on a token-ring network, a "green screen" terminal, a 3GL, and indexed-sequential files, along with runoff for doc, I could run circles around the developer I am today, although I know a LOT more now, so go figure. Anyway, yes, it is definitely important to consider risks and the overall business case. I'm coming into this project to address a business goal, rather than a specific technical goal, and I definitely learned a lot making a variety of both business and architectural choices and suggestions to date and doing a little POC with the MEAN stack. It is so much more complex to program today than it was in the 70's! I met Grace Hopper in the 80's and sometimes wonder what she would think if she saw how cryptic our software development is today. This is NOT the direction I was hoping our industry would go. cheers! --dawn On Tuesday, June 2, 2015 at 1:24:56 PM UTC-5, Mo Moadeli (CREDACIOUS) wrote: > > Dawn, I've been swamped at work so apologies for delayed response. If I > may, I want to perhaps add a different perspective that contains elements > that indirectly relate to your concerns but might also be of more direct > importance to the LOB decisions makers you originally alluded to. > > Speaking of 'decision makers', there is someone, a senior IT manager or > senior technical business manager, who (hopefully) should be thinking less > about the technical nuances of the options discussed), and more along > BUSINESS elements (even if the LOB is a cost center), and would be very > grateful if you can help them translate the technical SWOT (discussed > rigorously above) to a BUSINESS SWOT. If I were them, in addition to the > high-level technicalities mentioned, I would be considering the following > (very broad-brush) inter-related items: > > - risk mitigation: i.e.: Regardless of the final technical solution, how > can I reduce the impact on the business if something goes wrong (eg: > AngularJS x.x support ends unexpectedly or React.js never achieves > maturity/stability)? How does that compare with what I have today? > - constant or/added productivity: i.e. For each solution what is the > turn-around time and complexity to service the requirements of my > stakeholders and/or to carryout standard maintenance for a given lifespan > T? (eg: Angular x.x's inherently complex but robust vs React.js easier to > use but only-part-of-the-stack solution) > - (Human) resources: i.e. What is the level of expertise available and > support, how often, and for how long? (large AngularJS community and > support environment vs active and growing React community) > - And of course (opportunity) costs: i.e. What is the cost of > implementing my solution that covers items above and how does it compare to > the opportunity cost of not choosing the alternative? > > With the technical content you already have from your own research and > thoughts provided here, you need to sit with this person and jointly build > that case for each solution, openly and credibly. They will be very > grateful that you can couch the problem in these terms and/or help them > construct the business case in their own language. > > I hope this helps! > > Mo > > PS: In the main body I intentionally left out my thoughts on which way to > go because, frankly, I am biased! :)) However, for whatever it's worth, > and not knowing the specifics of your LOB, I believe staying on the > AngularJS track will more or less satisfy the business criteria above. > That said, in this day and age of rapid innovation (especially in software > infrastructure) a business (or LOB) can ill-afford a fire-and-forget > strategy, and must revisit their choices far more often than before and be > prepared to shake things up if stakeholders AND business requirements > demand it. The opportunity costs of inaction will out-weight the costs of > action more often than not. Regardless, the final decision is heavily > dependent--not only on technical merit--but business criteria as well. Good > luck! > > > On Tuesday, June 2, 2015 at 1:13:57 PM UTC-4, Dawn Wolthuis wrote: >> >> As much as I enjoy a good chat about languages, that was not the purpose >> of this thread, although I know I mentioned that JS fit a project better >> than TS right now. If someone wants to start a new thread regarding >> languages that meet Grace Hopper's criteria of sounding close to English >> (perhaps we have apps like Siri for that as the programming industry went a >> far different direction!), or languages that give you enough rope to hang >> yourself (basic, js, cobol, ...) compared to languages that hang you >> themselves or cause you to want to hang yourself, or whatever else there >> might be, I might even chime in. Right now I would be happier to accept any >> more comments in this thread that are more directly related to the original >> post. >> >> I now have advice from several sources and am leaning toward Sander's >> advice of choosing option b, upgrading to 1.4 before we dive into the >> rewrite, continuing to use ui-router. The second most popular response from >> folks I have chatted with is to bite the bullet and convert to the new >> router before we begin. The folks with that suggestion are far better than >> I am at coding and can just "toss things in and deal with it" better than >> I. With what I have seen so far, given I have been happy with ui-router, I >> am pleased not to have to start thinking like the new router, but that >> might be overly short-sighted of me. It seems to be yet another paradigm >> shift for no apparent reason (so I'm glad others are aware of the reasons >> and trust that they are good ones). I'm hopeful that ui-router will stick >> around for the conversion to Angular 2, so it might even help with that >> effort in the future. >> >> Is there anyone who can speak in favor of choosing option c and >> converting to the new router now rather than diving into a significant >> re-write without learning the new router first? >> >> --dawn >> >> On Monday, June 1, 2015 at 11:50:31 PM UTC-5, Anton Trapp wrote: >>> >>> Language wars. How funny. Hated JavaScript (came from Ruby and this is >>> still my favorite), with CoffeeScript I can look at it because it does not >>> look to ugly :) >>> Yes, some concepts (or the lack of them) show that not the most clever >>> people invented it yesterday and used all the experience from other >>> languages to do that. >>> >>> But to say a language is bad because people try to make it better over >>> the years as the intended purpose changes and it gets used by much more >>> people is silly. Every language that is used and after every new pattern >>> that proves worthy (DRY, ...) gets it's updates, otherwise it vanishes. >>> >>> And I am in the software business for almost 30 years. Saw many >>> languages and projects. Not a single one failed because of the used >>> language. Some failed because of people not able to understand how do deal >>> with the weaknesses of the languages and frameworks. >>> >>> And bashing around on something without any proof is just wasting my >>> time. JavaScript is definitively one of the most important and most used >>> languages today. Likely because it is unusable and all people who use it >>> are idiots. >>> >>> Really have better things to do. Out of this thread - have fun bashing ;) >>> >> -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to angular+unsubscr...@googlegroups.com. To post to this group, send email to angular@googlegroups.com. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
