​

 

 

How management buy-in affects Agile transformationhttps://www.cleverlance.com/en/blog/Pages/agile-transformation.aspxHow management buy-in affects Agile transformation<p>​​​​Agile transformation can be a powerful tool for businesses looking to improve efficiency, productivity, and flexibility. However, the success of an agile transformation is often tied to management buy-in. As I've written in my <a href="/en/blog/Pages/agile-tranformation-derail.aspx" target="_blank">previous post​</a>, in many cases, the motivation for an agile transformation comes from believing that the current organizational structure is misaligned and that agile will be a cure-all solution. Management may also have unrealistic expectations of the transformation process.​<br></p><p>In reality, management must play an active role in the transformation process, working collaboratively with teams to identify and solve problems. This requires a willingness to hear bad news, make difficult decisions, and address structural and systematic issues that may be inhibiting agility, such as overly complex organizational hierarchies, rigid technologies, and inflexible approval processes. Without this buy-in and active participation, agile transformations can become nothing more than a superficial change with little real impact on efficiency or productivity.​<br></p><h3>Definition of management and leadership</h3><p>There are multiple definitions of what management actually is. Let me cite the two classical ones:</p><p>Harold Koontz: Management is an art of getting things done through and with the people in formally organized groups. It is an art of creating an environment in which people can perform and individuals and can co-operate towards attainment of group goals.<br></p><p>F.W. Taylor: Management is an art of knowing what to do, when to do and see that it is done in the best and cheapest way.<br></p><p>So basically, when it comes to transitioning to an agile approach, there are two key takeaways managers need to keep in mind: first, they're responsible for creating an environment where people can be productive, and second, they need to figure out what to do when others are uncertain.<br></p><p>In addition, it is worth mentioning that although there is an overlap between the skills and qualities of a manager and a leader, they are not the same. A manager oversees and directs a team or organization to achieve its goals and objectives, while a leader inspires and motivates people to work towards a shared vision or goal. Although it is ideal for a manager to also possess strong leadership skills, it is not always necessary for a manager to be a leader as they can still effectively manage a team without necessarily inspiring or motivating them. However, in many cases, having strong leadership skills can enhance a manager's ability to manage their team effectively.<br></p><p>How does this apply in the context of an agile transformation?<br></p><h3>Top-down approach to agile transition<br></h3><p>From what I've seen, a few key attributes are critical for a successful top-down approach to agile transition. Managers must be willing to hear "bad news" and make active decisions in the business's best interests. The average employee in the company needs to be encouraged by managers to identify obstacles and suggest both workarounds and proper solutions.</p><p>To ensure smooth and effective work, managers must make their visions and expectations clear to team members. Although structural changes may hinder progress, it's important to recognize that some changes take time. A shared vision can motivate team members to find workarounds in the interim, while also fostering the belief that higher-level management is actively working towards a long-term solution.<br></p><p>Having clear orientation, vision, and understanding of context on a higher level can greatly improve motivation, productivity, and the relevance of solutions during an agile transformation. It can lead to more efficient and effective solutions as they are developed with the bigger picture in mind. A sense of direction and a clear vision can be a powerful motivator for people to persevere through challenging times. Like seeing the horizon during turbulent waters, it provides a sense of stability and purpose that can help individuals stay focused and productive. It's the leader's responsibility to ensure such a vision exists and is understood by others.<br></p><h3>Don't take it personally<br></h3><p>Managers who resist hearing strategic-level criticisms can hinder the progress of agile transformation. It's important not to take it personally. The broader the problem, the more difficult it is to resolve. Attempting to fix it carries both risk and reward, which is why the agile transformation was initiated in the first place.</p><p>When managers view criticism or obstacles as a cover for employee incompetence or failures, it can create a lack of trust that hinders effective management. This can lead to a tendency to micromanage and excessively monitor employees, which can ultimately undermine all the transformation efforts. Eventually, a lack of trust can lead employees to keep their ideas to themselves to avoid potential conflicts or arguments with their managers. This can hinder creativity and innovation and create a toxic work environment where open communication and collaboration are discouraged.<br></p><p>It's crucial for managers to actively participate and collaborate with their teams, facilitating problem-solving and decision-making instead of expecting the teams to sort everything out themselves. Some obstacles are outside the control of individual teams and require higher-level interventions or support from the organization.<br></p><h3>Make decisions - that's what leaders are supposed to do<br></h3><p>Decision-making in a business context involves a shared responsibility between managers and lower-level colleagues. Effective managers take responsibility for their decisions, even in the face of uncertainty. They actively seek out the information they need to make informed decisions and recognize that some situations may not have enough information, yet still require a decision. In contrast, some managers may try to shift responsibility elsewhere rather than taking ownership and accepting accountability for their decisions in such situations out of fear of failure. It is essential for managers to understand that managing uncertainty is a critical part of decision-making and to accept this responsibility. Lower-level colleagues play a crucial role in facilitating decisions by providing valid, precise, complete, and most importantly honest information.</p><p>To handle critical decisions, organizations can foster a culture of experimentation and testing or establish a structured approach to collect and analyze data for making informed decisions. By exploring various scenarios of potential outcomes, measuring their impacts, and proactively engaging with such models, organizations can break free from this pattern.<br></p><p>Effective managers approach decision-making with a healthy dose of skepticism, validating and cross-checking data before making any commitments. This also applies to creating plans and commitments during the sales process. It's important to note that the criticism and ideas for improvement from individual teams may not just involve structural and technical aspects but also target plans. A common pitfall is when experts are not involved in the sales and planning process, resulting in unrealistic plans. In such cases, the team should not be held accountable for being unable to adhere to an unrealistic plan. Creating such a plan is a decision that involves risk, which managers are responsible for evaluating, managing, and accepting. Agile transition might painfully expose such naive plans.<br></p><p>Delegating competence and responsibility is an essential aspect of effective management. However, it's important to note that managers should also be willing to accept the consequences of delegation.<br></p><h3>Overcoming fear and lack of trust<br></h3><p>The fear of change can often hinder the agile transformation process, and many managers may be hesitant to make changes due to various fears that are common to any human being. These fears include fear of failure, fear of the unknown, fear of losing control, fear of job security, fear of being exposed as incompetent, fear of losing status or power, fear of conflict or opposition, and fear of the extensive changes required by the agile transformation process. However, effective managers and organizations are able to recognize and manage these fears, while still moving forward with the necessary changes to improve outcomes. It is important not to take these fears personally, but instead to approach them with a solution-focused mindset - because paralysis may be the other option.</p><p>Fear and lack of trust can be significant barriers to organizational success, particularly during a transformation toward an agile culture. Although these feelings are valid and may have justifiable reasons, they can ultimately hinder progress. For an organization to move forward and become more effective, it is essential to foster trust, delegate competencies and responsibilities, and empower employees to make decisions. Most individuals are naturally motivated by changes that save time and effort, and a culture of trust and collaboration can facilitate this motivation toward achieving organizational goals.<br></p><p>By fostering a culture of trust and collaboration, organizations can overcome fears and barriers to agile transformation and empower employees to take actions that save time and effort.​​​​<br></p>
How flawed motivations can derail Agile transformationshttps://www.cleverlance.com/en/blog/Pages/agile-tranformation-derail.aspxHow flawed motivations can derail Agile transformations<p>​​​​​​​​​​Agile transformation has become a buzzword in the business world. Companies are eager to jump on the bandwagon and adopt Agile methodologies. The belief is that Agile transformation will increase productivity, efficiency, and speed, simplifying everything and making it faster. While this can be the case when done right, if the sole motivation for Agile transformation is focused on these outcomes and the company has a delusional idea about how difficult it will be to achieve them, things will go south. It's always a lot bumpier than anticipated.</p><p>​This post is part of a series about the most common Agile transformation pains, as I've witnessed them in the organizations around me. This series focuses on the top-down hindrances.</p><h3>Speed, efficiency, transparency</h3><p>What's incorrect about the motivation mentioned above? Don't efficiency, effectiveness, transparency, flexibility, and speed embody the characteristics that the Agile culture promises?</p><p>​In my view, the reason it falls short is that it lacks a crucial and integral aspect of Agile methodology, which is the concept of failing fast and promptly identifying and showcasing obstacles and challenges impeding progress. A true willingness to find problems sooner and improve collaboration must also be an integral and true part of the motivation.</p><p>The misconception I mentioned is problematic because it creates unrealistic expectations for what agile can achieve. Agile is not a quick fix for organizational problems. It's rather a fundamental shift in the way a company operates. It is a way of working that requires collaboration and a willingness to adapt. Everyone, including the senior management, must be willing to collaborate with teams to improve the environment for Agile work. The whole motivation stems from the belief that problems are caused by the disorganization of teams and wrong organizational structures.</p><h3>Transformation project - its end is just the beginning</h3><p>Regrettably, Agile transformation is often viewed by management teams as a silver bullet solution to a company's organizational issues. They mistakenly perceive it as a short, one-time investment that will provide immediate and long-lasting benefits. This misconception can lead to an overly simplified approach to Agile transformation, which does not consider the ongoing effort required to sustain it. Agile transformation requires continuous effort and commitment from both management and the teams involved.</p><p>​Many managers mistakenly believe that adopting Agile is as simple as calling it a transformation project, allocating a budget, giving the project a fancy name, hiring consultants, and conducting a bunch of trainings. They think that these actions alone will suffice to achieve the transformation and their job is done. People just pat themselves on the back for renaming project managers as scrum masters and officially closing the transformation project. And then they sit back while the teams self-organize and Scrum Masters magically remove all obstacles. But that's not how it works.</p><p>Organizations often face structural and systematic problems that impede their agility. Every company has some - just their depth varies. These issues can manifest in various ways, including overly complicated organizational and decision-making hierarchies, dependence on inflexible technologies, convoluted deployment procedures, and rigid approval processes, just to name a few typical ones.</p><p>For example, a company that releases software updates twice a year with numerous dependencies, code freezes, centralized testing, and lengthy development-testing-acceptance loops will likely encounter significant obstacles when adopting Agile methodologies. The legacy processes and technology stack may be quite incompatible with Agile workflows, making it a challenge to achieve the desired level of flexibility and speed.These inherent problems won't magically vanish during an Agile transformation - they'll just become painfully obvious and urgent. The good news is that teams will finally feel comfortable talking about them and trying to tackle them head-on. Problems will be found everywhere.</p><h3>​Beware of creating a Potemkin village</h3><p>The flipside is that if this is not expected to happen, the whole transformation won't work. One must be willing to hear the bad news and be ready to make proactive decisions.</p><p>After years of simply accepting the problems, teams will suddenly start shouting from the rooftops about these issues, and senior management needs to step up and work with them to make the workplace more agile-friendly. If they don't, teams will remain stuck in a rigid environment. Everyone will just call himself with a new title, such as product owner or Agile coach. This reorganization is likely to be seen as another waste of money and a failure, with many concluding that Agile doesn't work. A Potemkin village.</p><p>All levels of an organization need to be ready to face these challenges and work together to find solutions. A decision to adopt Agile is just the first step. Even the managers must be ready to roll up their sleeves and get involved in identifying and solving problems that arise during the transformation. It's a team effort, and everyone needs to play an active role. The more complex the business structure is, the longer the whole transformation will likely take. This is an ongoing process that is unlikely to ever come to a complete end. But the deciding factor is if there's actually a will to start and keep undergoing an uncomfortable change.</p><p>One surprising fact about Agile transformation is that it might lead to more bureaucracy if not implemented correctly. For example, suppose a company adopts Agile without addressing underlying issues such as convoluted decision-making processes or rigid approval procedures. In that case, it may inadvertently create more bureaucracy by adding more layers to the process. This is because Agile requires constant communication and collaboration, and if these processes are not streamlined, it can result in even more delays and inefficiencies.</p><h3>​​True motivation: A sense of security</h3><p>In my experience, failed attempts at agile transformation often stem from a common underlying issue: a lack of trust. This can manifest in various ways, such as a tendency to monitor and control teams closely. After one such transformation I've seen teams being required to share their sprint commitments, burn-down charts, and velocities, and then having to explain themselves when they don't meet those metrics. This happened at the senior management level.</p><p>Such reporting activity created a false sense of security by prioritizing the appearance of stunning charts and numbers on paper rather than the actual value of the work being done. The focus was on keeping commitments rather than questioning the sense of those commitments and the overall plans. Needless to say, what was missing was a critical examination of the actual business value of the effort invested and the value of the things developed. So it was quite obvious what the true initial motivation for Agile adoption had been.</p><h3>Do you really want to go Agile?</h3><p>​In conclusion, Agile transformation can be a powerful tool for organizations looking to improve their productivity, efficiency, and speed. However, it is essential to approach it with realistic expectations and a willingness to address underlying structural and cultural issues. Agile transformation is not a quick fix or a one-time investment but requires continuous effort and commitment from all levels of the organization. Managers must be ready to roll up their sleeves and work with their teams to identify and solve problems that arise during the transformation.</p><p>​​Furthermore, it is crucial to approach the transformation focusing on business value and not just metrics and appearance. So, before embarking on the journey of Agile transformation, think twice and ensure you are willing to fully commit to the process. Going Agile is about being able to react more fluidly to changing business circumstances, isn't it? If there's little willingness to address the underlying issues that hinder progress, what's the point of identifying them in the first place? That by definition hinders the fluidity from happening.</p><p>If fundamentally changing an organization, including its core cultural, technical, and process aspects for the better, isn't the honest motivation, then maybe it will be more comfortable to maintain the status quo and save the embarrassment that an attempt to perform an Agile transition would inevitably bring.​​<br></p><br>
Animation plugins in Figmahttps://www.cleverlance.com/en/blog/Pages/animation-plugins-figma.aspxAnimation plugins in Figma<p><em>​​​​​​​​​Disclaimer: all tools mentioned in this article are under active development with frequent releases, so the version used when writing this article may already be older than yours. All animations referenced in the article can be found in this </em><a href="https://www.figma.com/file/rtjSqflfNWeaMPAjrQzhoM/Figma-Animations-overview-article---resources?node-id=0:1" target="_blank"><em>Figma file</em></a><em>.</em><br></p><p>When one says "animation tool", most people in the industry immediately think of Adobe Animate or After Effects. No wonder, it's the "industry standard" after all. But when you only animate every once in a while, need to make a nice loading screen, and you already have all the assets made in Figma, you don't want to deal with other tools. As you will see, there is no need to resort to such overkill solutions!<br></p><p>At an opportune moment, Figma plugins enter the scene, enriching its native shape compositing and prototyping functionality with exportable animation capabilities. In this article I will present a selection of the best ones. But first, a bit of terminology.<br></p><h3>Keyframe<br></h3><p>Represents the state of an attribute of a given layer at a given time.<em><img src="/de/blog/PublishingImages/Articles/CreateIt/position_and_color_shift-2.gif" data-themekey="#" class="ms-rtePosition-4" alt="" style="margin:5px 200px;width:190px;height:190px;" /></em></p><p><em>The keyframe for attribute X at 0 seconds into the animation sets the switch position to the left, the next keyframe to the right. Two more keyframes change the color of the switch, the remaining two change the background color</em> (created with Motion).</p><h3>Ease<br></h3><p>Defines the acceleration and deceleration of the transition in time, whether it is faster at the beginning, at the end, or in the middle. This adds a sense of life to the animation - after all, few things in the world move uniformly (linearly), except perhaps gears.<em><img src="/de/blog/PublishingImages/Articles/CreateIt/Ease-2.gif" data-themekey="#" alt="" style="margin:5px 200px;width:190px;" /></em></p><p><em>The light square moves with a linear ease setting, while the dark one moves with "Ease in and out" - it speeds up at the beginning and slows down at the end </em>(created with Motion).<br></p><h3>Object anchor </h3><p>A point that defines the position and anchor of the layer in space. The layer rotates around the <span style="color:#232323;font-size:16px;">anchor; it is used for all motion calculations.</span><br></p><br><p><img src="/de/blog/PublishingImages/Articles/CreateIt/Anchor_center-2.gif" data-themekey="#" alt="" style="color:#696158;font-size:14px;margin:5px;width:190px;" /><img src="/de/blog/PublishingImages/Articles/CreateIt/Anchor_top_left-2.gif" data-themekey="#" alt="" style="margin:5px;width:190px;" /><img src="/de/blog/PublishingImages/Articles/CreateIt/Anchor_offcenter-2.gif" data-themekey="#" alt="" style="margin:5px;width:190px;height:190px;" /><br></p><p><em>Anchor in the center, top left corner, and at 50% of the X dimension and 75% of the Y dimension </em>(created via Motion).</p><h3>Formats<br></h3><p>in which motion graphics are commonly found on the web:​​​​​​​​<br></p><p><strong>MP4 and WEBM</strong></p><ul><li>Video formats<br></li><li>do not preserve quality when scaling<br></li></ul><p><strong>GIF</strong></p><ul><li>sequence of raster images<br></li><li>does not preserve quality when scaling<br></li><li>large volume<br></li></ul><p><strong>SVG</strong></p><ul><li>XML containing Javascript, CSS or SMIL code that defines individual shapes and their movement<br></li><li>scalable, easy to edit (if you can write the code)<br></li></ul><p>Bonus: <strong>Lottie</strong></p><ul><li>a new minimalist format based on JSON<br></li><li>shapes and their movement are defined using a maximum of two-letter attribute abbreviations<br></li></ul><p>Now let's get into the details of the individual animation plugins.</p><h3>Motion​<br></h3><p><img src="/de/blog/PublishingImages/Articles/CreateIt/motion.png" data-themekey="#" alt="" style="margin:5px;width:658px;height:336px;" /><br></p><p><a href="https://motionplugin.com/#" target="_blank">Motion</a> is a plugin with wide animation possibilities, based on keyframes. It allows animating a wide range of attributes, changing anchors with great granularity and copying keyframes between layers with X and Y value recalculation for a simplified workflow. A rich library of preset animations, effects and motions is available so we don't have to set everything up manually.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/link_and_vector_path_shadow-2.gif" data-themekey="#" alt="" style="margin:5px;width:648px;height:402px;" /><br></p><p><em>A paper plane moves according to the drawn vector and the shadow follows it thanks to the dependency provided by the handy link function.</em><br></p><p>​The finished animation can be exported in many formats, including GIF, MP4/WEBM and SVG in beta. GIF and SVG also support layer transparency.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figma1.png" data-themekey="#" alt="" style="margin:5px 230px;width:190px;height:411px;" /><br></p><p>Motion has four different licenses, with the free version limited to two-second animations and 30 FPS. The Professional license for 8 days per month is convenient for users who don't animate for a living.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figma6.png" data-themekey="#" alt="" style="margin:5px;width:658px;" /><br></p><p><em>The 8-day Motion license costs $6.39 per month.</em></p><p>Overall, the Motion plugin is very pleasant to use, although I would appreciate the option of a separate window for multi-screen work.<br></p><h3>Figmotion<br></h3><p><a href="https://www.figma.com/community/plugin/733025261168520714/Figmotion" target="_blank">Figmotion</a> is a free plugin with a web interface that makes it ideal for multi-screen work. It is also based on the use of keyframes. Compared to Motion, it supports animation of individual rounded corners and stroke widths, on the other hand, copying keyframes is done without recalculation, which in combination with the need to click Save every time, considerably slows down the workflow.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figmotion_corners-2.gif" data-themekey="#" alt="" style="margin:5px 200px;width:190px;height:190px;" /> </p><p><em>Rounding of individual corners and stroke width.</em><br></p><p>​Figmotion implements the dependency between layers using expressions, i.e. calculating values based on variables (time in milliseconds or progress as a decimal value between 0 and 1), or attributes of other layers. However, this functionality is not well documented and you need to know Javascript.<br></p><p>​​​​​The plugin has only four basic preset ease options and completely lacks a motion library, which means the users have to do everything manually. The anchor can be set to one of nine preselected positions. It supports export to MP4, WEBM and GIF up to 60 FPS, but without the option of transparent layers. Lottie format export was also recently launched in beta, and front-end developers will be interested in the new export for React's Framer Motion.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figma2.png" data-themekey="#" alt="" style="margin:5px 230px;width:190px;height:325px;" /><br></p><p><em>Anchor settings are on top, keyframe settings in the center, and transition options on the bottom.</em></p><p>​​​Figmotion has a huge number of features, but many of them are unfinished, and frequent bugs and a cumbersome workflow take away from its usability. On the other hand, it has unlimited animation length, is free, and has the largest number of users in the Figma community.<br></p><h3>Bonus: Jitter.video<br></h3><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figma3.png" data-themekey="#" alt="" style="margin:5px;width:658px;height:399px;" /><br></p><p><a href="https://jitter.video/" target="_blank">​Jitter</a> is a web tool for creating animations from vector shapes which doesn't work directly in Figma, but you can import assets from Figma in a single click using their plugin. While it doesn't yet support all attributes (for example, individually rounded corners), it solves this relatively elegantly - it imports the unsupported layer as a PNG. Rather than keyframes, it focuses on the transition process. It provides a decent library of preset animations and a simplified view of individual attributes.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/figma4.png" data-themekey="#" alt="" style="margin:5px 230px;width:190px;height:460px;" /><br></p><p><em>The user is shileded from individual attributes by user-friendly verbs.</em></p><p>Jitter in the free version does not allow transparent backgrounds and export to higher resolutions. In the case of the beta Lottie export, this limitation is quite easy to work around - you just need to know a bit about the Lottie format and set the transparency manually. The paid version costs $12/month.<br></p><h3>Conclusion<br></h3><p>As you can see, there are several ways to get otherwise static assets moving in Figma, it just depends on what one expects from the tool and whether one is willing to pay something for the extended possibilities to implement one's ideas. The fact that they compete with each other encourages dynamic development, which of course is not without bugs, but the developers of these tools are quick to respond and appreciate every bug reported (I've written about ten of them myself).</p><p>Would you like to learn how to use one of the plugins? You can look forward to a sequel in the form of a tutorial on Motion.​​<br></p>
Unexpected bad practiceshttps://www.cleverlance.com/en/blog/Pages/unexpected-bad-practices.aspxUnexpected bad practices<p>​​Some programming practices are so familiar to us that we use them automatically without much thought. Sometimes these techniques become obsolete; sometimes they are applied in the wrong context. Addressing such poorly experienced habits is often met with revolt. Especially by those who use them and perceive the topic as useful, so let's do exactly that!</p><h3>Marks<br></h3><p>Programming IDEs often recognize specific types of comments to help navigate across the codebase. Xcode’s <em>FIXME</em> lets other developers know that a piece of code deserves more attention. <em>TODO</em> is helpful when something is, well, to be done. <em>MARK</em> differs from the previous cases; it serves a documentation purpose. The same feature in IntelliJ IDEA/Android Studio is called r​egion.<br></p><p>Marks divide the source code into multiple parts using headings. That can make the code appear broken into logical units. If you are a reader familiar with the former Objective-C era of iOS development,​ know that this is just an updated <em>#pragma mark</em> directive.<br></p><p>Typical usage is in files with a large number of lines. <em>Marks</em> create the illusion of clarity by breaking them into pieces that supposedly belong together.<br></p><p>The usage of marks in such cases is a bad practice. Developers often abuse them to justify a file being too big. One should not depend on Xcode to make the code comprehensive and readable. Small and well-decomposed classes are more straightforward to reason about and navigate without IDE features. Especially for pull request reviewers using the web interface where those features are absent.<br></p><h3>Extensions</h3><p>Modern programming languages such as Kotlin or Swift allow you to extend classes, interfaces/protocols, structs, or enums to provide an additional implementation. You can divide your code into multiple pieces using extensions to outline what belongs closer together. Another usage is to make a convenience extension around another type you might not even own to make its use more intuitive. The possibilities are almost limitless. This isn't always a good thing, but first, a peek into history.<br></p><p>Extensions existed way back in Objective-C as well. If you're not blessed with experience with programming in such a language and had to guess the name for extensions, you'd likely be surprised. It's Categories! Another surprise is that Extensions are a thing in Objective-C too, but serve different purposes. What's interesting is the difference between both languages. Categories in Objective-C forced the developer to come up with the name. That's why files named in style <em>Class+CategoryName.swift</em> are often used even for Swift extensions. And more importantly, to use Categories, you had to import them explicitly.<br></p><p>Extensions in Swift are an unnamed piece of code. Such code may be more complicated for the reader to grasp. If multiple extensions of the same type exist, adding a name to the code and wrapping it in a type might help readability immensely.<br></p><p>Improper extension of widely used types causes namespace pollution. It's critical, before creating extensions, to ask whether all instances of the type should have such an ability. Should all UIViews have access to a blinking method? Does one specific subclass of UIView make more sense?<br></p><p>Some developers use extensions to break down the implementation of multiple protocols: which might also be a warning sign. If a class implements many protocols, it may be time to consider splitting it into smaller classes.<br></p><p>For trolls out there: you can make your co-workers mad by extending <em>UIView</em> with <em>translatesAutoresizingMasksIntoConstraints and watch them compare it with translatesAutoresizingMaskIntoConstraints.</em><br></p><p>But don't.</p><h3>Comments<br></h3><p>The ability to write comments might lead undisciplined programmers to create code of poor quality. Unfortunately, it's easier to neglect to name a variable and describe what's going on in my head with a complicated but not-so-clear comment. Easy should not be our goal. Brevity and clarity should.<br></p><p>Great comment for poorly written code is still a code smell. Don't just take my word for it. Robert Martin states: "A comment is a failure to express yourself in code. If you fail, then write a comment; but try not to fail."<br></p><p>Another reason is as the code lives in the repository and is modified and refactored, its behavior might change, and its name can express it everywhere it is called. But its comment is rarely updated and may become more confusing than helpful.<br></p><p>Documentation comments serve their purpose very well when you're designing an API for others to use. Remember that the API needs to stand by itself, and clarity is the priority. Don't use the documentation comments as an excuse for a lousy design.<br></p><h3>Structure</h3><p>The structure of a project is one of the first things you see when you check out a codebase, and it should outline the app's purpose at first sight. However, it is not an exception that some projects have folder structures inspired by the layers of architecture, e.g., View, ViewModel, Model.</p><p>Project ​struc​ture based on architecture layers is a bad practice. It makes reusability effectively impossible. Navigating through such a structure is unnecessarily complicated and becomes harder to maintain as the scope increases. It doesn't scale. Folders inspired by the architecture might have their place, not just at the top level. It should not be the first thing you see.<br></p><p><img src="/de/blog/PublishingImages/Articles/MobileIt/unexpected-bad-practices-01-01.png" data-themekey="#" alt="" style="margin:5px;" /><br></p><p>See for yourself, what structure tells you more about the application?<br></p><h3>Dependencies</h3><p>Open source offers many libraries to simplify life, from UI components through networking to dependency injection solutions. It can often save a great deal of time and effort. On the other hand, this carries various dangers and limitations; using third-party libraries requires discipline, order, and balance.<br></p><p>Randomly scattered third-party dependencies significantly reduce robustness. Shielding the core of the application and using the libraries from the outer parts of the architecture helps mitigate the risk. Abstraction eases the process of replacing one library with another.<br></p><p>It's OK to utilize 3rd party dependencies, but with caution. Ask yourselves: How much time will it save me? How much effort will it take to replace? Can I install enough defense mechanisms to protect the application?<br></p><p>The silver bullet to protect your app, though sometimes tricky or impractical, is to have the import of the dependency in only one place.</p><p>We've had the pleasure of taking over multiple apps that were impossible to maintain anymore due to this problem. Without abstraction, no longer supported (or closed sourced) libraries disintegrated the codebase. External dependencies should never hold your product hostage.<br></p><h3>Tests</h3><p>Test-driven development is a programmer's good manners, a discipline overflowing with benefits. Technical impacts are a blog post by itself, if not a series. Non-technical impacts such as easy onboarding of new team members and executable documentation that cannot become obsolete speak for themselves.<br></p><p>Yet they are often neglected. A complete absence of tests is the apparent first and most common violation, followed by writing tests after the production code, which mitigates all the benefits and introduces other obstacles.<br></p><p>You must write unit tests first - before production code. Testing first will prevent you from creating code that's too complex. It will guide you through building components of the right size. The big classes are challenging to test, and the tests will direct you to decompose them into smaller ones.<br></p><p>Tests written after production code are inherently lower quality and can even be misleading. Unless you write the production code as proof of the first failing test, it is impossible to say whether the tests assert what they declare. It is then questionable how well such tests protect the system under test.<br></p><p>If you write tests after implementation, you may find a component challenging to test, which is impossible with a test-first approach. You can't create untestable code!<br></p><h3>The devil's in the detail</h3><p>Even the mundane can be harmful if we do something too automatically and with less attention. Challenge the ordinary and seek bad practices that you wouldn't expect.​​<br></p>
Apple thinks about the security of its usershttps://www.cleverlance.com/en/blog/Pages/apple-account-deletion.aspxApple thinks about the security of its users<p>​​​Mobile apps are becoming increasingly popular among users. Thousands of them are downloaded every day from <strong>Google Play</strong> and the<strong> Apple App Store</strong>. However, not all apps are completely secure for their users and not all manage the personal data of their users correctly. The above-mentioned companies try to make sure that only apps which “play fair” with users get into their stores.<br></p><p>In order to protect the privacy of iOS app users, Apple has issued a <a href="https://developer.apple.com/support/offering-account-deletion-in-your-app" target="_blank">regulationstating</a> that: “Starting June 30, 2022, apps submitted to the App Store that support account creation must also let users initiate deletion of their account within the app.”</p><p>Originally, this guideline was supposed to apply from the end of January 2022, but the deadline was postponed by 5 months due to pressure from developers and app companies. This is due to the fact that updating apps is not always a simple procedure. Apple has clear rules for deletion of an account: </p><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px;"><p>• The process of deleting the account must be clear, intuitive and transparent, easy to find in the application (e.g. a button to take you to the user profile or account management).</p><p>• We must offer complete deletion of the entire account record, including associated personal data. Merely offering to deactivate (temporarily disable) the account is not enough. </p><p>• If users have visit the website to complete deletion of their account, we should add a direct link to the page on the website where they can complete the process. </p><p>• Users must be well informed. If the deletion request is going to take longer to complete, we need to let users know. </p><p>• If the app supports in-app purchases, we need to clearly explain to people how subsequent billing and account cancellation will take place. </p><p>• All apps must include an easily accessible link to the privacy policy in the description on App Store Connect within the app. </p><p>• Last but not least, it is necessary to comply with the applicable legal requirements for the processing and storage of the client’s personal data. And also its deletion. This includes compliance with local laws - in our case, the applicable GDPR directive.</p></blockquote><p><a href="/en/" target="_blank">Cleverlance</a> in its capacity as a technology company, helps its customers address these requirements. As a supplier of mobile applications, we have successfully resolved this issue, for example in the mobile application for <a href="https://apps.apple.com/cz/app/my%C5%A1koda/id1161648654?l=cs" target="_blank">MyŠkoda</a> ŠKODA AUTO a.s. Exactly according to the GDPR directive, here customers can completely delete their account in their profile, including their personal data. However, they must first disco​nnect their cars, which they control via the app. </p><p>In banking, the situation is slightly different. Although users can delete their accounts and access to the mobile app, their products remain untouched in the bank. Just like their personal data which must remain in the systems because of the legitimate interest of processing personal data and fulfilling a legal obligation. Users can cancel their account in the app and in doing so stop using the app. But they remain full-fledged customers of the bank.</p><h3>What does Google say?</h3><p>And how does another giant, Google, feel about this? The rules for displaying apps in Google Play state that the app must be transparent and inform the user how it processes their personal data. They prohibit outright fraudulent or dishonest conduct. However, Google has not yet taken the step of dictating that every app, if it creates a user account, must also allow the deletion of that account. </p><p>This move by Apple will certainly improve the transparency and fairness of apps as regards their users. It is a good step in the right direction towards a more honest electronic world. </p><h3>Recommendations for developers </h3><p>For the implementation of the new account deletion functionality, I recommend scheduling a separate release after the specified date. This is to say that Apple is likely to be rigorously testing the functionality and this may lead to a delay in release of the new version. This could have a detrimental effect on other important new functionality of the app if released alongside this release. And users don’t like to wait.​<br></p>

​