New post
Article
· Nov 26, 2018 2m read

InterSystems Best Practices

#Best Practices #Developer Community Official

Hi Community!

We are introducing a new feature on DC site - Best Practices of InterSystems Data Platforms.

It is the tag, which highlights articles on DC considered as Best Practices on how to develop, test, deploy and manage solutions on InterSystems Data Platforms. 

Why do we do this?

You often asked us(InterSystems) what is the attitude to different posts on DC? How to distinguish posts with  InterSystems message for developers from "just thoughts"? Actually, you can subscribe to Product Managers and Technology architects directly, but we must admit that there are a lot of articles from Community members which have tons of experience, bright solutions, and knowledge and which are in fact the Best Practices for InterSystems Data Platforms. And we want to highlight this content.

Who makes the decision? 

We established a council of InterSystems Product Managers and Technology Architects who review articles and decide on whether it is considered as InterSystems Best Practice.

What posts will be reviewed?

All articles and some questions on DC which have best practices answers.

How often will we see new Best Practices on DC?

Every week we'll tag a new Best Practices article. You can get the notification about it if you subscribe to  Best Practice tag page. Also we'll put a comment to the post from DC administration that it is selected as Best Practices.

When will we start?

We already started. Subscribe to the tag and stay tuned!

And we are waiting for your InterSystems Best Practices article!

Discussion (14)1
Log in or sign up to continue
Andre Larsen Barbosa · Jun 17, 2021

Hi everyone... My name is André Larsen Barbosa, known “popularly” as Larsen. Unlike most community members, I'm not a programmer, and in fact, I don't like programming at all. Yes, there are other areas in IT besides these.

Come on, I believe all of you developers do testing after development, right? Or are they so confident that they believe they can't make mistakes? Or, do they wait for the problem to appear in the user? Then just launch an update and fix or undo this mistake. So, that's exactly where we work with quality (well, everyone should work with quality), but I'm referring to a specific area, which is QA, or Quality Assurance.

When I talk about this, at the same time, I know that there are many companies that already work in this way, with very specific departments and with a somewhat rigid process. However, we also know that many are self-employed, independent programmers, who perhaps, and only perhaps, have not had or do not have this opportunity, which I tell you, is unique. No, I don't want to convert anyone, but I'm sure if you've read this far, you'll think about it.

What is quality software? Only software that doesn't give an error when opening it? Is it fast software? Cheap? Simple? Who meets what has been proposed? Which meets the customer's needs? Well, we have a lot of possibilities, but, I tell you all, when we talk about customers, they certainly expect all these questions to be answered by the software you've developed. And I go further, it's not just the code used, if it's clear, if it has comments, if it follows some rules and basic concepts. This is just part of the process, which crosses some boundaries and affects many areas.

Process, there is a very important word for the “acquisition” of quality in a project. So, how to achieve the expected result if we don't get a satisfactory interview with the client? Therefore, we will not know exactly what to build. How can we do something with quality if we don't participate in the negotiation of deadlines? Thus, it is true to say that quality must be involved throughout the entire process. I'm not saying that it's a rule and that if it doesn't, it won't work, but it will positively influence this participation.

With one more interesting point mentioned, which in fact is software (and here I open to any and all work that can be done, whether it is software, building a house, a cake recipe, anyway, anything, once that Quality, or the concept of quality is universal) of quality? It is very subjective to speak, but, thinking of a way to translate this, we would have something like: “The totality of characteristics of a product or service that can satisfy a certain need of a certain customer. And it is achieved through the permanent search for better results based on the best performance of each of the elements of a process, always oriented towards the customer, meeting their needs and above all exceeding their expectations.”

What motivated me to do this article (if I can afford to call it that)? You would be surprised by the absurdities we see. It's about losing sleep.

0 0
Nigel Salm · Jun 17, 2021

Hi Andre

I have read your article and I think that it is worthy of being included in this thread as you speak many truths. I am sure that many people work with technology, from the Customer Project Managers, the Business Analysts, the Team Leaders, the Scrum Master, the Senior Developers, Junior Developers, Testers, Customer UAT testers, and ultimately the Users of the resultant Technology Solution who view their role in the chain with Blinkers and work on the basis that as long as they do their job properly (and that is a word that can mean many different things) and are either unconcerned about the people who fill the other roles in the chain or view them as a necessary evil. But I also believe that there are technologists who are very conscious of the fact that they are an important element in the overall delivery of a solution. It is very rare to find people who can wear the hat of all of the players in this chain. I have met maybe 3 people in my entire career who just stood head and shoulders above everyone else in their ability to communicate and understand the needs and requirements of the customer,  translate those requirements into a set of tasks for the Business Analysts to prioritize, document, create the project scope and timeline, write requirement specifications that can be understood by the customer and the development team, be able to sit with the senior developers and discuss the possible approaches to crafting a solution, who can clearly identify which tasks should be handled by the senior developers and those that should be delegated to the more junior developers, create testing plans for the testers and the documentation writers and ultimately guide the Customer UAT team through the stringent test scenarios to ensure that the application does what was requested, does not crash, does not present the user with an explosion of colour and animation and finally go back to the customer and get that all-important sign-off so that the invoicing and payments can be finalised. Some of us have been lucky enough to have been assigned to a project where we were able to interact with the customer, understand their business, understand their pain or their ambitions, then take that knowledge and produce the requirement specifications, technical process flows, choose the software elements, write the code that pulls all of the components into a functioning whole, documents their code such that future developers who have to work with that code can do so without messing it up because they are unaware that a statement in line 23 of 5000 lines will inadvertently cause the logic on line 2356 to take an unexpected step to the left and render the program unusable. Very few developers get to spend time with the quality assurance staff and ultimately the users who have to use the application to do their jobs and be able to go home without a blinding headache and a sense of dread that tomorrow they are going to have to fight with the application to get the printout or that all-important "Your data has been saved. Click OK to proceed" popup.  

I have seldom met a programmer who will concede that their code is not as good as the person coding next to them, or for that matter finding a developer who can gracefully and politely read some truly awful code of another developer and take the time to work with that bad developer and help them become a better programmer without inadvertently step on 1 f 20 emotional and ideological traps that arise in every one of these encounters. Or maybe I would use the analogy of the McDonalds Ice-cream specialist who was born to whip up the most perfect McFlurry who has to stand and watch a steady stream of ice-cream servers who don't give a damn and will be leaving in a month to go and pour soda at Wendy's. 

For the last 50 years software creators, whether they be individuals or technology companies, have discussed, and theorized, and consulted psychologists and time-management experts, and even astrologers to come up with the definitive guide to creating perfect, absolutely perfect, application. Entire libraries of books and templates and methodologies and Predictive Indicators intended to match the right person to the right role and despite those 50 years and the brilliant, practical, theorists and technologists who have contributed, with dedication and fervor to this topic, And yet, for every model that has emerged from these think tanks, 100 bad applications are spilling out the doors of the technology companies.

And I haven't even started on the external forces, the project managers, the customer relations manager, the accountants, the middle managers, and worst of all the salesmen who, in just doing their jobs, manage to inflict sufficient damage to the 'plan' thus guaranteeing that the final product will be ....less.

But then you encounter a group of people who have formed themselves into a community, a 'Developer Community', who come from a myriad of different backgrounds, skills, methodologies, personalities, and socio-economic, gender-based cultures who miraculously have one thing in common. They love to code. Their hearts soar when they interact with a user who says 'Thank you because of some modification that they have made that has made that user's life just that little bit better. And all of us have at some time or other written a bad piece of code or have struggled to fit into the 'TEAM', or had to deal with a salesman who has sold unrealistic solutions and unachievable timelines to a customer who in reality didn't actually know what they actually wanted to start with. We have seen it all, we have notched up successes and strive hard to forget the failures and yet we go to bed at night and we dream of tropical islands with dancers wrapped in fine silks with pet tigers on leads and woken up the following morning with 5 pages of code written vividly on the insides of their skulls and in a blinding flash of light they know that they have cracked it. The mists of possibilities and uncertainties and intrusions and indecision that has plagued them for the previous 4 weeks have overnight coalesced into the 'Perfect' solution. Their fingers are already tapping at their laptops as they eat their breakfast and for the next 8, 18, 80 hours magic flows from their fingers into that IDE that is the interface between their imagination and the architecture that will swallow up their code and compile it into the module and voila! It's done, and it's beautiful.

And then we go home and get up the next day and do it all again. And as we create solutions we come to our community and we bounce ideas off each other, we seek out the nuggets of knowledge and experience from our friends who went through the process of being the first person to master a technique or understand a piece of functionality that is almost incomprehensible to most of us because or minds might not be wired in such a way that understanding that functionality was as easy as watching the Eurovision song contest without crying.

What we all share in common though are years and years of tuning our coding styles, learning and absorbing emerging technologies, developing the skills to share our knowledge with the people we work with without making them run from the room sobbing because you have been too brutal in your appraisal of their work and it is through a community like ours that so many of us have become the skilled and dedicated developers that we are.

What I do know is that generally speaking, I have met more developers who have been able to help the Business Analysts understand the requirements, ask the right questions of the customer to find out what they actually need, pacify the project managers that their agile, and scrum, and Jira, and storyboards will get to the finish line without incurring penalties for late delivery. Who find the time to document their code knowing that no matter how well it is written it is going to take another developer some time to work out what you have written and how it fits into the bigger picture and finally, one day, they get to meet the user who is using that application who turns round and comments that this application has helped them get their work done quickly and efficiently, that doesn't shower them with pompous popups asking them how they could be so stupid to put a text letter into a numeric field. 

We may not be able to ensure that every element in the chain is going to work as expected and that ideas and requirements don't occasionally get twisted in translation nor make every single user equally happy but we can control the space that we occupy and we know what we are doing and we have adopted different coding styles over the years and we find our selves at a point where we believe that we can layout a template, a structure, a developers ethical code and produce a set of standards and conventions on which we all (give or take) agree, if followed, will stand a chance of guaranteeing that the programs we write work, are readable and maintainable and when fitted into the whole will generate an application that works, is good, beautiful even.

We take pride in our community. We welcome the input of the outside world, we like to learn and experiment and listen to the experiences of our comrades and when we are in Boston we will gather in a fairly dark room and drink a little too much and listen and watch as one of ours demonstrates his latest little app or tool or plugin and it makes us happy and we feel very much at home.

Nigel. 

2 0
Andre Larsen Barbosa · Jun 18, 2021

Hi Nigel, despite your tone of vengeance, I agree with you, I know the ability that developers have and that in many cases, they know much more than the user, or even anyone else who claims to know the process. And if it generated this feeling, I'm sorry, it wasn't the idea, and yes, it's good to have a different view. At the same time, you agree with me that this look from the outside also influences, no? And, I saw in your text a good part of the questions that I live in my work. I can only thank you for your "comment" and apologize if it was too general and offended you as a whole. At the same time, I believe that we have different views and that uniting them is certainly beneficial. So thanks and sorry.  

0 0
Nigel Salm · Jul 13, 2021

Hi Andre,

I would like to apologise if the tone of my reply came across as vengeful,, that was certainly not my intention. An hour ago I started writing a response where I took two examples from documentaries that I had watched during these long Covid Lockdown hours. One was about the production of a single Rolls Royce car and the amount of time, craftsmanship, quality control, pride and perfection that goes into the manufacture of each car. Each component is crafted by an individual who has practised his art over decades of trial and error. If the component has the slightest 'fault', quite often some imperfection that 99% of the population would not notice but the man who crafted the component and the quality control manager did notice and the item would be scrapped and the process would start all over again and I guess that it is for that reason that the best Rolls Royce cars sell for around $12 million. Probably half of that cost goes into those discarded items that did not meet the standard of quality that Rolls Royce prides itself in.

The second documentary was about the ice cream machines that franchise owners of McDonald's restaurants have to buy when they buy a McDonald's restaurant and how those machines have a very complicated cleaning program, which, should it fail, renders the machine unusable until a certified mechanic is called out to come and fix the machine. The mechanics are certified by the manufacturers of the ice cream machines and the rates they charge are high and in the food business where profit margins are slim is easy to understand why roughly one-third of McDonald's restaurants in the USA are not serving ice cream as the machine is 'broken'.  25% of the companies revenue is derived from the 'services' of their mechanics. The company could probably make an ice cream machine that doesn't break down but to do so would eliminate 25% of their revenue. It just so happens that the company that makes the ice cream machines are located in the same city as McDonald's headquarters and they have had a 50-year relationship where McDonald's earn a certain amount of revenue through the sales of the ice cream machines and the ice cream machine manufacturer earns 25% of their revenue by supplying machines that in a sense are designed to fail periodically. It also turns out that both McDonald's and the ice cream manufacturer are owned by a nameless holding company.

In the original version of this reply I went into far greater detail about each documentary and then two things happened. For the last month I have been using a program called Grammarly which, in the free version, will do basic spelling checks and other gramatical errors but in the paid version it will analyse your text and using fairly sophisticated algorithms will score your text against 10 different criteria and make suggestions, very good suggestions, as to how a paragraph could be rephrased as the original is too verbose or is too passive or aggressive and so on. I suspect that if I had run my original message it would have detected that the tone was a  bit 'vengeful' and would have suggested ways that I could express the concepts I was trying to convey in a more palatable manner. The other thing that happened is I accidentally hit the back page button and I lost all of the text that I had written and so I rewrote it and given that I didn't have an hour to write out all of the detail in my original I ended up writing this text instead. Grammarly tells me that I score 5/5 for Informal, 4/5 for optimistic and 3/5 for confidence. I guess the last one, confidence, is due to the fact that I haven't yet linked the messages behind the documentaries to the subject of software. 

I have worked in software companies that have been in business for 30 years or so and there were people and practices within those companies that led to a certain sense of 'we do it like this because we have always done it like this'. That can work in two ways, if you happen to have worked out a formula where all of the constituent parts are tried and tested and produce a certain level of excellence then that software company is likely to produce good applications and will continue in business for many years to come. Somewhere in those companies you are likely to find individuals who take great pride in their work and that sense of excellence influences those around that person and challenges them to aim for the same levels of excellence. On the otherhand it can lead to a company that started off with an innovative product that sold well and as a result they have applied the same standard to everything that they have done thereafter irrespective of changes in technology or fresh ideas brought in by new employees but eventually fail as the software they produce is no longer innovative and probably fails periodically requiring a 'sotware expert' to come on site and fix it. It is a fine balance to maintain. Companies cannot just change the way that they do things at the say so of some fresh employee with bright ideas. Nor can they remain stuck in a certain well trodden path because eventually they will be left behind as other younger and more adventurous companies enter the market with their innovative products and steal the lime light.

Excellence comes at a price. Those individuals who have taken their craft seriously and have become masters in their trade do not come cheap. Companies that try and produce excelllence using people with fewer skills and a willingness to work for lower wages are likely to produce poor software. The art is in matching the right people for the right tasks. Investing in the areas that demand excellence whilst not ignoring the role of the often overlooked managers who hold the whole enterprise together with their stoic reliance on repetative tasks.

At this point Grammarly is telling me that I have said enough. My ratings are now showing 5/5 for Optimistic and Confident and 5/5 for Formal as opposed to 5/5 for informal that it scored me half way through the text.

Yours respectfully

Nigel

1 1