Tag: programming

  • Mob Programming During a Pandemic: Lessons Learned

    Mob Programming During a Pandemic: Lessons Learned

    Despite limitations, mob programming can be effective, even during COVID-19

    The COVID-19 pandemic has many of us considering the long-term impact on our personal and working lives. Shaking hands with new colleagues or clients? Buffet lunches? I’ve recently wondered how social distancing will affect mob programming, which is a development practice we implemented at Bonitasoft late last year.

    What is mob programming? It’s a software development approach where an entire team gathers around one keyboard and one projector screen at once, according to Agile community organization Agile Alliance. It’s an extension of the idea of pair programming, which involves two team members collaborating to complete a development task in the same space.

    In an August 2013 CodeBetter.com post, Marcus Hammarberg, head of Quality & Curriculum at the School of Applied Technology in Sweden, equated mob programming to driving. The driver uses the keyboard, writing the code and following coding standards. Other team members are navigators, advisers and researchers who assist the driver and focus on higher-level tasks such as determining if the team is solving the right problem. They also tag in to take over as the driver.

    “I’m not saying that mob programming is for everyone, neither is pair programming,” Hammarberg write. “It might not be for all types of tasks either … But I am saying that getting your team into a room, with one computer and one screen, the whole team is working together on one feature—that there is no more effective way to get that feature out.”

    Of course, much has changed over the past several months, including people’s comfort level with being in close proximity. Before I get into my recommendations for how mob programming can work in the current situation, let me share why Bonitasoft embraced it to begin with and the benefits to my company.

    Embracing Mob Programming

    About a year ago, I saw Agile coach Woody Zuill deliver a presentation titled “Mob Programming: A Whole Team Approach,” at MixIT 2019. I was intrigued by what I saw as a promising development approach. However, I had my doubts about the effectiveness and logistics of gathering five people in front of one screen. I also suspected it wouldn’t be compatible with remote work—a premonition of today’s situation?

    Running development projects in sprints made it a low-risk investment, so I introduced mob programming to the other members of my five-person team, which is responsible for the development of the Bonita platform portal for delivery of applications and is comprised of a mix of introverts and extroverts. The team took a mob programming approach to design and test an application page. It was a medium complexity project built with Gradle, using the UI Designer web page development tool and tested with Cypress.

    After discussing the project’s objective and methodology, the team worked on a laptop and a standard-size screen in the open office space. Pros: Fast development completion, better implementation and good test coverage. Cons: Decreased focus because of lengthy discussion and the distraction of phone notifications, communication style differences and paused cross-cutting topics.

    My team members and I loved the result of mob programming but needed to iron out the format. We also skipped the first stage of agility in our excitement to try mob programming: starting with a strong framework and basic rules. These include spelling out the roles of the pilot, navigator and researchers on a team.

    Among other adjustments, we moved to a quieter spot in the office to work. We swapped out the small screen for a giant screen and replaced the laptop with a desktop, keyboard and mouse. We scheduled more breaks. We adhered to the basic rules. We rotated roles every 15 minutes, which meant all team members were more attentive and involved. Recognizing that timid team members might not speak up, we distributed speaking time more fairly. And we were more selective when choosing projects for the mob programming method (bug fixes, for instance, are best solved through pair programming).

    How We Benefited from Mob Programming

    The process required a little tweaking at the beginning but it was well worth it. We’ve realized a lot of benefits from the mob programming methodology. One of the biggest benefits is all the time we save on development projects. Mob programming eliminates merge conflicts, decreases the time spent in standup meetings and pull request reviews and reduces external interruptions (people are less willing to interrupt an entire group than just one dev working independently).

    Here are a few more mob programming benefits:

    • Global knowledge sharing: All members of a mob programming development team receive the same level of knowledge on new developments. New team members are able to quickly ramp up on the legacy code.
    • High-quality solutions: The solutions from mob programming efforts tend to be better tested with fewer bugs in the final product. Since the code is made modularly, it’s easy to modify if needed.
    • Team growth: Mob programming has taught us to communicate in a way that works best for each team member. We appreciate the diversity of thought and personality among team members rather than viewing it as a disadvantage.

    Can Mob Programming Work in a Pandemic?

    Now that you know why I recommend mob programming let’s look at whether it’s possible to continue using this methodology safely during the pandemic. Bonitasoft devs are all working remotely so I base this on experience. We apply the basic rules using videoconferencing tools and duplicate the development environment for everyone. Communicating via videoconferencing was an adjustment but it works. Each team can adapt mob programming to what works best for them over multiple iterations, whether they’re working in the same space or remotely.

    Here are a few mob programming tips:

    • Define when it involves remote work versus when it will involve everyone working in the same space (with social distancing procedures in place, of course).
    • Apply the basic rules strictly, so you have a solid foundation on which to build a mob programming practice.
    • Limit potential distractions by opting for a large screen, mouse and keyboard in a quiet location.
    • Factor free time into your non-sprint work schedule so that team members can check their email and work on other projects.
    • Define break times (the Pomodoro technique could be one option).

    Mob Programming is Worth Exploring … Even Now!

    During the past few months, I’ve learned a lot about mob programming and believe there’s a certain magic to it. At Bonitasoft, smart implementations have resulted from the development team embracing the value of collective intelligence and mob programming. We’re delivering projects faster and enjoying greater satisfaction in our work lives. With some adaptation, it’s possible to realize its value by adding it to your development methodology options.

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    There’s no denying that low-code is a rising trend in application development that’s likely to stay for the long run. Its impressive benefits in terms of agility and development time are convincing the enterprise, so it’s no wonder that the industry is on its course to achieve fivefold growth between 2017 and 2022.

    In low-code platforms, building custom cloud applications can be achieved by reusing components through a simple drag-and-drop interface, which means reduced engineering efforts. Then, APIs can be used to hook components together and maximize compatibility.

    Although many steps of the way can be achieved without actively writing a single line of code, many low-code apps include advanced logic written in JavaScript. So, when it comes to understanding the threat model of low-code platforms, we must consider security considerations that arise from using JavaScript code.

    Low-Code and JavaScript

    Because JavaScript needs to be interpreted by a browser to work, it is exposed and anyone can access, read and modify it. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the inexistence of a back end or the need to avoid performance losses. So, companies’ proprietary algorithms and logic end up running on an adversarial environment, which opens the door to a series of attacks—namely, automated abuse, piracy, intellectual property theft and data exfiltration.

    When it comes to protecting code, typically we’re led to the concept of encryption. However, JavaScript encryption is not a feasible strategy; the browser always needs to interpret JavaScript so that it works. If we have a decryption key, we need to supply it to the browser; if that key becomes compromised, all the code will be easily accessed.

    A suitable approach to protect JavaScript is transforming it into a new version that is extremely difficult to understand while also preventing attackers from debugging or tampering with the code.

    When it comes to enterprise or commercial applications, JavaScript must be protected with maximum resilience—that the protected code will prevent attackers from using automated tools against it. On top of this, the code should contain runtime defenses that break the application whenever attackers try to debug or tamper with the app’s source code.

    Conclusion

    Low-code still means a lot of code. Even though most of it will not appear on the front stage, development teams must not forget that it should always be protected. Attackers love low-hanging fruit and unprotected source code of enterprise apps is certainly a low-effort, high-gain venture.